Versions des environnements
>Yes, there are a number of possibilties
>You have to find the balance between ease of use and performance
>Personally, I would prefer functions a la SetItem(value, x, y, z, ..) and getItem(@value, x, y, z, ...) to avoid the access and assign methods
>For a couple of dimensions ( say up to 8 or so), SetItem() and GetItem() may be the fastest
>If we start dreaming and go beyond 24 dimensions - we'll need an array - SetItem(value, @dimensions) with the overhead of setting the elements of dimensions before each call
Multiple dimensions were not asked specifically, and if handling needs more than 2 dimensions,
I'd prefer either a xxxValue([setvalue],@Dimensions[,cnAliasIfNotCurrent]) or a totally class based acces
methods with each class having its workingalias and current "Dimensionpointer[s]" as properties.
OTOH when working with sparse matrices it may be best NOT to work in an "loop dimensions step 1"-pattern,
if most of the values are nonexistant and you can jump over the "empty" values using scan or similar
table movement logic, filtering via Rushmore. Pure function coding might lead to such nonoptimized coding.
Class based coding of access routines might generalize any such "optimized"
access pattern, especially if multiple tables are involved.
Too many holes in the specs for my taste to speculate further ;-)
Précédent
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement