[Scilab-Dev] A+[]
Pierre-Aimé Agnel
pierre-aime.agnel at scilab-enterprises.com
Fri Feb 19 10:36:50 CET 2016
Hello,
A flag has been introduced to tackle the A+[] operation
help("oldEmptyBehaviour")
oldEmptyBehaviour("on")
1 + []
oldEmptyBehaviour("off")
1+[]
oldEmptyBehaviour("query")
We kept the warning for both behaviours if users want to migrate "softly".
This is also done to protect the scripts.
Le 19/02/2016 10:08, Serge Steer a écrit :
> 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
>
>
>
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/dev
Pierre-Aimé Agnel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20160219/40d6e342/attachment.htm>
More information about the dev
mailing list