type of structs and cells

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

type of structs and cells

Hi all,

I hope some of you are still reading this list, which has a very low
traffic these days... I just discovered, while working on

https://codereview.scilab.org/#/c/20491/

https://codereview.scilab.org/#/c/19114/

that cells have the same type number, although a different type string.
Hence, when you want to differentiate between structs, cells, lists,
mlists, tlists, you cannot rely on typeof(), since for mlists and tlists
they return the usertype, neither on type(), since it does not make the
difference between cells and structs. I know there exist isstruct() and
iscell(), but why do we have the same type number ??

S.





--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet
_______________________________________________
dev mailing list
[hidden email]
http://lists.scilab.org/mailman/listinfo/dev
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: type of structs and cells

Le 12/09/2018 à 17:02, Stéphane Mottelet a écrit :

> Hi all,
>
> I hope some of you are still reading this list, which has a very low
> traffic these days... I just discovered, while working on
>
> https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/codereview.scilab.org/#/c/20491/ 
>
>
> https://antispam.utc.fr/proxy/2/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/codereview.scilab.org/#/c/19114/ 
>
>
> that cells
and structs

> have the same type number, although a different type string. Hence,
> when you want to differentiate between structs, cells, lists, mlists,
> tlists, you cannot rely on typeof(), since for mlists and tlists they
> return the usertype, neither on type(), since it does not make the
> difference between cells and structs. I know there exist isstruct()
> and iscell(), but why do we have the same type number ??
>
> S.
>
>
>
>
>

--
Stéphane Mottelet
Ingénieur de recherche
EA 4297 Transformations Intégrées de la Matière Renouvelable
Département Génie des Procédés Industriels
Sorbonne Universités - Université de Technologie de Compiègne
CS 60319, 60203 Compiègne cedex
Tel : +33(0)344234688
http://www.utc.fr/~mottelet

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

Re: type of structs and cells

In reply to this post by mottelet
Hello Stéphane,

Le 12/09/2018 à 17:02, Stéphane Mottelet a écrit :
Hi all,

I hope some of you are still reading this list, which has a very low traffic these days... I just discovered, while working on

https://codereview.scilab.org/#/c/20491/

https://codereview.scilab.org/#/c/19114/

that cells have the same type number, although a different type string. Hence, when you want to differentiate between structs, cells, lists, mlists, tlists, you cannot rely on typeof(),

I guess you meant that we must use the typeof() instead of type(). Anyway,...

since for mlists and tlists they return the usertype, neither on type(), since it does not make the difference between cells and structs. I know there exist isstruct() and iscell(), but why do we have the same type number ??

I had the same question in mind for 2 years. So thanks for asking it here explicitly!

Since in Scilab 6 cells and structs are now native types, it could have been the opportunity and the right moment to ascribe a dedicated type() number to each of them, out of their historical mlist type number 17.

We may imagine that this conservatism is to avoid back-compatibility issues.
However, when we look for the "17" pattern in the whole native *.sci Scilab files, we get only 85 possibly relevant hits in 58 files (*.sci *.sce *.tst *.dia.ref *.c *.cpp *.java *.xml), over thousands of files.
The full list is attached.

