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

[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".


Aggh


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
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

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

[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".


Aggh

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 

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

[Stéphane Mottelet]

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@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 




--
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 

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

[Stéphane Mottelet]

Hello Antoine 

> Le 19 sept. 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 ...



> 
> 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

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

[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 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
http://lists.scilab.org/mailman/listinfo/users



___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

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

[Samuel Gougeon]

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
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

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

[Samuel Gougeon]

Le 19/09/2018 à 12:25, Samuel Gougeon a écrit :

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).


Here is the Scilab 6.0.0 changelog in the int8 ... iuint64 help page for 
6.0.2:



Would you prefer fixing int32(%inf) in order to keep all answers to 0: 
this would avoid any saturating behavior for the infinite values as for 
finite ones ; or these new settings?



___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

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

[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
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

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

[Stéphane Mottelet]

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

OK


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
users@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

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

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

[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
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

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

[Stéphane Mottelet]

Le 19/09/2018 à 11:17, Samuel Gougeon a écrit :



Le 17/09/2018 à 19:03, Stéphane Mottelet a écrit :

[No answers]

Hello all,

Do I have to conclude that the implementation is currently so 
incoherent that *nobody* uses integer types in Scilab (other than 
Scilab code itself) ?


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


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

  * most of Scilab users working with encoded integers are satisfied.
No answer = status quo.
  * or almost nobody uses Scilab. So, never mind any deep changes. You
can do whatever you want on a relic.

Best regards
Samuel



___
users mailing list
users@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

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

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

[Samuel Gougeon]

Le 17/09/2018 à 19:03, Stéphane Mottelet a écrit :

[No answers]

Hello all,

Do I have to conclude that the implementation is currently so 
incoherent that *nobody* uses integer types in Scilab (other than 
Scilab code itself) ?


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

 * most of Scilab users working with encoded integers are satisfied. No
   answer = status quo.
 * or almost nobody uses Scilab. So, never mind any deep changes. You
   can do whatever you want on a relic.

Best regards
Samuel

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

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

[Stéphane Mottelet]

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...


S.

While introducing an actually new feature breaks nothing.

Regards
Samuel

___
users mailing list
users@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

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

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

[Samuel Gougeon]

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
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

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

[Samuel Gougeon]

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,

Integer types in Scilab are not smoothly implemented and there are 
still some bugs and real questions to be discussed, specifically on 
over/underflow, exceptions in divisions such as in


int8(1)/int8(0)

int8(-128)/int8(-1)

type of the result of mixed double/integer operations, such as

int8(1) + %pi

int8(1)/0.0

and so on. Other software related to Scilab, e.g. Matlab and Julia, 
have different conventions and currently Scilab currently adopts a mix 
of them, which does not help to make one's mind.


Integers types were a long-waited feature by people who needed it, so 
I would like to have some  developpers and user testimonies about the 
way they do algebra with them.


Thanks in adavance,

S.



Le 17/09/2018 à 19:03, Stéphane Mottelet a écrit :

[No answers]

Hello all,

Do I have to conclude that the implementation is currently so 
incoherent that *nobody* uses integer types in Scilab (other than 
Scilab code itself) ?


S.


___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

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

[Stéphane Mottelet]

Le 19/09/2018 à 09:03, amonm...@laas.fr 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.

Can you precise the languages (besides C and C++) ?

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
users@lists.scilab.org
https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/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 







--
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
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

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

[philippe]

Le 19/09/2018 à 09:03, amonm...@laas.fr 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
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

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

[amonmayr]

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?

Antoine


S.



Best regards,

Philippe


___
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



--
+++

 Antoine Monmayrant LAAS - CNRS
 7 avenue du Colonel Roche
 BP 54200
 31031 TOULOUSE Cedex 4
 FRANCE

 Tel:+33 5 61 33 64 59
 
 email : antoine.monmayr...@laas.fr

 permanent email : antoine.monmayr...@polytechnique.org

+++

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

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

[Stéphane Mottelet]

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
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

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

[philippe]

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
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users