Hello Antoine > Le 19 sept. 2018 à 13:28, antoine monmayrant <antoine.monmayr...@laas.fr> 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 ...
> > Cheers, > > 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@lists.scilab.org >> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users >> > > _______________________________________________ > users mailing list > users@lists.scilab.org > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users _______________________________________________ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
