[Scilab-users] Confusion about types (typeof vs. Variabe Browser)

classic Classic list List threaded Threaded
8 messages Options
fmiyara fmiyara
Reply | Threaded
Open this post in threaded view
|

[Scilab-users] Confusion about types (typeof vs. Variabe Browser)


Dear all,

I'm trying to elucidate some details regarding types. The most basic type, corresponding to real or complex decimal numbers (or vectors, matrices and hypermatrices with this kind of components) is called "constant" by the function typeof (and so listed in the documentation).

However, the variable browser lists them as "double".

This is somewhat confusing. It seems that "double" refers to the way each individual component is encoded while constant may refer to the fact that any array containing doubles is o type constant.

In the case of integers, for instance we have int64 as reported by typeof, but in the Variable Browser it is listed a bit more in full as "Integer 64". While this is also slightly inconsistent, it is not to complain very much about.

In the case of rationals, typeof returns "rational" while the Variable Browser callsit "r (Tlist)"

Cell array type is called "ce" by typeof but "Cell" in the Variabe Browser

User-defined types in tlists and mlists are designed by the user-defined type name by typeof, while the variable browser adds "(Tlist)" or "(Mlist)"

Functions, libraries and impliit lists such as $ are not listed in the variable bowser but are correctly reported by typeof

I wonder whether there is a reason for all this or it is actually an issue that could be fixed in a future versions.

Thank you

Regards,

Federico Miyara
 

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

Re: Confusion about types (typeof vs. Variabe Browser)


Dear all,

Regarding the question I've sent a few days earlier (see below), I think the Variable Browser in some cases may be creating confusion between variable types and number formats


For instance,

a = 1.22

creates a variable of type "constant", while its format is "double".

Regards,

Federico Miyara


On 29/11/2019 02:57, Federico Miyara wrote:

Dear all,

I'm trying to elucidate some details regarding types. The most basic type, corresponding to real or complex decimal numbers (or vectors, matrices and hypermatrices with this kind of components) is called "constant" by the function typeof (and so listed in the documentation).

However, the variable browser lists them as "double".

This is somewhat confusing. It seems that "double" refers to the way each individual component is encoded while constant may refer to the fact that any array containing doubles is o type constant.

In the case of integers, for instance we have int64 as reported by typeof, but in the Variable Browser it is listed a bit more in full as "Integer 64". While this is also slightly inconsistent, it is not to complain very much about.

In the case of rationals, typeof returns "rational" while the Variable Browser callsit "r (Tlist)"

Cell array type is called "ce" by typeof but "Cell" in the Variabe Browser

User-defined types in tlists and mlists are designed by the user-defined type name by typeof, while the variable browser adds "(Tlist)" or "(Mlist)"

Functions, libraries and impliit lists such as $ are not listed in the variable bowser but are correctly reported by typeof

I wonder whether there is a reason for all this or it is actually an issue that could be fixed in a future versions.

Thank you

Regards,

Federico Miyara
 


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

Re: Confusion about types (typeof vs. Variabe Browser)

Hello,

The name "constant" has been kept to ensure backwards compatibililty. But frankly, sometimes legacy really sucks !

To me, "constant" should be replaced everywhere by "double" to suppress this confusion. The argument that it would break some toolboxes does not hold : we already will have to recompile almost all binary gateways for the next release of Scilab. I don't understand why toolboxes authors would not be able to release a new version by just doing an easy find/replace in their codes.

S.

Le 04/12/2019 à 02:07, Federico Miyara a écrit :

Dear all,

Regarding the question I've sent a few days earlier (see below), I think the Variable Browser in some cases may be creating confusion between variable types and number formats


For instance,

a = 1.22

creates a variable of type "constant", while its format is "double".

Regards,

Federico Miyara


On 29/11/2019 02:57, Federico Miyara wrote:

Dear all,

I'm trying to elucidate some details regarding types. The most basic type, corresponding to real or complex decimal numbers (or vectors, matrices and hypermatrices with this kind of components) is called "constant" by the function typeof (and so listed in the documentation).

However, the variable browser lists them as "double".

This is somewhat confusing. It seems that "double" refers to the way each individual component is encoded while constant may refer to the fact that any array containing doubles is o type constant.

In the case of integers, for instance we have int64 as reported by typeof, but in the Variable Browser it is listed a bit more in full as "Integer 64". While this is also slightly inconsistent, it is not to complain very much about.

