Perhaps it's worth noting that you can achieve separability without hierarchy, using coinsert.
You still need to know the name of the owning locale to populate (and incorporate) it, but if your data is constant that should not be a severe obstacle. You need good naming conventions, but arguably you need that already. You can't overload the use of a name except through explicit reference to a locale, but that should not be a serious problem. There may be performance issues when many locales are included in a copath. I have never studied that issue, nor used long copath values. Finally, note that if you are thinking in database terms, it may be worth spending some time investigating what third normal form would do to your data. -- Raul On Sat, Feb 2, 2013 at 11:10 PM, David Porter <[email protected]> wrote: > The problem I faced in MatLab was to provide temperature data from an > infra-red camera. The data from the camera was in the Air Force's Standard > Archive Format(SAF) that allows all the raw data, calibration constants, and > much ancillary data (such as data units, classification, and data type) to > be saved in several files. The major advantage of using this approach and > the SAF files is that the entire experiment may be reproduced at a later > time to troubleshoot any aspect of the data handling. The major > disadvantage is that several different files are needed, each with a similar > but not identical format, and smaller pieces of the data were needed by > different functions. > > I started using MatLab's structure as a way of pulling all the data from all > the files together under a single variable e.g. q1. Using this variable, I > could easily provide the entirety of the data to a function. > > At times I was only interested in the irradiance to temperature calibration > constants, while at other times I was interested only in the actual raw > data. I could separate out the data I needed and provide that as an > argument to another function by using the hierarchical naming, e.g. > q1.test1.calconstants, The structure notation is simple to use, requiring > only assignments to the properly named entity. Recovering the data was as > easy as typing the same named entity. After using this notation for a > while, I thought of it more as a database construction and query language. > > The need to make a copy of the data comes from assigning the output of a > function to a name. I would like to assign the variable used in the > function (say q1) to a more meaningful name (say replication01). As I > stated above, I could also pass pertinent subsets of data to functions that > worked on that data without burdening the function with all the other data. > > The above are some of the problems that the MatLab Structure solves. Can it > be done other ways? Certainly. But after I worked with this notation in > MatLab, I found it to be a valuable way to store a large amount of data > efficiently. > > An approach much like your example is what I was thinking I would have to do > before I emailed the forum. It may still be where I end up. > > Thanks, > Dave > > > On 2/2/2013 8:28 AM, Raul Miller wrote: >> >> As has been pointed out, J's locales are not hierarchical. >> >> J's boxed structures are hierarchical but are not implicitly named. >> >> A question is: why do you need both a hierarchy and a way of making >> copies of a part of that hierarchy? >> >> Why not use a single copy? >> >> What problem does the hierarchy solve? >> >> It's entirely possible to emulate the hierarchy in J, but there will >> be performance costs for some operation. In your case you had three >> operations: >> >> Defining an initial value >> Copying a subtree >> Accessing a final value >> >> I can think of one approach where access is fast, and another approach >> where copy is fast, for example. But since I do not know why you want >> this in the first place I do not know if either is appropriate. >> >> For example, you might use the letter 'z' to mark hierarchical breaks. >> Here, you would implement copy using a routine which enumerates your >> names and which makes fresh copies of them. >> >> For example, you might use indirect references to achieve your >> hierarchical breaks. Here, you would implement access using a routine >> which visits each locale to find the reference to the next locale. >> >> In either case, if you do not like the appearance of the mechanism >> (and you probably should not find it appealing) you would build >> routines to hide that appearance from arbitrary code. >> > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
