Wed 17 Oct 2012 11:27:42 AM UTC, comment #1:
The proposed solution is valuable for the presented case, but risks to have far-reaching consequences. The unique() actually performs 3 things:
- create a 1D array out of the data
- sort the data
- make sure the data are unique
We could leave out the sorting, in some case also the uniqueness,
but certainly not the array creation.
When designing the property database, it was the intention that properties would be constant data valid for all the items in the specified set. Re-ordering of the items in the set is therefore no problem. It is also a lot cleaner in the output if the items come out sorted.
Adding a 'sort=True' argument (and then possibly also a 'unique=True') would clutter up the Prop interface, where we want to keep the number of predefined keys as small as possible. And it would probably make it confusing to the user as to when to use them.
An alternative would be to renumber the data according to the
results of unique. That would also require an extra field and be confusing.
So I suggest to leave it like it is for now, and explain to the
user that when he provides data that are not constant for all the elements in set, he should first uniquize the set (and his data) before entering them in the property database.
Furthermore I think it is best to concentrate on constant properties for all items in the set. Thus the case of surface
labels could be handled by grouping the elements per label and specifying a separate property record for each of the labels, with the proper subset of the elements.
In a large model with n elements, six subsets with a constant label would much more efficient than a list of n labels.
We should however envision the possibility of data that are continuously changing over the elements. For such cases we should probably create some kind of Field class. A Field class
would then hold data in a way that is only influenced by the number of the elements, not by their order.
I am leaving this bug open until we decide how to proceed.
|