<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><font color="#009900">Hello Cédric,<br>
<br>
Thanks for your answer. I am aware of what cells are. <br>
I understand the reported error messages. <br>
The new {} heterogeneous concatenators are ones of the best new
features that Scilab 6 offers. <br>
But i strongly disagree with the present implementation of {} as
extractors and inserters,<br>
because they are not user-oriented, look useless, and are
unhandy.<br>
<br>
Your answer does not provide any example that could not be dealt
with () instead of {}, <br>
i.e. for which no unambiguous implementation with () could
exist.<br>
<br>
I am answering to some points in the thread of your message,
with a user point of view:<br>
<br>
</font>Le 18/02/2016 11:03, Cedric Delamarre a écrit :<br>
</div>
<blockquote cite="mid:1455789784.2595.103.camel@blink" type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<font color="#009900">.<br>
Sorry, but this rational looks absolutely not user-oriented.<br>
When a user builds a cell array, he/she is aware that it is a
container of mixed data, <br>
not a matrix with the same type of objects. The fact that actually
all objects are wrapped<br>
in a elementary cell to look with the same type is an internal
consideration. <br>
The matrix becomes a matrix of pointers toward objects. OK.
Pointers have all the same <br>
type: pointer. OK. And then? If users want to deal with
homogeneous pointers, <br>
they code in C/C++, not in Scilab language. <br>
There is no reason to expect extracting from a cell array, one by
one, objects that all <br>
have the same type = "cell", since it is chosen to be an
heterogeneous container! <br>
And the user rather wishes to use a syntax to insert or extract
parts of the array in a way that <br>
is the most simple, direct, intuitive and unambiguous as possible.
And so the nearest <br>
to the matrix syntax as possible.<br>
This is why addressing cells contents with the same symbols () as
used for matrix, <br>
and only these ones, should be of high priority.<br>
</font>
<blockquote cite="mid:1455789784.2595.103.camel@blink" type="cite">
<pre wrap="">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</pre>
</blockquote>
<font color="#009900">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?<br>
</font><br>
<blockquote cite="mid:1455789784.2595.103.camel@blink" type="cite">
<pre wrap="">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" <font color="#009900">// m is an homogeneous container not of type string => Error is OK</font>
s(5) = 5 <font color="#009900">// s is an homogeneous container not of type decimal => Error is OK</font>
a(5) = 5 <font color="#009900">// a is an heterogeneous container accepting <b>any</b> type of data => This could and should be handled</font>
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".
</pre>
</blockquote>
<font color="#009900">a(4) = [5 5 5] // could handle it exactly in
the same way<br>
</font><br>
<blockquote cite="mid:1455789784.2595.103.camel@blink" type="cite">
<pre wrap="">a{4} = {5 5 5}
This insert the Cell array at the forth position of "a".</pre>
</blockquote>
<font color="#009900">a(4) = {5 5 5} // could handle it exactly in
the same way. <br>
Since size([4],"*")~=size({5 5 5}, "*"), there is absolutely no
ambiguity about what must be done.<br>
If there was, </font><font color="#009900"><font color="#009900">a(4)
= { {5 5 5} } could be used.<br>
</font><br>
By the way, to use a syntax completely consistent, why {5 5 5} is
used instead of { {5} {5} {5}} in your example?<br>
As far as i understand, the result of {5 5 5} is a 1x3 array of
cells, so cells that are horizontally concatenated:<br>
External { ..} concatenate them, and the listed objects should be
cells, not direct data. <br>
But { 5 5 5 } <b>automatically</b> wraps listed data in a cell
before concatenating them.<br>
This is exactly the type of automatism that should be silently
performed on every scalar data involved in cells, <br>
as well for extraction and insertion, what we claim for.<br>
</font>
<font color="#009900"><br>
</font>
<blockquote cite="mid:1455789784.2595.103.camel@blink" type="cite">
<pre wrap="">a(4:6) = {5 5 5}
This insert each cell elements in "a".</pre>
</blockquote>
<font color="#009900">OK for that. It is straightforward, and
unambiguous.<br>
For this kind of operation, the distributive assignment is
performed <br>
<b>with absolutely no respect with unmatching sizes/formats of the
recipient and of the source</b>. <br>
Only the linearized indices of components are used. Example:<br>
</font><font color="#009900"><tt>c = {%pi %i %t ; %z "abc"
list(1,"a")}</tt><tt><br>
</tt><tt>--> c(:,1) = { 1 2 } // an horizontal array feeds
a column, and <b>it is fine and OK!</b></tt><tt><br>
</tt><tt> c = </tt><tt><br>
</tt><tt> [1x1 constant] [1x1 constant] [1x1 boolean]</tt><tt><br>
</tt><tt> [1x1 constant] [1x1 string ] [ list ]</tt></font><font
color="#009900"><br>
<br>
<b>This is why using a list() as linearized/serialized data source
could and should do exactly the same</b>:<br>
</font><font color="#009900"><tt>c([3 1 2]) = list("cde", %s, %e)
// shou</tt><tt>ld be accepted and performed in a <i>distributive</i>
way, whereas<br>
</tt></font><font color="#009900"><tt>c([3 1 2]) = {list("cde",
%s, %e)} // is</tt><tt> accepted but performed in a <i>replicative</i>
way.<br>
</tt></font><br>
<blockquote cite="mid:1455789784.2595.103.camel@blink" type="cite">
<pre wrap="">../..</pre>
</blockquote>
<font color="#009900">When the JIMS module was published as a part
of Scilab, there were two main issues concerning usages and users:<br>
* The first one was about wrapping/unwrapping java objects
from/into scilab objects. <br>
These wrapping/unwrapping operations were implemented, but were
not done automatically. <br>
Yet, afterwards, they have been set as the default mode in
order to be <br>
done in a transparent way for users. And it is very great,
because most users <br>
do not want to deal with internal handlings. They have an
object and only one, <br>
and they don't care about the way it is encoded on the Scilab
side or on the java side.<br>
<br>
* The second issue was about indexing numbers, that started at 0
instead of 1 as <br>
with any other type of scilab object. This was modified in
order to keep an <br>
homogeneous indexation policy.<br>
<br>
With the present implementation of cells, we have exactly the same
kind of issues.<br>
{} insertion and extraction operators should really be abandoned.
<br>
<b>Or, again, please provide cases for which these</b><b> would be
demonstrated as mandatory</b>.<br>
And single data should be automatically wrapped or unwrapped from
their cell <br>
container in a transparent way. When there could be an ambiguity
at insertion, <br>
the user can always force the wrapping by using some {} around the
data source.<br>
<br>
I haven't found any SEP presenting usages of new {} as extractors,
inserters, and concatenators.<br>
It would be great to have a pointer about such a document.<br>
Otherwise, i am afraid that we would miss a great opportunity to
make Scilab really <br>
friendly to deal with mixed data. Improvements could be done with
existing structures.<br>
And mistakes should be avoided before launching new cells
features.<br>
<br>
{} extractors/inserters look to have been implemented in memory of
the former .entries <br>
mlist field. But this way to address contents was directly
connected to the technical way<br>
cells were encoded, as mlists. Cells are no longer mlists. Please
forget completely .entries<br>
and remove a{} addressing.<br>
<br>
Best regards<br>
Samuel<br>
</font><br>
</body>
</html>