In the case of rationals, typeof returns "rational" while the Variable Browser callsit "r (Tlist)"

Cell array type is called "ce" by typeof but "Cell" in the Variabe Browser

User-defined types in tlists and mlists are designed by the user-defined type name by typeof, while the variable browser adds "(Tlist)" or "(Mlist)"

Functions, libraries and impliit lists such as $ are not listed in the variable bowser but are correctly reported by typeof

I wonder whether there is a reason for all this or it is actually an issue that could be fixed in a future versions.

Thank you

Regards,

Federico Miyara
 


_______________________________________________
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: Confusion about types (typeof vs. Variabe Browser)

In reply to this post by fmiyara
Le 29/11/2019 à 06:57, Federico Miyara a écrit :

Dear all,

I'm trying to elucidate some details regarding types. The most basic type, corresponding to real or complex decimal numbers (or vectors, matrices and hypermatrices with this kind of components) is called "constant" by the function typeof (and so listed in the documentation).

However, the variable browser lists them as "double".


Both are sucking legacy (i hope there is no copyright on this expression). But if we should sort awful things, a variable of "constant" is clearly the worst, in my not humble opinion.

"double" is awful as well because personally, as a user in 2019, i strictly don't care about that, 40 years ago, there was a dominating "single precision" encoding, and then came the "double precision" encoding, and everybody was really happy, you know. Still today, we should remember this great event. OK, OK, OK. We are still very happy, indeed.
In Scilab, there is no single precision encoding. May be we should propose implementing it, to look like our so loved eternal and discrete and exclusive inspirator.

For any normal newby, before being twisted-minded by historical and external habits, a "double" is a number, or even better, for interfaces where short and explicit keywords are welcome, a num.ber

And for the same fresh user, what does a string mean? A rope, a chain.
Now, when comprehensive normal -- so very creative -- persons ask why we don't name a byte a string of bits, you know which answer they receive? None. Very strange world, isn't it? Very.
Yet, "Text" is a word even shorter than "String". It tells exactly what this stuff is actually.
In Scilab, a text is NOT a characters string: the basic block is the text, not the character. And part() helps.
But anyway, which user really cares about how texts are encoded? Is it really the matter?


This is somewhat confusing.


Oo yes. Sometimes we pay to get confused. With Scilab, it's free. Get, try, and love it. Or report.

It seems that "double" refers to the way each individual component is encoded while constant may refer to the fact that any array containing doubles is o type constant.

In the case of integers, for instance we have int64 as reported by typeof, but in the Variable Browser it is listed a bit more in full as "Integer 64". While this is also slightly inconsistent, it is not to complain very much about.

In the case of rationals, typeof returns "rational" while the Variable Browser callsit "r (Tlist)"

Cell array type is called "ce" by typeof but "Cell" in the Variabe Browser

User-defined types in tlists and mlists are designed by the user-defined type name by typeof, while the variable browser adds "(Tlist)" or "(Mlist)"

Functions, libraries and impliit lists such as $ are not listed in the variable bowser but are correctly reported by typeof


We can add them in the list, through the Filter menu.

Anyway, beside the "constant" typeof, i personally do not care too much about technical typeof names.
Obviously, it is always highly preferable to choose carefully reserved keywords when creating them.
Some typeof improvements have been done for Scilab 6. And indeed we could wonder why this "constant" typeof has not been changed.
Too frequently used in existing codes? Probably.

But the situation in GUIs is quite different. Back-compatibility issues are somewhat less acute than in the code.
In the variables browser and editor,

  • an array of decimal real numbers could be tagged "num.ber"
  • an array of complex numbers : "complex", despite it is the same "constant" typeof. It's not the topic.
  • a sparse array of complex numbers : "sparse complex"
  • an array of characters string : "text"
  • an array of int64 integers : "int64". It is definitely clear, and shorter than "Integer 64" or "64 bits integers", that tell nothing more or better than "int64"
  • an array of rationals: "rational", indeed.
  • etc

I do not see reasons to make GUIs labels exactly matching the technical typeofs.
But, please convince us.

Cheers
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: Confusion about types (typeof vs. Variabe Browser)

In reply to this post by mottelet
Le 04/12/2019 à 13:30, Stéphane Mottelet a écrit :

