[Scilab-users] [Scilab-Dev] algebra conventions with integer types to be discussed

[antoine monmayrant]

Another one of my favorites, that highlights the fact that scilab needs 
a lot of polishing (in particular in the documentation & naming) to help 
new or non-specialist users:

Compare the choice of name for matlab  poylval() and scilab horner().
How could I know that to evaluate a polynomial I should call horner()?
If you don't know the name in advance, trying to use the help system for 
"polynomial evaluation" or similar strings is not going to help you much¹.
As I can never remember the name of the horner() function, I always end 
up opening the help system, browsing manually down to the Polynomials 
page and parse the listing of the functions to find the one mentioning 
"evaluate".

Arrrrgghhhhh....

Antoine

¹ "help polynomial" brings you to the legacy scilab API example on 
polynomial! Spot on ! :-)


Le 19/09/2018 à 14:36, Stéphane Mottelet a écrit :
> Hello Antoine,
>
> Le 19/09/2018 à 13:28, antoine monmayrant a écrit :
>>
>>
>> Le 19/09/2018 à 13:04, Samuel Gougeon a écrit :
>>> Le 19/09/2018 à 11:10, Stéphane Mottelet a écrit :
>>>> Le 19/09/2018 à 11:01, Samuel Gougeon a écrit :
>>>>> Le 18/09/2018 à 19:26, philippe a écrit :
>>>>>> Le 17/09/2018 à 19:03, Stéphane Mottelet a écrit :
>>>>>>> Do I have to conclude that the implementation is currently so 
>>>>>>> incoherent
>>>>>>> that *nobody* uses integer types in Scilab (other than Scilab code
>>>>>>> itself) ?
>>>>>> it's a new feature,
>>>>>
>>>>> It would not be a new feature, but a change. This means that for 
>>>>> 30 years that Scilab
>>>>> and its int8 uint8 int16 uint16 int32 uint32 datatypes exist, the 
>>>>> current algebra is used,
>>>>> and is used in a consistent way, even if in some aspects we may 
>>>>> deem that this way
>>>>> is too rough. At least, it is predictable, and manageable.
>>>>> And so, changing the current algebra would break all codes 
>>>>> implemented with encoded
>>>>> integers for 30 years.
>>>> The aim of my first message was a try to clarify this point. Where 
>>>> are this codes ?  In scilab itself, in user codes ? To me, user 
>>>> codes having been untouched since 10 years are not used any more...
>>>
>>> I think that this position underestimates a lot users wish for 
>>> stability and reproducibility.
>>> In a lab, in a design office, or even in the text book for a lesson 
>>> in maths or computing,
>>> if it is not possible to get the same results when changing the 
>>> Scilab version you use,
>>> then many users/authors will keep using the scilab version with 
>>> which the code/book has
>>> been implemented/written. It does not prevent installing later 
>>> versions.
>>>
>>> Even 10 years: It is the "official" lifetime of the whole Scilab 5 
>>> family. If we fairly assume that
>>> the community have grown a lot with Scilab 5, it represents likely 
>>> almost all the existing codes.
>>> And the Scilab 5.5.2 will be still used for (10 ?) years. Killing 
>>> the ATOMS server for 5.5.2
>>> won't remove Scilab 5.5.2 where it is installed for existing codes, 
>>> and won't provide time
>>> to authors to update their existing ressources.
>> I second that!
>> I started using scilab with version 2.6 and no later than this year, 
>> I had to rerun a bunch of scripts dating back from 2004/2005 so most 
>> probably created using scilab 3.x.
>> Some of them ran without any modification and some others required 
>> minor updates to give exactly the same old result (most changes being 
>> in the cosmetic of the graphics, not on the core results of the 
>> simulation).
>> Last week, I gave to one of my colleagues a code I wrote in 2008, so 
>> exactly 10 years ago.
>> So reusing a 10-years-old code that have not been used during a 
>> decade is quite common for us ...
> Please include me into "us" :-D I started using Scilab when it was 
> Basile, in 1989. Like you, I have a bunch of old code that I am happy 
> to be able to run with minor glitches.
>
> What I meant is that too much conservatism is no good for Scilab. Have 
> you ever tried to put yourself into the position of a true Scilab 
> newcomer ? Not that easy. The long-term users who we are have 
> developped a particular abnegation that newcomers do not have. Each 
> year I meet some people who try Scilab for a while and just move on 
> (sometimes my own students).
>
> Take the example of the "new graphics". The core of it is solid 
> (SciRenderer, and so on), but at the Scilab level... Even changing 
> french-inspired command names seems to be a problem (champ, fec, ...), 
> different interpretations of foreground/background depending on the 
> context, hard-wired color numbers, figure canvases denoted as "Axes", 
> and so on.
>
> Please don't mistake yourself about my intentions: I am not just 
> playing with Scilab, I just want that people really use it instead of 
> Matlab (for example in my university, people teaching Signal 
> processing and Automatic Control still use Matlab. They just tried a 
> little bit, then moved on).
>
> The particular point on integers was probably not the good point to 
> start with, but just an example of our reactions to eventual changes 
> aiming a better  compatibility of Scilab with other software.
>
> S.
>
>>
>> Cheers, gcf
>>
>> Antoine
>>>
>>> About Scilab 6.0 itself:
>>> The 
>>> "[^a-zA-Z0-9_](int8|uint8|int16|uint16|int32|uint32|int64|uint64)[^a-zA-Z0-9_]" 
>>> pattern
>>> gets 3876 hits in 293 *.sci *.sce and *.tst files.
>>> Not counting the *.xml ones, nor the hardcoded *.c *.cpp *.java ones 
>>> in which the algebra
>>> would have to be overhauled and updated as well.
>>>
>>> Samuel
>>>
>>> _______________________________________________
>>> users mailing list
>>> users at lists.scilab.org
>>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users 
>>>
>>>
>>
>> _______________________________________________
>> users mailing list
>> users at lists.scilab.org
>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users 
>>
>
>