Le 23/02/2018 à 15:50, Samuel Gougeon a écrit :
No strangeness at all. I was just *asking* why Scilab's behavior is the
one observed. No judgement at all, no claim. Because of a recent change
in my professionnal position I have now enough time to spent a bit of it
about Scilab (many years ago I spent *a lot* of time about it). Sorry
for my "fresh" view of some facts that were discussed a long time ago,
when I did not have time to read the mailing lists...
Le 23/02/2018 à 14:06, Stéphane Mottelet a écrit :
Le 23/02/2018 à 13:45, Stéphane Mottelet a écrit :
I would like to point out the conventions used by Scilab and Matlab
when an integer number is subject to overflow:
Do you see any reason in favor of one of each ?
Maybe monotonicity, but it should be discussed anyway.
This has been already done here or/and on Bugzilla, quite extensively.
Anyway, it can't be changed without breaking completely Scilab and
It is the same for 1.2 * int8(3) that yields an int8 and not a double.
The fact that all these optimizations with a global impact were not
discussed and decided
to prepare the 6.0.0 is indeed a HUGE pity.
There are many ways to kill a software. Breaking things with a global
impact like this +num again,
and next minor release again, and next minor release again on another
point... is an excellent one.
So, sorry, but this kind of (re)discussion and changes must be done
when targeting a major release
for which all things must be rewritten.
And decided and announced to all authors ASAP, not just 1 year before
And since you put this on the table while the 6.0.1 is just released
and we had not the chance
to read you here about that before looks rather strange to me.
users mailing list
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
users mailing list