>
> Hello,
>
> The name "constant" has been kept to ensure backwards compatibililty.
> But frankly, sometimes legacy really sucks !
>
> To me, "constant" should be replaced everywhere by "double" to
> suppress this confusion. The argument that it would break some
> toolboxes does not hold : we already will have to recompile almost all
> binary gateways for the next release of Scilab. I don't understand why
> toolboxes authors would not be able to release a new version by just
> doing an easy find/replace in their codes.
>

Stéphane,

All ATOMS toolboxes are all together a very tiny part of all existing codes.

Samuel

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

Re: Confusion about types (typeof vs. Variabe Browser)


Le 05/12/2019 à 23:26, Samuel Gougeon a écrit :

> Le 04/12/2019 à 13:30, Stéphane Mottelet a écrit :
>>
>> Hello,
>>
>> The name "constant" has been kept to ensure backwards compatibililty.
>> But frankly, sometimes legacy really sucks !
>>
>> To me, "constant" should be replaced everywhere by "double" to
>> suppress this confusion. The argument that it would break some
>> toolboxes does not hold : we already will have to recompile almost
>> all binary gateways for the next release of Scilab. I don't
>> understand why toolboxes authors would not be able to release a new
>> version by just doing an easy find/replace in their codes.
>>
>
> Stéphane,
>
> All ATOMS toolboxes are all together a very tiny part of all existing
> codes.

Yes. But what is the ratio of "alive" codes ? When I see the
infinitesimal traffic on the ML, I have the feeling that this ratio is
close to zero (but not zero, right ?). The small number of *active*
users (hence having "active" codes) do not have problems to adapt to
(necessary) changes. In the past we had such (yeah, painfull) issues
(empty matrix stuff, among others).

We are no going to prevent improvements because there are some codes,
somewhere, with no maintainer, that could eventually fail after the
improvement. Codes with no maintainers are (most of the time) dead codes.

Please think about the future of Scilab, not always its past.

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

Re: Confusion about types (typeof vs. Variabe Browser)


Le 06/12/2019 à 08:41, Stéphane Mottelet a écrit :
> Please think about the future of Scilab, not always its past.


I do agree with you.
I mentioned in the past that the default colormap was so ugly it should
be considered a bug ( http://bugzilla.scilab.org/show_bug.cgi?id=11054 ).

I proposed changing the default colormap to something sensible and also
proposed adding decent replacement to the abomination that is jetcolormap.
The answer was: "but we can't: backward compatibility".

I think scilab is one of the only plotting soft that is still using
horrible defaults (matlab, python.matplotib, ... all have evolved and
changed to reasonable defaults).


Antoine

_______________________________________________
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: Confusion about types (typeof vs. Variabe Browser)

This is already hijacking the initial thread. I won't go on here after this message.

Le 06/12/2019 à 11:17, Antoine Monmayrant a écrit :

Le 06/12/2019 à 08:41, Stéphane Mottelet a écrit :
Please think about the future of Scilab, not always its past.

For my part, i think about future, taking into account the present.
And the past is also interesting to learn from past successes, and failures.




I do agree with you.
I mentioned in the past that the default colormap was so ugly it should be considered a bug ( http://bugzilla.scilab.org/show_bug.cgi?id=11054 ).

The problem was and is not that the default colormap is ugly, but that it holds for the whole figure, instead of per axes.

I proposed changing the default colormap to something sensible and also proposed adding decent replacement to the abomination that is jetcolormap.


jetcolormap() is jetcolormap(), and is used as a jetcolormap swatch in many other softwares, noticeably thermal imaging ones.
It is one very standard colormap among other ones. I don't see the point about any abomination.

The answer was: "but we can't: backward compatibility".

I think scilab is one of the only plotting soft that is still using horrible defaults (matlab, python.matplotib, ... all have evolved and changed to reasonable defaults).


This is why i am wondering why my open post about changing the default grid style in axes has received strictly no answer, noticably from futurologists. Is it OK with the current defaults? Not for me.
Was it OK with the default ticks and grid style of bode() up to 6.0.1? Not for me. This is why changing them was proposed and accepted in 6.0.2.
Etc, etc etc.

There were actually extremely conservative positions or actions/inactions about some cases -- i am wondering for instance about the disp() inversion --, hardly believable, because almost or definitely without rationale. And we can hope that, for this case, it will be corrected soon.

But these extreme cases -- that are even hard to consider as naive -- do no allow any extreme positions in the opposite, whose main processing could aim to avoid providing rationale as well, in the pretendly opposite direction but for the same reason: it's shorter, and at first sight, it looks easier.

Regards
Samuel



_______________________________________________
users mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/users