[Scilab-users] Overflow convention for integer types

classic Classic list List threaded Threaded
5 messages Options
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

[Scilab-users] Overflow convention for integer types

Hello,

I would like to point out the conventions used by Scilab and Matlab when
an integer number is subject to overflow:

Scilab 6.0.1:

--> uint8(255)+1
  ans  =

   0

Matlab R2017b

 >> uint8(255)+1

ans =

   uint8

    255

Do you see any reason in favor of one of each ?

S.


--
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
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: Overflow convention for integer types

Le 23/02/2018 à 13:45, Stéphane Mottelet a écrit :

> Hello,
>
> I would like to point out the conventions used by Scilab and Matlab
> when an integer number is subject to overflow:
>
> Scilab 6.0.1:
>
> --> uint8(255)+1
>  ans  =
>
>   0
>
> Matlab R2017b
>
> >> uint8(255)+1
>
> ans =
>
>   uint8
>
>    255
>
> Do you see any reason in favor of one of each ?
>
> S.
>
>
Maybe monotonicity, but it should be discussed anyway.

S.

--
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
Rafael Guerra Rafael Guerra
Reply | Threaded
Open this post in threaded view
|

Re: Overflow convention for integer types


See some advantages of saturation overflow in article:
https://en.wikipedia.org/wiki/Saturation_arithmetic


-----Original Message-----
From: users [mailto:[hidden email]] On Behalf Of Stéphane Mottelet
Sent: Friday, February 23, 2018 2:06 PM
To: International users mailing list for Scilab. <[hidden email]>
Subject: Re: [Scilab-users] Overflow convention for integer types

Le 23/02/2018 à 13:45, Stéphane Mottelet a écrit :

> Hello,
>
> I would like to point out the conventions used by Scilab and Matlab
> when an integer number is subject to overflow:
>
> Scilab 6.0.1:
>
> --> uint8(255)+1
>  ans  =
>
>   0
>
> Matlab R2017b
>
> >> uint8(255)+1
>
> ans =
>
>   uint8
>
>    255
>
> Do you see any reason in favor of one of each ?
>
> S.
>
>
Maybe monotonicity, but it should be discussed anyway.

S.

--
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
_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
Samuel GOUGEON Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

Re: Overflow convention for integer types

In reply to this post by mottelet
Le 23/02/2018 à 14:06, Stéphane Mottelet a écrit :

> Le 23/02/2018 à 13:45, Stéphane Mottelet a écrit :
>> Hello,
>>
>> I would like to point out the conventions used by Scilab and Matlab
>> when an integer number is subject to overflow:
>>
>> Scilab 6.0.1:
>>
>> --> uint8(255)+1
>>  ans  =
>>
>>   0
>>
>> Matlab R2017b
>>
>> >> uint8(255)+1
>>
>> ans =
>>
>>   uint8
>>
>>    255
>>
>> Do you see any reason in favor of one of each ?
>>
>> S.
>>
>>
> 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
external modules.
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
the release.

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.

Best regards
Samuel

_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: Overflow convention for integer types

Le 23/02/2018 à 15:50, Samuel Gougeon a écrit :

> Le 23/02/2018 à 14:06, Stéphane Mottelet a écrit :
>> Le 23/02/2018 à 13:45, Stéphane Mottelet a écrit :
>>> Hello,
>>>
>>> I would like to point out the conventions used by Scilab and Matlab
>>> when an integer number is subject to overflow:
>>>
>>> Scilab 6.0.1:
>>>
>>> --> uint8(255)+1
>>>  ans  =
>>>
>>>   0
>>>
>>> Matlab R2017b
>>>
>>> >> uint8(255)+1
>>>
>>> ans =
>>>
>>>   uint8
>>>
>>>    255
>>>
>>> Do you see any reason in favor of one of each ?
>>>
>>> S.
>>>
>>>
>> 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
> external modules.
> 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
> the release.
>
> 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.
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...

S.

>
> Best regards
> Samuel
>
> _______________________________________________
> users mailing list
> [hidden email]
> http://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