David, the disadvantage of the SAF format is intolerable. The file format exemplified in http://www.jsoftware.com/jwiki/IanClark/credo dosn't have this disadvantage. Everything is kept in one file. The information you need is easily extracted from the file. - Bo
>________________________________ > Fra: David Porter <[email protected]> >Til: [email protected] >Sendt: 5:10 søndag den 3. februar 2013 >Emne: Re: [Jprogramming] How best to Port MatLab structure to J > >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
