Richard and Bob Correct! In everything you say. [x,y,z] is, in LC space, a single dimensional space and especially about use case. But then you are limiting yourself to single dimensional thinking. Here is my next point that I was coming to, so well done for preempting me.
Going back a bit, in a traditional sense, we think of time as being a fourth dimension, which it is, but also it isn't, depending on your POV. It is 'a' fourth dimension, but not 'the' fourth dimension. X,Y and Z can be thought of as our three spacial dimensions. But t (time) is separate to spacial dimensions. Other spacial dimensions (not string theory which is now not a thing) include but are not limited to heading/direction, inside/outside, flip/reverse. Other dimensions not related to time or space could be thought of as mass (G, weight (kind-of, but not really)), fields (theoretical) and maybe energy. Representing these in LC, ALL spacial dimensions could be held in a single dimension (theoretically), [u,v,w,x,y,z,...]. Time in it's own dimension [t]. Mass in it's own [m]. And so on. tObject[u,v,w,x,y,z,...][t][m][e]... That works fine for that 'kind' of dimensional array. Let's use IP addresses as another. A first would be our WAN (Wide Area Network) address made up of, in simple terms, ISP, County/City, State, Country, eg, [186,11,47,10]. Then our LAN (Local Area Network) address which we can think of as Building, Floor, Area, Terminal, eg, [127,4,2,103]. So far we have [186,11,47,10][127,4,2,103], 8 dimensions in a 2 dimension array. tAddr[tWAN1[1],tWAN1[2],tWAN1[3],tWAN1[4]][tLAN1.1,tLAN1.2,tLAN1.3,tLAN1.4] as an example of structure. As Richard mentioned, using [186,11,47,10][127,4,2,103] is neither better or worse than using [186,11,47,10][127][4][2][103]. However, one may be more useful/flexible/managable than the other. In most cases in a given WAN location, the LAN root host address is often 127 throughout, so you might want to link the floor number in with it, like [127,tFloorNum] and still have the area and terminal number in seperate sub arrays. But what are the advantages for and against. Let's assume that a building has 100 floors, 10 areas per floor and 20 terminals per area. If we use the [186,11,47,10][127,4,2,103] method for just this one location with a string of tab delimited data as each ones value, we would be storing in the keys of tAddr[186,11,47,10] 20,000 LAN addresses, 1 per line. This makes it easier to filter in a search but using a lineOffset or scan through for the addr's 127,99,9,19 to 127,100,10,10 would take much longer than 127,1,9,19 to 127,2,10,10. Using the [186,11,47,10][127,4][2][103] would be far more convoluted to filter search depending on the method used. Access times to the value data within this addr would be fast indeed. but getting a list of existing terminal addresses from this method would be longer than the previous where you simply request the keys of [186,11,47,10]. But my biggest case for Super Sub Arrays is File System Indexing. Coming next .... Sean On Thu, 11 Mar 2021 at 16:35, Bob Sneidar via use-livecode < [email protected]> wrote: > <soapbox> > A well put answer to that egregious question that haunts ALL who are > problem solvers: “Which is better?” > A person might mean, better for your pocketbook, Long term/short term, > better to configure, better performance, better support, better looking, > better sounding... > > Really, this is a perennial problem with all people in all vocations. We > don’t necessarily need more information, we need more understanding. Then > we will learn to ask the right kind of questions. > </soapbox> > > :-) > > Bob S > > > On Mar 11, 2021, at 8:03 AM, Richard Gaskin via use-livecode < > [email protected]<mailto:[email protected]>> > wrote: > > LiveCode is very flexible, giving us many options for structuring data > according to the needs of the task at hand. Which is "better" or "more > useful" depends on the problem being solved. > > -- > Richard Gaskin > Fourth World Systems > > _______________________________________________ > use-livecode mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
