[Scilab-Dev] SEP #40: Cell Arrays
Samuel Gougeon
sgougeon at free.fr
Thu Feb 18 18:45:53 CET 2016
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20160218/c6825d76/attachment.htm>
More information about the dev
mailing list