This is much fewer than for some other features removed from 5.5 for 6.0. By the way, contrarily to a syntactic change like []+n that can't be tracked in the code, parsing any external user code for "[^.0-9a-zA-Z%_:"'*/+-;]17[^.0-9a-zA-Z%_:"'*/+-;<]" is very simple, to get on the spots and update relevant occurrences.

So, to me, ascribing dedicated and separate type() numbers to cells and structures is still a relevant question, for Scilab 6.1.
Scilab 6 aims to be more consistent. Ascribing new type codes to now native cells and structures looks possible at low cost.

Best regards
Samuel


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

type_17_HITS_601_sci_sce_tst_c_cpp_java_xml.txt (11K) Download Attachment
mottelet mottelet
Reply | Threaded
Open this post in threaded view
|

Re: type of structs and cells

Le 12/09/2018 à 21:48, Samuel Gougeon a écrit :

Hello Stéphane,

Le 12/09/2018 à 17:02, Stéphane Mottelet a écrit :
Hi all,

I hope some of you are still reading this list, which has a very low traffic these days... I just discovered, while working on

https://codereview.scilab.org/#/c/20491/

https://codereview.scilab.org/#/c/19114/

that cells have the same type number, although a different type string. Hence, when you want to differentiate between structs, cells, lists, mlists, tlists, you cannot rely on typeof(),

I guess you meant that we must use the typeof() instead of type(). Anyway,...

since for mlists and tlists they return the usertype, neither on type(), since it does not make the difference between cells and structs. I know there exist isstruct() and iscell(), but why do we have the same type number ??

I had the same question in mind for 2 years. So thanks for asking it here explicitly!

Since in Scilab 6 cells and structs are now native types, it could have been the opportunity and the right moment to ascribe a dedicated type() number to each of them, out of their historical mlist type number 17.

We may imagine that this conservatism is to avoid back-compatibility issues.

There is more than that. For Scilab 6 structs, for k=1,2 getfield(k,...) returns the same result as Scilab 5.5.2

--> str=struct("a",1,"b",1)
 str  =

  a: [1x1 constant]
  b: [1x1 constant]


--> getfield(1,str)
 ans  =

!st  dims  a  b  !


--> getfield(2,str)
 ans  =

  1  1

as if str, in this example, was still a mlist. This is so artificial, but certainely necessary !
However, when we look for the "17" pattern in the whole native *.sci Scilab files, we get only 85 possibly relevant hits in 58 files (*.sci *.sce *.tst *.dia.ref *.c *.cpp *.java *.xml), over thousands of files.
The full list is attached.

This is much fewer than for some other features removed from 5.5 for 6.0. By the way, contrarily to a syntactic change like []+n that can't be tracked in the code, parsing any external user code for "[^.0-9a-zA-Z%_:"'*/+-;]17[^.0-9a-zA-Z%_:"'*/+-;<]" is very simple, to get on the spots and update relevant occurrences.

So, to me, ascribing dedicated and separate type() numbers to cells and structures is still a relevant question, for Scilab 6.1.
Scilab 6 aims to be more consistent. Ascribing new type codes to now native cells and structures looks possible at low cost.

Best regards
Samuel



_______________________________________________
dev mailing list
[hidden email]
https://antispam.utc.fr/proxy/1/c3RlcGhhbmUubW90dGVsZXRAdXRjLmZy/lists.scilab.org/mailman/listinfo/dev


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

Re: type of structs and cells

Le 12/09/2018 à 22:08, Stéphane Mottelet a écrit :

Le 12/09/2018 à 21:48, Samuel Gougeon a écrit :

Hello Stéphane,

Le 12/09/2018 à 17:02, Stéphane Mottelet a écrit :
Hi all,

I hope some of you are still reading this list, which has a very low traffic these days... I just discovered, while working on

https://codereview.scilab.org/#/c/20491/

https://codereview.scilab.org/#/c/19114/

that cells have the same type number, although a different type string. Hence, when you want to differentiate between structs, cells, lists, mlists, tlists, you cannot rely on typeof(),

I guess you meant that we must use the typeof() instead of type(). Anyway,...

since for mlists and tlists they return the usertype, neither on type(), since it does not make the difference between cells and structs. I know there exist isstruct() and iscell(), but why do we have the same type number ??

I had the same question in mind for 2 years. So thanks for asking it here explicitly!

Since in Scilab 6 cells and structs are now native types, it could have been the opportunity and the right moment to ascribe a dedicated type() number to each of them, out of their historical mlist type number 17.

We may imagine that this conservatism is to avoid back-compatibility issues.

There is more than that. For Scilab 6 structs, for k=1,2 getfield(k,...) returns the same result as Scilab 5.5.2

--> str=struct("a",1,"b",1)
 str  =

  a: [1x1 constant]
  b: [1x1 constant]


--> getfield(1,str)
 ans  =

!st  dims  a  b  !


--> getfield(2,str)
 ans  =

  1  1

as if str, in this example, was still a mlist. This is so artificial, but certainely necessary !

I must confess that i did not catch how the bug 15034 has been processed.
I feel rather concerned about its processing. It looks to create an
"hybrid/duplicate" type/typeof for struct(), so killing the announcement they
are native type in Scilab 6.
To me, AFAIU, this is a confusing and worrying way to fix the bug 15234.
Unless struct are finally not native at all in Scilab 6. If so, the CHANGES file
and the documentation should be fixed to cancel the announcement.




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

Re: type of structs and cells

In reply to this post by mottelet
Le 12/09/2018 à 22:08, Stéphane Mottelet a écrit :

Le 12/09/2018 à 21:48, Samuel Gougeon a écrit :

Hello Stéphane,

Le 12/09/2018 à 17:02, Stéphane Mottelet a écrit :
Hi all,

I hope some of you are still reading this list, which has a very low traffic these days... I just discovered, while working on

https://codereview.scilab.org/#/c/20491/

https://codereview.scilab.org/#/c/19114/

that cells have the same type number, although a different type string. Hence, when you want to differentiate between structs, cells, lists, mlists, tlists, you cannot rely on typeof(),

I guess you meant that we must use the typeof() instead of type(). Anyway,...

since for mlists and tlists they return the usertype, neither on type(), since it does not make the difference between cells and structs. I know there exist isstruct() and iscell(), but why do we have the same type number ??

I had the same question in mind for 2 years. So thanks for asking it here explicitly!

Since in Scilab 6 cells and structs are now native types, it could have been the opportunity and the right moment to ascribe a dedicated type() number to each of them, out of their historical mlist type number 17.

We may imagine that this conservatism is to avoid back-compatibility issues.

There is more than that. For Scilab 6 structs, for k=1,2 getfield(k,...) returns the same result as Scilab 5.5.2

--> str=struct("a",1,"b",1)
 str  =

  a: [1x1 constant]
  b: [1x1 constant]


--> getfield(1,str)
 ans  =

!st  dims  a  b  !


--> getfield(2,str)
 ans  =

  1  1

as if str, in this example, was still a mlist. This is so artificial, but certainely necessary !


I don't see why. In reading mode, it is possible to retrieve all struct information in a more direct and handy way:

--> getfield(1,str)
 ans  =
!st  dims  a  b  !

typeof(str)  // returns "st" : OK
fieldnames(str)  // returns ["a" "b"] : OK

--> getfield(2,str)
 ans  =
  1  1

size(str)      // returns dims values: OK

In addition:
getfield(3, s) // returns the list of values for the "a" field

clear s
s.a = %pi
s(1,2).a = %i
s(1).t = "Hi"
s(2).t = "Bonjour"

getfield(3, s)

// But s(:).a returns the same, without using getfield().
// => So getfield() is now useless for struct()

s(:).a

--> getfield(3, s)
 ans  =
       ans(1)
   3.1415927

       ans(2)
   i  

--> // But s(:).a returns the same, without using getfield(). So getfield() is now useless for struct()
--> s(:).a
 ans  =
       ans(1)
   3.1415927

       ans(2)
   i  

So: usage of getfield() with structures could and should now be completely prevented.

The main issue with new native structures is that, for an array of structures, it is no longer possible to set the whole set of values of a field , neither with a .field syntax nor with setfield()...

But it is hard to see why it could not be implemented, or at least reimplemented with setfield(), without reintroducing struct as mlist().

Samuel



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