<div dir="ltr">Hello<div><br></div><div>I am inclined to share Samuel point of view: this is a compliocation than could be avoided.</div><div><br></div><div>But I cannot resist noting that the annoucement is 6 years older than the announcement of the weapon of mass destruction that consist in changing the behaviour of the addition of a matrix with a null matrix.</div><div><br></div><div>Sorry for insisting, but I will again call for the removal from the final Scilab 6.0 release of this planned change.</div><div><br></div><div>First, I am not convinced at all by the argument put forward that it will make Scilab more consistent with other language such as Matlab, Octave, Julia.. : after all, every language has its indiosycrasies; a Matlab user will yet have to adapt herslef to this change, bu along many other ones; and I,do not think that changing this behavour will convice any Matlab user to switch to Scilab nor prevent anyone thinking about switching to give up because of this beahviour.</div><div><br></div><div>Second The argument that it enhances Scilab internal consistency is a little bit more compelling, but not much: after all, addition and subtraction are different operations from multiplication and division, such one can justify different behaviour. And there are cases when it make tho code more compact.</div><div><br></div><div>Adnd lastly both arguments are anyway swept away by the simple fact that the change should make all previous code unreliable: you cannot be sure in advance that the working of your program has not been affected by the change (and the warning that is designed to alert to the user is not sufficient: a warning can easily be missed, especially for second hand users not so famaliar with Scilab and if it is hidden among many other warnings).</div><div><br></div><div>I hope that the Scilab will come to its senses and give up making this change.</div><div><br></div><div>Regards.</div><div><br></div><div>Éric.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-02-18 18:45 GMT+01:00 Samuel Gougeon <span dir="ltr"><<a href="mailto:sgougeon@free.fr" target="_blank">sgougeon@free.fr</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Hello,<br>
<br>
Le 29/03/2010 11:40, Bruno JOFRET a écrit :<br>
</div>
<blockquote type="cite">Hi,
<br>
<br>
Please find attached SEP #40 talking about Cell Arrays.
<br>
This SEP is targeting Scilab 6.0 as we will introduce a new syntax
for cells.
<br>
<br>
Any feedbacks are welcome.
<br>
</blockquote>
<br>
6 years after, it is very (very) late to comment or make any
suggestion. <br>
Yet, Scilab 6.0 is not yet released, so i hope that this won't be
too late for the essential: <br>
Indexation (extraction and insertion) with {} should really not be
introduced.<br>
<br>
This message comes after first comments and rational recently posted
there:<br>
<a href="http://mailinglists.scilab.org/Scilab-users-a-i-j-specific-extraction-syntax-with-should-not-be-introduced-tp4033484.html" target="_blank">http://mailinglists.scilab.org/Scilab-users-a-i-j-specific-extraction-syntax-with-should-not-be-introduced-tp4033484.html</a><br>
<br>
As another way to explain why {} extractors and inserters must not
be introduced, <br>
we may follow the pages of the current version of the SEP available
here:<br>
<a href="http://gitweb.scilab.org/?p=scilab.git;a=blob;f=SEP/SEP_040_cell_arrays.odt" target="_blank">http://gitweb.scilab.org/?p=scilab.git;a=blob;f=SEP/SEP_040_cell_arrays.odt</a>
<br>
<ul>
<li>After a cell array <b>c = { %pi %i %t ; %z "abc" list(1,%s)}</b>
has been (very friendly) built with the new {} heterogeneous
concatenator:<br>
<br>
</li>
<ul>
<li>the <b>extraction of the content of any single cell
component</b> should be direct:</li>
<ul>
<li>with Scilab < 6 : c(5).entries or c(1,3).entries</li>
<li>with Scilab >=6: c(5) or c(1,3)<br>
<br>
</li>
<li>with Scilab < 6 : c(5) or c(1,3)</li>
<li>with Scilab >=6: {c(5)} or {c(1,3)}<br>
Whenever any wrapped-in-cell answer would be needed, it
still can be obtain by packaging the answer, instead of
implementing a "dereferencing" way to address a content
through a very specific {} extractors and inserters when
unwrapped values are required.<br>
<br>
</li>
</ul>
<li>As well, <b>the insertion into a single component must be
direct, and any type of data should be accepted</b>:</li>
<ul>
<li>Scilab < 6: c(5).entries = ["Hi" "Hello"] or
c(1,3).entries = ["Hi" "Hello"] </li>
<li>Scilab >=6: c(5) = ["Hi" "Hello"] or c(1,3) = ["Hi"
"Hello"] <br>
So, page 4: <br>
</li>
<ul>
<li>c = cell([4,3,2]); for i = 1:24, c<b>{i}</b> = i, end <br>
becomes <br>
</li>
<li>c = cell([4,3,2]); for i = 1:24, c<b>(i)</b> = i, end <br>
<br>
</li>
</ul>
</ul>
<li>Is there any reason to not address cells components simply
as we do for matrix components, directly with (i,j,..)? I do
not find any.<br>
The .entries addressing was needed due to the encoding of
cells as mlists. But what could motivate keeping any
intermediate level to access to the values of data, for
extraction as well as for insertion? I do not see a single
reason.<br>
As noted here-above, from the fact that the LHS object is a
cell array, any data type can be accepted and inserted,
without any prior packaging of the RHS as a cell array. The
wrapping in cell must be done internally by the insertion
process.</li>
<li>Then, Scilab 6: c(5) = {"abcd"} will insert a true
elementary cell as the c(1,3) c's component, not the string
"abcd". This is a straightforward and very clear syntax. What
is in RHS parameter is just values that are inserted in the
array, <b>as is</b>.<br>
<br>
</li>
</ul>
<li><b>The SEP does not present </b><b><u>insertion and
extraction of multiple components</u> in a once</b>. <br>
After still <b>c = { %pi %i %t ; %z "abc" list(1,%s)}, </b>the
current implementation is the following:<br>
<br>
</li>
<ul>
<li><b>multiple insertion</b>: <font color="#993399"><b>a) of
corresponding multiple components</b>:</font><br>
</li>
<ul>
<li><tt>c(:,1) = { %e "zz" } <br>
</tt>assigns %e to c(1,1) and "zz" to c(2,1) <i>in a
distributive way</i>! <br>
</li>
<ol>
<li>This kind of distributive assignment is a very great new
feature!!</li>
<li>The assignment is transparently done using <i>linearized
indices</i>. unmatching sizes/formats of the recipient
and of the source is smoothly handled. Here, a row of
cells feeds a column of cells. This is nice as is! This
behavior could also be implemented with other types of RHS
containers, at least for a list. So<br>
<br>
</li>
</ol>
<li> <tt>c(:,1) = list(%e, "zz")<br>
</tt>should do the same. But it does not:<tt><br>
--> c(:,1) = list(%e, "zz")<br>
Wrong insertion: A Cell expected: use {...} instead of
(...).<br>
</tt>This feature might be implemented later. This is not so
urgent as removing the {} addressing.<br>
<br>
If this feature is implemented, how will it be possible to
insert a list in a single component?</li>
<ul>
<li><tt>c(3) = list(list(%t))</tt> // will do it. Or if the
size of the list is not 1, even</li>
<li><tt>c(3) = list(%t, %z)</tt> // mismatch could be
handled softly in a comprehensive way<br>
<br>
</li>
</ul>
<li><tt><tt>c([1 2]) = { %e "zz" } </tt></tt> does the same
using a vector of linearized indices<tt>. Great!<br>
<br>
</tt></li>
</ul>
<li><b>multiple insertion</b>: <font color="#993399"><b>b) of a
single component to be replicated</b>:</font><br>
</li>
<ul>
<li><tt><tt>c([1 4]) = {"abc"} </tt></tt>inserts the same
"abc" string at the 1st and 4th positions in c. This is
great! The only thing is that the syntax should become
simply<br>
<tt><tt>c([1 4]) = "abc"<br>
</tt></tt>In the final implementation that we suggest and
hope, c([1 4]) = {"abc"} will be as well possible but will
insert the cell {"abc"} instead of the string "abc" at the
desired positions.<tt><tt><br>
<br>
</tt></tt></li>
</ul>
<li><b>multiple extraction:</b></li>
<ul>
<li><tt>c(1,:)</tt> returns<tt> {%pi %i %t}</tt>: this is
great! By default, this can't be anything else than a cell
array. <br>
No <tt>c{1,:} </tt>syntax is required<br>
</li>
<li><tt>c(:,3)</tt> returns <tt>{%t ; list(1,%s)}</tt>:
still great and expected! <br>
No <tt>c{3,:}</tt> syntax is required</li>
<li><tt>c(1:2,[1 3])</tt> returns <tt>{%pi %t ; %z
list(1,%s)}</tt> as expected. <br>
No <tt>c{1:2,[1 3]}</tt> syntax is required</li>
<li>with a linearized index: <tt>c([2 5 3]) </tt>returns <tt>{%z
; %t ; %i}</tt> column cell, as with matrices addressed
with a linearized index a column is returned: Great! <br>
No <tt>c{[2 5 3]}</tt> syntax is required<br>
<br>
</li>
</ul>
</ul>
<li>Finally, <b>what about conversions between a cell array and a
list? </b>We think that this kind of conversion between these
2 types of containers should be available in Scilab.<br>
</li>
<ul>
<li><b>list => cell</b> : <br>
</li>
<ul>
<li>If it becomes possible to feed a cell array (or subarray)
with a list as discussed above, then this kind of conversion
won't need anything else. We will just have to do:<br>
<tt>c = cell(2,3); c(:) = list(%pi, %z, %i, "abc", %t,
list(1,%s)</tt><tt>) <br>
<br>
</tt></li>
<li>Otherwise: <b>makecell() </b>should be kept and renamed
<b>list2cell()</b>, instead of being removed. It already
works as expected : <br>
L = <tt>list(%pi, %z, %i, "abc", %t, list(1,%s)</tt><tt>);<br>
--> makecell([2 3], L(:))<br>
ans =<br>
[1x1 constant] [1x1 polynomial] [1x1 constant]<br>
[1x1 string ] [1x1 boolean ] [ list ]<br>
<br>
</tt></li>
</ul>
<li><b>cell => list:</b> <br>
</li>
<ul>
<li>The present special extraction with {:} does it, but this
syntax must be removed. Keeping it only for that is
meaningless:<br>
<tt>--> typeof(c{:})</tt><tt><br>
</tt><tt> ans =</tt><tt><br>
</tt><tt> list</tt><br>
</li>
<li>A new <b>cell2list()</b> converter should rather be
implemented.<br>
</li>
</ul>
</ul>
</ul>
<p>Hoping that this will convince you to remove the {} complicated
addressing and the related data wrapping,<br>
</p>
<p>Best regards<span class="HOEnZb"><font color="#888888"><br>
Samuel Gougeon<br>
<br>
</font></span></p>
</div>
<br>_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@lists.scilab.org">dev@lists.scilab.org</a><br>
<a href="http://lists.scilab.org/mailman/listinfo/dev" rel="noreferrer" target="_blank">http://lists.scilab.org/mailman/listinfo/dev</a><br>
<br></blockquote></div><br></div>