Philippe Roux |
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, I would have like to use it before ... I've build my own solution and now I just need time replace it with int64. For mixed int/double expression I expect to get the best floating point approximation as a result. Best regards, Philippe _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Hello Philippe,
Great to hear from you, 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, I would have like to use it before ... I've build > my own solution and now I just need time replace it with int64. > > For mixed int/double expression I expect to get the best floating point > approximation as a result. and for int/int ? S. > > > Best regards, > > Philippe > > > _______________________________________________ > users mailing list > [hidden email] > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Le 18/09/2018 à 20:53, Stéphane Mottelet a écrit :
> Hello Philippe, > > Great to hear from you, > > 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, I would have like to use it before ... I've build >> my own solution and now I just need time replace it with int64. >> >> For mixed int/double expression I expect to get the best floating point >> approximation as a result. > and for int/int ? I use. So 3.0/4.0=0.75 but 3/4=0. But maybe getting a rational would make more sense? Antoine > > S. >> >> >> Best regards, >> >> Philippe >> >> >> _______________________________________________ >> users mailing list >> [hidden email] >> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users >> > > _______________________________________________ > users mailing list > [hidden email] > http://lists.scilab.org/mailman/listinfo/users > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++ Antoine Monmayrant LAAS - CNRS 7 avenue du Colonel Roche BP 54200 31031 TOULOUSE Cedex 4 FRANCE Tel:+33 5 61 33 64 59 email : [hidden email] permanent email : [hidden email] +++++++++++++++++++++++++++++++++++++++++++++++++++++++ _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Philippe Roux |
Le 19/09/2018 à 09:03, [hidden email] a écrit :
> Le 18/09/2018 à 20:53, Stéphane Mottelet a écrit : >> and for int/int ? > For me, this should be int, to be consistent with most of the languages > I use. > So 3.0/4.0=0.75 but 3/4=0. > But maybe getting a rational would make more sense? I agree, I would expect the quotient of Euclidian division in this case. Best Regards, Philippe _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
In reply to this post by amonmayr
Le 19/09/2018 à 09:03, [hidden email] a écrit :
> Le 18/09/2018 à 20:53, Stéphane Mottelet a écrit : >> Hello Philippe, >> >> Great to hear from you, >> >> 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, I would have like to use it before ... I've build >>> my own solution and now I just need time replace it with int64. >>> >>> For mixed int/double expression I expect to get the best floating point >>> approximation as a result. >> and for int/int ? > For me, this should be int, to be consistent with most of the > languages I use. > So 3.0/4.0=0.75 but 3/4=0. > But maybe getting a rational would make more sense? Here are some links to interesting discussions to help getting one : https://docs.julialang.org/en/v0.6.1/manual/conversion-and-promotion/ https://fr.mathworks.com/matlabcentral/answers/18222-arithmetic-promotion-floating-point-to-integer https://fr.mathworks.com/matlabcentral/answers/36773-why-float-no-become-integer https://stackoverflow.com/questions/2425251/how-do-i-get-real-integer-overflows-in-matlab-octave/2430278#2430278 S. > > Antoine >> >> S. >>> >>> >>> Best regards, >>> >>> Philippe >>> >>> >>> _______________________________________________ >>> users mailing list >>> [hidden email] >>> https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users >>> >> >> _______________________________________________ >> users mailing list >> [hidden email] >> 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 _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Samuel GOUGEON |
In reply to this post by Philippe Roux
Here is the start of this discussion.
As cross-posting looks forbidden/prevented/canceled, i am afraid that only the dev@ list received both initial messages. At least, only the dev@ archives publish them. Also, setting a scilab list in CC: while the main receiver is another list looks also useless because it is silently canceled (see the dev@ online archives). Regards Samuel Le 14/09/2018 à 18:20, Stéphane Mottelet a écrit : Hello all, Le 17/09/2018 à 19:03, Stéphane
Mottelet a écrit :
[No answers] _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Samuel GOUGEON |
In reply to this post by Philippe Roux
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. While introducing an actually new feature breaks nothing. Regards Samuel _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
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. this codes ? In scilab itself, in user codes ? To me, user codes having been untouched since 10 years are not used any more... S. > While introducing an actually new feature breaks nothing. > > Regards > Samuel > > _______________________________________________ > users mailing list > [hidden email] > 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 _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Samuel GOUGEON |
In reply to this post by Samuel GOUGEON
The current implementation is not incoherent. The message was likely not published on users@. The traffic is (much?) lower on dev@ than on users@. A poor trafic about this topic could also mean that
Best regards _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Le 19/09/2018 à 11:17, Samuel Gougeon a
écrit :
However, there are still bugs, and when trying to solve them, the question of incoherence raises. See e.g : --> int8(-128)/int8(-1) ans = -128 The message was likely not published on users@. The traffic is (much?) lower on dev@ than on users@. A poor trafic about this topic could also mean that
-- 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 _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Samuel GOUGEON |
Le 19/09/2018 à 11:24, Stéphane Mottelet a écrit :
> Le 19/09/2018 à 11:17, Samuel Gougeon a écrit : >> >> The current implementation is not incoherent. > However, there are still bugs, and when trying to solve them, the > question of incoherence raises. See e.g : > > --> int8(-128)/int8(-1) > ans = > -128 There is no bug here. The division yields 128, that then is wrapped, what yields -128, since in Scilab after the int8 127, 127+1 goes to -128 instead of ceiling to 127 like in Octave: >> int8(-128)/int8(-1) ans = 127 At first sight, Octave's result does not look more consistent than Scilab's one. But following its own ceiling/flooring rules, yet it is consistent. With both possible rules, wrapping or saturating ones, results may appear as inconsistent. But for this example, it is not the case. Samuel _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Le 19/09/2018 à 11:46, Samuel Gougeon a écrit :
> Le 19/09/2018 à 11:24, Stéphane Mottelet a écrit : >> Le 19/09/2018 à 11:17, Samuel Gougeon a écrit : >>> >>> The current implementation is not incoherent. >> However, there are still bugs, and when trying to solve them, the >> question of incoherence raises. See e.g : >> >> --> int8(-128)/int8(-1) >> ans = >> -128 > > There is no bug here. The division yields 128, that then is wrapped, > what yields -128, since in Scilab after the int8 127, 127+1 goes to > -128 instead of ceiling to 127 like in Octave: > >> int8(-128)/int8(-1) > ans = 127 > > At first sight, Octave's result does not look more consistent than > Scilab's one. > But following its own ceiling/flooring rules, yet it is consistent. What is puzzling is that Scilab implements a *mix* of rules comming from different software. I am wondering about the true reason: Scilab: --> int8(-128)/int8(0) ans = -128 --> int8(-128)/int8(-1) ans = -128 Matlab: >> int8(-128)/int8(0) ans = int8 -128 >> int8(-128)/int8(-1) ans = int8 127 > > With both possible rules, wrapping or saturating ones, results may > appear as inconsistent. But for this example, it is not the case. > > Samuel > > _______________________________________________ > users mailing list > [hidden email] > 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 _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Samuel GOUGEON |
Le 19/09/2018 à 12:02, Stéphane Mottelet a écrit :
> Le 19/09/2018 à 11:46, Samuel Gougeon a écrit : > .../... >> >> At first sight, Octave's result does not look more consistent than >> Scilab's one. >> But following its own ceiling/flooring rules, yet it is consistent. > What is puzzling is that Scilab implements a *mix* of rules comming > from different software. I am wondering about the true reason: > > Scilab: > > --> int8(-128)/int8(0) > ans = > > -128 This is in Scilab 6. In Scilab 6, int8(-%inf) has been set to the int8 floor, and int8(%inf) to the int8 ceil. It is more consistent than the 5.5 behavior (and is now documented in the 6.0 branch). Also, 6.0 uses ieee() in a consistent way for encoded integers. That was not the case with Scilab 5.5. This change would deserve being documented. So here, the sign is correct, the value as well. > > --> int8(-128)/int8(-1) > ans = > -128 > > Matlab: > > >> int8(-128)/int8(0) > > ans = > > int8 > > -128 > > >> int8(-128)/int8(-1) > > ans = > > int8 > > 127 All these results are consistent in their own referential. I don't catch where you see a mix of rules. It is anyway necessary to set a fixed value for int8(%inf) and int8(-%inf). These inputs are not "infinitely wrappable" :) To set them to the bounding values is not absurd. This is what Scilab 6.0 does now. To me, it is an improvement. Samuel _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Samuel GOUGEON |
In reply to this post by mottelet
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. 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 [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Antoine Monmayrant |
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 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 > [hidden email] > http://lists.scilab.org/mailman/listinfo/users > _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Hello Antoine
> Le 19 sept. 2018 à 13:28, antoine monmayrant <[hidden email]> 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 >> [hidden email] >> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users >> > > _______________________________________________ > users mailing list > [hidden email] > https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
In reply to this post by Antoine Monmayrant
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 ... 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 >> [hidden email] >> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users >> >> > > _______________________________________________ > users mailing list > [hidden email] > 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 _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
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 >>> [hidden email] >>> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users >>> >>> >> >> _______________________________________________ >> users mailing list >> [hidden email] >> https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/users >> > > _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Samuel GOUGEON |
Le 19/09/2018 à 15:36, antoine monmayrant a écrit :
> 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.... This is why uman() has a redirection list: --> uman polyval w brings you to the horner page and more than 200 other redirections that could be easily included in help(), with a switch in the Preferences (to use the automatic redirection or not). horner() is also applicable to rationals. I am happy to use -- and have to document and maintain -- a single same function to evaluate both polynomials and rationals. So, this example shows that a generic polynomials page is missing, or/and that the polynomial tag could be added to the currently existing most appropriated page. Anyone is welcome to write this page, or/and to indicate which existing one would be the best hook to polynomial features. Samuel _______________________________________________ users mailing list [hidden email] http://lists.scilab.org/mailman/listinfo/users |
Free forum by Nabble | Edit this page |