[Scilab-Dev] A+[]
Eric Dubois
grocer.toolbox at gmail.com
Sat Feb 20 08:37:05 CET 2016
Thank you for the information
1) do you plan to maintain this feature forever?
If not (as I suspect, maybe mistakenly), then for me it does not solve the
main problem which is the daunting ask of adapting old code (especially if
it is emboddied in a toolbox) and the risk of missing something.
If yes, then:
2) for functions in toolboxes, the answer should rather be something like
that :
function [...]
if evstr(part(getversion(),8:10)) >= 6 then
function [...]
if evstr(part(getversion(),8:10)) >= 6 then
oldEmptyBehaviour("on")
end
[...]
if evstr(part(getversion(),8:10)) >= 6 then
oldEmptyBehaviour("off")
end
endfunction
This is because there will remain users that will continue loading
toolboxes (in particular through Atoms) under old Scilab versions and I
think important that the toolboxes go on working for these users.
The result is not very elegant, but I can survive with it. But please do
not change the working of the getversion function! And more importantly,
please do not remove anytime the oldEmptyBehaviour function.
Regards
Éric.
2016-02-19 10:36 GMT+01:00 Pierre-Aimé Agnel <
pierre-aime.agnel at scilab-enterprises.com>:
> 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>:
>
>> 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:
>>
>> - 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.
>>
>> - 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
>>
>> - 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.
>> - 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:
>>
>> - *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!
>>
>> - *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.
>>
>> - *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.
>> - *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 ]
>>
>> - *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
>> http://lists.scilab.org/mailman/listinfo/dev
>>
>>
>
>
> _______________________________________________
> dev mailing listdev at lists.scilab.orghttp://lists.scilab.org/mailman/listinfo/dev
>
>
>
>
> _______________________________________________
> dev mailing listdev at lists.scilab.orghttp://lists.scilab.org/mailman/listinfo/dev
>
>
> Pierre-Aimé Agnel
>
>
> _______________________________________________
> 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/20160220/d3632cc2/attachment.htm>
More information about the dev
mailing list