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

Stéphane Mottelet stephane.mottelet at utc.fr
Wed Sep 19 14:36:29 CEST 2018


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 
>


-- 
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet




More information about the users mailing list