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
_______________________________________________
users mailing list
[email protected]
http://lists.scilab.org/mailman/listinfo/users
