[Scilab-users] a{i, j} specific extraction syntax with {} should not be introduced

[Samuel Gougeon]

Hello Cédric,

Thanks for your answer. I am aware of what cells are.
I understand the reported error messages.
The new {} heterogeneous concatenators are ones of the best new features 
that Scilab 6 offers.
But i strongly disagree with the present implementation of {} as 
extractors and inserters,
because they are not user-oriented, look useless, and are unhandy.

Your answer does not provide any example that could not be dealt with () 
instead of {},
i.e. for which no unambiguous implementation with () could exist.

I am answering to some points in the thread of your message, with a user 
point of view:

Le 18/02/2016 11:03, Cedric Delamarre a écrit :
> Hello Samuel,
>
> Cells are specific container which can contain any types of Scilab, but
> each element of a Cell matrix is a Cell. So, the rules for a Cell are
> same than the rules for a matrix of something.
>
> This feature is consistent with matrix extraction because when you
> extract from or insert to a matrix of constant, the result is a matrix
> of constant.
.
Sorry, but this rational looks absolutely not user-oriented.
When a user builds a cell array, he/she is aware that it is a container 
of mixed data,
not a matrix with the same type of objects. The fact that actually all 
objects are wrapped
in a elementary cell to look with the same type is an internal 
consideration.
The matrix becomes a matrix of pointers toward objects. OK. Pointers 
have all the same
type: pointer. OK. And then? If users want to deal with homogeneous 
pointers,
they code in C/C++,  not in Scilab language.
There is no reason to expect extracting from a cell array, one by one, 
objects that all
have the same type = "cell", since it is chosen to be an heterogeneous 
container!
And the user rather wishes to use a syntax to insert or extract parts of 
the array in a way that
is the most simple, direct, intuitive and unambiguous as possible. And 
so the nearest
to the matrix syntax as possible.
This is why addressing cells contents with the same symbols () as used 
for matrix,
and only these ones, should be of high priority.
> For example:
> m = [1 2 3];
> m(1:2) // extracts a matrix of constant
> m(4) = 4 // inserts a constant
> s = ["this" "is a" "string"];
> s(1:2) // extracts a matrix of strings
> s(4) = "true?" // inserts a string
> a={1, %s, "test"};
> a(1:2) // extracts a matrix of cells
> a(4) = {5} // inserts a cell
Exactly the same could be done with a(4) = 5. There is absolutely no 
ambiguity about what the user wish to do there. Is there?

> This insert a cell at the forth position of "a" as you can insert a
> constant in a matrix of constant and not a string.
>
> For example:
> m(5) = "5"// m is an homogeneous container not of type string => Error is OK
> s(5) = 5// s is an homogeneous container not of type decimal => Error is OK
> a(5) = 5// a is an heterogeneous container accepting *any* type of data => 
> This could and should be handled
>
> But, because Cells array can contain any Scilab types, we need a new
> operator to insert another type in a cell.
>
> a{4} = [5 5 5]
> This insert the matrix of constant at the forth position of "a".
a(4) = [5 5 5]  // could handle it exactly in the same way

> a{4} = {5 5 5}
> This insert the Cell array at the forth position of "a".
a(4) = {5 5 5}  // could handle it exactly in the same way.
Since size([4],"*")~=size({5 5 5}, "*"), there is absolutely no 
ambiguity about what must be done.
If there was, a(4) = { {5 5 5} } could be used.

By the way, to use a syntax completely consistent, why {5 5 5} is used 
instead of { {5} {5} {5}} in your example?
As far as i understand, the result of {5 5 5} is a 1x3 array of cells, 
so cells that are horizontally concatenated:
External { ..} concatenate them, and the listed objects should be cells, 
not direct data.
But { 5 5 5 } *automatically* wraps listed data in a cell before 
concatenating them.
This is exactly the type of automatism that should be silently performed 
on every scalar data involved in cells,
as well for extraction and insertion, what we claim for.

> a(4:6) = {5 5 5}
> This insert each cell elements in "a".
OK for that. It is straightforward, and unambiguous.
For this kind of operation, the distributive assignment is performed
*with absolutely no respect with unmatching sizes/formats of the 
recipient and of the source*.
Only the linearized indices of components are used. Example:
c = {%pi %i %t ; %z "abc" list(1,"a")}
--> c(:,1) = { 1 2 }     // an horizontal array feeds a column, and *it 
is fine and OK!*
  c  =
   [1x1 constant]  [1x1 constant]  [1x1 boolean]
   [1x1 constant]  [1x1 string  ]  [    list   ]

*This is why using a list() as linearized/serialized data source could 
and should do exactly the same*:
c([3 1 2]) = list("cde", %s, %e) // should be accepted and performed in 
a /distributive/ way, whereas
c([3 1 2]) = {list("cde", %s, %e)} // isaccepted but performed in a 
/replicative/ way.

> ../..
When the JIMS module was published as a part of Scilab, there were two 
main issues concerning usages and users:
* The first one was about wrapping/unwrapping java objects from/into 
scilab objects.
    These wrapping/unwrapping operations were implemented, but were not 
done automatically.
    Yet, afterwards, they have been set as the default mode in order to be
    done in a transparent way for users. And it is very great, because 
most users
    do not want to deal with internal handlings. They have an object and 
only one,
    and they don't care about the way it is encoded on the Scilab side 
or on the java side.

* The second issue was about indexing numbers, that started at 0 instead 
of 1 as
    with any other type of scilab object. This was modified in order to 
keep an
    homogeneous indexation policy.

With the present implementation of cells, we have exactly the same kind 
of issues.
{} insertion and extraction operators should really be abandoned.
*Or, again, please provide cases for which these**would be demonstrated 
as mandatory*.
And single data should be automatically wrapped or unwrapped from their 
cell
container in a transparent way. When there could be an ambiguity at 
insertion,
the user can always force the wrapping by using some {} around the data 
source.

I haven't found any SEP presenting usages of new {} as extractors, 
inserters, and concatenators.
It would be great to have a pointer about such a document.
Otherwise, i am afraid that we would miss a great opportunity to make 
Scilab really
friendly to deal with mixed data. Improvements could be done with 
existing structures.
And mistakes should be avoided before launching new cells features.

{} extractors/inserters look to have been implemented in memory of the 
former .entries
mlist field. But this way to address contents was directly connected to 
the technical way
cells were encoded, as mlists. Cells are no longer mlists. Please forget 
completely  .entries
and remove a{} addressing.

Best regards
Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20160218/170ce73d/attachment.htm>