Dyalog Forums

neeraj wrote:1. Are we using an array because that is what we know
or
2. An array is the best solution even if we had a tree structure.

I think this depends on what you are trying to do. In general, trees seem to be comfortable to users of scalar-oriented (and compiled) languages, while arrays are a more comfortable fit for "parallel" APL notation. There is probably a cross-over zone which we should investigate. But we need some real problems to solve before we can discuss about how comfortable different data structures are.

Thinking about (what I have seen of) XQuery and other tools for manipulating XML, these seem to be trying to take what I would call an "array view" of the XML, applying something similar to SQL (which is very much "an array language") to the trees :-) I think tree structures are pretty uncomfortable to work when you are trying to do any form of "analytics". You can't see the data for all the trees.

Re string manipulation: As Andy and Dan have hinted, this is on our hit list, we have some ideas that we will be playing with in 2010 / v13.

Regarding trees, I agree with Morten that it would be good to find some real-life examples on which to ponder.

For what it's worth, the "refs" function in dfns.dws http://www.dyalog.com/dfnsdws/n_refs.htm traverses a namespace tree and returns a structure of all space-references it finds. At first I thought the result should reflect the structure of the namespace tree but it turns out that a flat vector of refs is more convenient (I think).

John.

Given that with refs one can build not just trees but connected graphs with loops, I think a flat vector of refs is the only possible result...

Yss, my comment wasn't quite general enough. I should have said: "At first I thought the result should reflect the structure of the namespace graph ...

The same argument holds as we can also represent graphs with reasonable ease in APL http://www.dyalog.com/dfnsdws/n_Graphs.htm but, as before, I think the flat vector of refs is better.

neeraj wrote:I was exposed to []XML for the first time at the APL conference and the first thought that crossed my mind was that xml is inherently a tree like structure and is it the case that

1. Are we using an array because that is what we know
or
2. An array is the best solution even if we had a tree structure.

I have to admit to having written an XML processor in Dyalog in 2003-4.

It was the most thoroughgoing use I made of my homebaked class/object framework. The New function took an XML string, did all the necessary parsing and returned an instance which exposed methods: Attributes, Character, Child, Children, Comments, Content, CDATA, Default, Element, Elements, Instructions, Parse, Root, Source, Tree & Type.

Each took an argument that was usually some kind of text selection on the possible candidates. Of these, Child, Children, Element, Elements, Root & Tree returned either one or more other instances of the same XML class.

Basically, having done all the work on the first pass, you still had it all to do to find what you wanted.

Give me arrays every time.

I think that for some kind of applications such as manipulating nested directory structures a tree structure would be useful. Now we can arrayize a tree by storing metadata in an array which would describe the leaf or node of the tree and we can still get our work done. But that is kind of silly. If you look at APL itself, all arrays are stored as linear memory with metadata about how to interpret the linear memory for e.g. as a 2 x 3 matrix. The APL programmer is not burdened with this housekeeping, the system keeps track of it. Similarly, I am sure that there are other data-structures which might come in handy without the APL programmer having to do bookkeeping. For e.g., following Dyalog selective assignment syntax a new tree could be assigned to a node.

(Tree1.node.(name='My Documents'))<- New Tree


etc.

Reminded Arthur Whitney of a conversation a couple of years ago in which he spoke of having been drawn in K towards Lisp’s tree-like lists, now finding himself leaning back towards APL’s rectangular arrays.

yes. but just with x?y (in apl: dyadic iota).
the general lists in k are immensely useful and subsume apl almost perfectly.

in k3, x?y looked for y in x.
but now x?y looks for rank(x)-1 things of y in x.
(i think apl itself went through some mods like this)

so vector?vector will look for scalars and have vector result.
so matrix?matrix will look for vectors and have vector result.