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

classic Classic list List threaded Threaded
19 messages Options
Philippe Roux Philippe Roux
Reply | Threaded
Open this post in threaded view
|

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

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

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

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

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

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

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

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

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

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.
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
>>> [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 Samuel GOUGEON
Reply | Threaded
Open this post in threaded view
|

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

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,

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

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

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

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

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

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

In reply to this post by 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
[hidden email]
http://lists.scilab.org/mailman/listinfo/users
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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


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

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

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

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

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