[Scilab-Dev] A+[]
Serge Steer
Serge.Steer at inria.fr
Fri Feb 19 10:08:43 CET 2016
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.
It can be a solution redefine it as oldscilab_mode that can be used for
old codes
Serge
Le 18/02/2016 20:41, Eric Dubois a écrit :
> Hello
>
> I am inclined to share Samuel point of view: this is a compliocation
> than could be avoided.
>
> 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.
>
> Sorry for insisting, but I will again call for the removal from the
> final Scilab 6.0 release of this planned change.
>
> 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.
>
> 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.
>
> 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).
>
> I hope that the Scilab will come to its senses and give up making this
> change.
>
> Regards.
>
> Éric.
>
> 2016-02-18 18:45 GMT+01:00 Samuel Gougeon <sgougeon at free.fr
> <mailto:sgougeon at free.fr>>:
>
> Hello,
>
> Le 29/03/2010 11:40, Bruno JOFRET a écrit :
>> Hi,
>>
>> Please find attached SEP #40 talking about Cell Arrays.
>> This SEP is targeting Scilab 6.0 as we will introduce a new
>> syntax for cells.
>>
>> Any feedbacks are welcome.
>
> 6 years after, it is very (very) late to comment or make any
> suggestion.
> Yet, Scilab 6.0 is not yet released, so i hope that this won't be
> too late for the essential:
> Indexation (extraction and insertion) with {} should really not be
> introduced.
>
> This message comes after first comments and rational recently
> posted there:
> http://mailinglists.scilab.org/Scilab-users-a-i-j-specific-extraction-syntax-with-should-not-be-introduced-tp4033484.html
>
> As another way to explain why {} extractors and inserters must not
> be introduced,
> we may follow the pages of the current version of the SEP
> available here:
> http://gitweb.scilab.org/?p=scilab.git;a=blob;f=SEP/SEP_040_cell_arrays.odt
>
>
> * After a cell array *c = { %pi %i %t ; %z "abc" list(1,%s)}*
> has been (very friendly) built with the new {} heterogeneous
> concatenator:
>
> o the *extraction of the content of any single cell
> component* should be direct:
> + with Scilab < 6 : c(5).entries or c(1,3).entries
> + with Scilab >=6: c(5) or c(1,3)
>
> + with Scilab < 6 : c(5) or c(1,3)
> + with Scilab >=6: {c(5)} or {c(1,3)}
> 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.
>
> o As well, *the insertion into a single component must be
> direct, and any type of data should be accepted*:
> + Scilab < 6: c(5).entries = ["Hi" "Hello"] or
> c(1,3).entries = ["Hi" "Hello"]
> + Scilab >=6: c(5) = ["Hi" "Hello"] or c(1,3) = ["Hi"
> "Hello"]
> So, page 4:
> # c = cell([4,3,2]); for i = 1:24, c*{i}* = i, end
> becomes
> # c = cell([4,3,2]); for i = 1:24, c*(i)* = i, end
>
> o 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.
> 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.
> 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.
> o 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, *as is*.
>
> * *The SEP does not present **_insertion and extraction of
> multiple components_ in a once*.
> After still *c = { %pi %i %t ; %z "abc" list(1,%s)}, *the
> current implementation is the following:
>
> o *multiple insertion*: *a) of corresponding multiple
> components*:
> + c(:,1) = { %e "zz" }
> assigns %e to c(1,1) and "zz" to c(2,1) /in a
> distributive way/!
> 1. This kind of distributive assignment is a very
> great new feature!!
> 2. The assignment is transparently done using
> /linearized indices/. 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
>
> + c(:,1) = list(%e, "zz")
> should do the same. But it does not:
> --> c(:,1) = list(%e, "zz")
> Wrong insertion: A Cell expected: use {...} instead of
> (...).
> This feature might be implemented later. This is not
> so urgent as removing the {} addressing.
>
> If this feature is implemented, how will it be
> possible to insert a list in a single component?
> # c(3) = list(list(%t)) // will do it. Or if the
> size of the list is not 1, even
> # c(3) = list(%t, %z) // mismatch could be
> handled softly in a comprehensive way
>
> + c([1 2]) = { %e "zz" } does the same using a vector of
> linearized indices. Great!
>
> o *multiple insertion*: *b) of a single component to be
> replicated*:
> + c([1 4]) = {"abc"} 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
> c([1 4]) = "abc"
> 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.
>
> o *multiple extraction:*
> + c(1,:) returns{%pi %i %t}: this is great! By
> default, this can't be anything else than a cell array.
> No c{1,:} syntax is required
> + c(:,3) returns {%t ; list(1,%s)}: still great and
> expected!
> No c{3,:} syntax is required
> + c(1:2,[1 3]) returns {%pi %t ; %z list(1,%s)} as
> expected.
> No c{1:2,[1 3]} syntax is required
> + with a linearized index: c([2 5 3]) returns {%z ; %t ;
> %i} column cell, as with matrices addressed with a
> linearized index a column is returned: Great!
> No c{[2 5 3]} syntax is required
>
> * Finally, *what about conversions between a cell array and a
> list? *We think that this kind of conversion between these 2
> types of containers should be available in Scilab.
> o *list => cell* :
> + 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:
> c = cell(2,3); c(:) = list(%pi, %z, %i, "abc", %t,
> list(1,%s))
>
> + Otherwise: *makecell() *should be kept and renamed
> *list2cell()*, instead of being removed. It already
> works as expected :
> L = list(%pi, %z, %i, "abc", %t, list(1,%s));
> --> makecell([2 3], L(:))
> ans =
> [1x1 constant] [1x1 polynomial] [1x1 constant]
> [1x1 string ] [1x1 boolean ] [ list ]
>
> o *cell => list:*
> + The present special extraction with {:} does it, but
> this syntax must be removed. Keeping it only for that
> is meaningless:
> --> typeof(c{:})
> ans =
> list
> + A new *cell2list()* converter should rather be
> implemented.
>
> Hoping that this will convince you to remove the {} complicated
> addressing and the related data wrapping,
>
> Best regards
> Samuel Gougeon
>
>
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org <mailto:dev at lists.scilab.org>
> http://lists.scilab.org/mailman/listinfo/dev
>
>
>
>
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20160219/ebc757d4/attachment.htm>
More information about the dev
mailing list