This might be better on the chat forum, but: (1) "table" -- we've got lots of existing uses of that term. For example: https://www.jsoftware.com/help/dictionary/samp07.htm
Specifying a table as "just a dictionary with ..." could conflict with those uses (existing tables have rank and shape. But what's the shape of a dictionary? (2) I can't make heads nor tails of "A dictionary is a table with just one key and 1 value." And I just get completely lost after that. Use cases (or: useful examples) are probably what we need here. Thanks, -- Raul On Wed, Nov 20, 2019 at 11:04 AM 'Pascal Jasmin' via Programming <programm...@jsoftware.com> wrote: > > Here are the goals I have for a dictionary class. > A table is just a dictionary with (potentially multiple) key(s) and multiple > values. A dictionary is a table with just one key and 1 value. > Underlying storage should be at the most performant data type: If all keys > or value (columns) are of the same/compatible types then they should be > stored as such types. Only boxed if the "field" contains incompatible types. > Object creation of the table/dictionary can impose type and shape > restrictions. > To accomplish the above, a list class that boxes items only when an item > incompatible with the rest of the list is added is needed. Then columns just > use that class interface to add/update values. > The tradeoff is append/update checks/slowdowns in order to be able to obtain > "clean" raw data/columns, but also avoid boxing if checks allow it. The > checks may have less of a performance penalty than "upserting" > (append/update) boxed structures. > restricting types of table/dic at creation, further eliminates the checks, > relying on errors when an incompatible type is added. > An alternative simpler design is to have separate classes for > dictionary/table maintained with boxed items, and one with raw items. Most > applications do not require variable field types. Types and shape(with fill) > restrictions can still be added at creation time in order to coerce values to > that type. For boxed storage, items are boxed without checks. So both class > types have better performance. > > sugar functions for trimming variable shape columns (such as strings) make > sense, and a default numeric list fill value of __ may be better than 0. _. > is an option for fill value, but may harm performance more. __ or _. instead > of 0 makes a floating point datatype storage though. Using a magic > MAX/MIN_int would solve this, but create a bug in someone sometime's > application that would be hard to track. > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
