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
