<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Calibri">Hello,<br>
<br>
A flag has been introduced to tackle the A+[] operation<br>
</font><tt>help</tt><tt>("</tt><tt>oldEmptyBehaviour")</tt><tt><br>
</tt><tt>oldEmptyBehaviour</tt><tt>("</tt><tt>on")</tt><tt><br>
</tt><tt>1 + []</tt><tt><br>
</tt><tt><br>
</tt><tt>oldEmptyBehaviour</tt><tt>("off")</tt><tt><br>
</tt><tt>1+[]</tt><tt><br>
</tt><font face="Calibri"><br>
</font><br>
<font face="Calibri"><tt>oldEmptyBehaviour</tt><tt>("<font
face="Calibri">query</font>")</tt><tt><br>
</tt><br>
<br>
We kept the warning for both behaviours if users want to migrate
"softly".<br>
This is also done to protect the scripts.<br>
<br>
<br>
</font>
<div class="moz-cite-prefix">Le 19/02/2016 10:08, Serge Steer a
écrit :<br>
</div>
<blockquote cite="mid:56C6DB9B.8070508@inria.fr" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">In Scilab 5 the function mtlb_mode
allows to change the meaning of a+[] according to Scilab or
matlab semantics. This function has been removed in Scilab6. <br>
It can be a solution redefine it as oldscilab_mode that can be
used for old codes<br>
Serge<br>
Le 18/02/2016 20:41, Eric Dubois a écrit :<br>
</div>
<blockquote
cite="mid:CAGgDjFTioCjbgVMnMTUvVEEu+sGDHW1E=aPArDgwiS7qtWgm8w@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:dev@lists.scilab.org">dev@lists.scilab.org</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:dev@lists.scilab.org">dev@lists.scilab.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.scilab.org/mailman/listinfo/dev">http://lists.scilab.org/mailman/listinfo/dev</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dev@lists.scilab.org">dev@lists.scilab.org</a>
<a class="moz-txt-link-freetext" href="http://lists.scilab.org/mailman/listinfo/dev">http://lists.scilab.org/mailman/listinfo/dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">Pierre-Aimé Agnel
</pre>
</body>
</html>