Multiple Arrays and single Basic Table Field

[BarrySumpter]

Just playing around with LiveCode and arrays and the Basic Table Field.

Say I've got 10 single dimention arrays.

Is there an (I should be asking what is the) easy LiveCode way
to combile the 10 single dimention arrays into a single Basic Table Field.

I've already seen this: 7810-How-do-I-display-an-array-in-a-table-field-
http://lessons.runrev.com/spaces/lesson ... ble-field-
And

http://homepages.rpi.edu/~simonk/technical.html
Materials for Stata and Runtime Revolution

something like this is what I'd be doing in any other language than livecode.

Code: Select all

Repeat with i from 1 to upperbounds(ary1)
 set the tbdata[i] of group table to ary1(i) & cr & ary2(i) & cr & ary3(i) & cr & ary(4)  & cr & ary(5) ... etc
end repeat

I'll research how to constuct a multi-dimentional array later.
For now I'm looking for an easy livecode way to combine arrays.

hmmmm. Is there a Repeast for each in a single dimention array?
How do I know how many occurances/items are in a single dimention array?

[BarrySumpter]

11844-How-do-I-Search-an-Array-
http://lessons.runrev.com/spaces/lesson ... -an-Array-

Code: Select all

...
# first we set up the entries in our SINGLE DIMENTION array
local tArray
put "Adams, Alexander" into tArray[1]
put "Beaumont, Benjamin" into tArray[2]
etc.
...

...
Note: The array key starts at 1 and increments by 1 for each new item that is added.

It is important that you follow this numbering scheme for the binary search algorithm in this example to work.

An item stored in array element 0(zero) would not be found.
...

So the array is 1 based and NOT 0 based. The 0 based always thru me off.

I'm pretty sure now that the secret to
Arrays and their Keys is that the keys to a single dimentional Array are AUTOMATICALLY created.
Which was NOT stated in the example or anywhere else I could find.

Code: Select all

function linearSearch @pArray pItem
    local tIndex
    local tResult

    # return 0 if we cannot find an item in the array
    put 0 into tResult

    # get the keys of the array

    get the keys of pArray    --         Where did these keys come from?  The were automatically created.  Or the get command creates them.
    -- NOTE: The get command is a shorthand way of writing the following statement:
             --   put expression into it   --  that clears some things up with the get comment and the it object

    split it by return

    # visit every array element indexed by a key
    
    repeat for each element tIndex in it         --  Each occurance of an array is called an Element

    # test if the current array element is a match with the item we are looking for
        
     if pArray[tIndex] = pItem then
            put tIndex into tResult
            exit repeat
        end if
    end repeat
    
    return tResult

end linearSearch

The function can be called as follows:

Code: Select all

put linearSearch (tArray, "Best, Tony") into tArrayKey

[BvG]

Here's three examples, each showcasing their strength.

You can use repeat loops to flatten arrays. The first example is small, fast and easy to code, but not flexible in arrangement. because arrays keys are ordered randomly, you would need to sort the result, if you need a specific order. Repeat loops are useful if you want to do something to each key or element (entry) of your array. Here I am converting the elements to show time stamps in a user readable format.

Code: Select all

local theArray
on mouseUp
  repeat for each key theKey in theArray
    convert theArray[theLine] from seconds to system date and system time
    put theArray[theKey] & return after theList
  end repeat
  put theList into field 1
end mouseUp

This second example also use repeat loops. This approach allows to sort the keys before iterating trough them, which is faster then sorting the whole resulting list.

Code: Select all

local theArray
on mouseUp
  put the keys of theArray into theList
  sort theList descending
  repeat for each line theLine in theList
    put theLine & tab & theArray[theLine] & return after theList
  end repeat
  put theList into field 1
end mouseUp

A third example does not use repeat loops, instead using the built in command "combine" to flatten an array. The inverse of combine is "split", i suggest looking them up in the dictionary. This approach is advantageous if you don't care much for ordering the list, or do not want to manipulate each entry individually.

Code: Select all

local theArray
on mouseUp
  combine theArray by return and tab
  put theArray into field 1
end mouseUp

[bn]

Hi Barry,

How do I know how many occurances/items are in a single dimention array?

The easiest is to get the keys of the array which gives you all the keys in a list. Then you get the number of lines of the keys list = the number of entries into the one - dimensional array.

Code: Select all

put the keys of tArray into myKeyList
put the number of lines of myKeyList into tNumberOfKeys

Or if the keys are sequential numbers then you can use the extents functions it gives you the lowest number in the keys and the highest number in the keys

Code: Select all

put extents (tArray) into tLowestAndHighestValue

it returns for an array with the keys from 1 to 20 "1,20"

if you have an array that contains numbers as content then you can use min, max average, sum and a couple of others on the content of the entire array without looking into every entry

Kind regards


@BVG:

Code: Select all

convert theArray[theLine] from seconds to system date and system time

should probably be:

Code: Select all

convert theArray[theKey] from seconds to system date and system time

Bernd

[bn]

some examples for arrays with numeric keys and numeric content:

Code: Select all

on mouseUp
   -- make the array
   repeat with i = 1 to 20
      put i + i into tArray[i]
   end repeat

   put "number of keys = number of entries" &&  the number of lines of the keys of tArray & cr after tCollect
   put "extents" && extents (tArray) & cr & cr after tCollect
   put "Min" && min (tArray) & cr after tCollect
   put "Max" && max (tArray) & cr after tCollect
   put "Sum" && sum (tArray) & cr after tCollect
   put "Average" && average (tArray) & cr after tCollect
   put "Median" && median (tArray) & cr after tCollect
   put "StdDev" && standarddeviation  (tArray) & cr after tCollect
   put tCollect
end mouseUp

Kind regards

Bernd

[BarrySumpter]

Wow! Heaps n heaps of examples to sink me teeth into.
Thanks guys. Much appreciated.

I thought the keys were some random number automatically generated.
But they are actually the ascending index in order of construction.
Might have been getting them mixed up with the random data.

[BarrySumpter]

The Basic Table Field is just a slighly advanced Text Field.

Code: Select all

on mouseUp
   
   -- place a Basic Table Field onto a card and name it tbl1
   
   -- The Basic Table Field is just a slighly advanced Text Field.

   -- setup tArray with embeded tab 
   -- (its the embeded tab that seperates the data into Basic Table Field columns)
   put "A" & tab & "q"  into tArray[1]
   put "B" & tab & "w" into tArray[2]
   put "C" & tab & "e" into tArray[3]
   put "D" & tab & "r" into tArray[4]
   put "E" & tab & "t" into tArray[5]
   put "F" & tab & "y" into tArray[6]
   
   -- setup tArray2
   put "a" into tArray2[1]
   put "b" into tArray2[2]
   put "c" into tArray2[3]
   put "d" into tArray2[4]
   put "e" into tArray2[5]
   put "f" into tArray2[6]
   
   -- setup tArray3
   put "1" into tArray3[1]
   put "2" into tArray3[2]
   put "3" into tArray3[3]
   put "4" into tArray3[4]
   put "5" into tArray3[5]
   put "6" into tArray3[6]
   
   -- retreive the count of elements
   put the keys of tArray into myKeyList
   put the number of lines of myKeyList into tNumberOfKeys
   -- Put the number of lines of the keys of tArray into tNumberOfKeys  -- is a one liner instead of the two above - cool
   
   
   -- Concatinate the data into a single array
   repeat with i = 1 to tNumberOfKeys
      
      put tArray[i] & tab & tArray2[i] & tab & tArray3[i] into tArrayConcatinated[i]
      
   end repeat
   
   
   
   -- setup the array for assigning to the basic table field 
   
   --                                                       After this combine command 
   combine tArrayConcatinated using return 
   --combine tArrayConcatinated using return and tab  -- tab adds array index (1,2,3) column to front of each element
   --                                                       the tArrayConcatinated is NO LONGER an array 
   
   put tArrayConcatinated into field tbl1
   
   
 breakpoint  -- see how table is NOT REALLY sorted 
                   -- mearly listed by index (1,2,3) only 
                   -- i.e. the index order in which the arrays were constructed at very top of this script
   
   -- OK now sort the string (since the combine command turns the tArrayConcatinated array into a string)
   -- sort lines of tArrayConcatinated numeric by word 2 of each   -- Numberic does not work if word 2 is Alphabetic (q,w,e,r,t,y) and returns no error
   sort lines of tArrayConcatinated by word 2 of each  -- Alphabetic - default - no variation of Alpha, Alphabetic, nor Alphabetical would work in place of numeric
   
   put tArrayConcatinated into field tbl1
   
   -- now see how table is sorted by column 2
   
   
end mouseUp

[bn]

Hi Barry,

I thought the keys were some random number automatically generated.
But they are actually the ascending index in order of construction.

The keys are not kept in memory in the order they were generated. This is important because even though one might think so because one constructed the array that way, retrieving the keys and assuming they are in the order you created them is not reliable.
Actually sort them always if you want the keys in your expected order. This is the way associatve arrays work.

KInd regards

Bernd

[BarrySumpter]

Yeah, maybe thats where I got that out of order idea.
But I've tested it and the keys are in order when I use an index.
I tested on a 1000 element array. Thats a long as my attention span would last.

Is there a way to consistantly prove this?
Or perhaps the point is that its NOT consistant so just sort them to be sure.
Yes, OK I'm slow. But there IS a lot to learn.
LOL
And why not sort since it's so freakin simple in LiveCode.
sort theList -- deducing Ascending is default and deducing its defaulting sort on the key
sort theList descending
(better not forget teh potentially really large arrays
and not just a monts worth a daily total or a years worth of montly totals, etc)


Unless its something to do with ( and may be limited to only ) the more efficient
repeat for each key theKey in theArray kinda script


I'll look closer next I read on that topic.

Many thanks!

[FourthWorld]

Yeah, maybe thats where I got that out of order idea.
But I've tested it and the keys are in order when I use an index.
I tested on a 1000 element array. Thats a long as my attention span would last.

Is there a way to consistantly prove this?

On the use-livecode list Alex Tweedly suggested this recipe:

The form "repeat for each element" will
process the elements in the order of the keys of the array. Normally this
is the correct order (because split by only a primary separator produces an
array whose keys are consecutive integers), but there is no guarantee that
they will always be.

And I've found at least one case where they're not - I have a spreadsheet
which works just fine up to 3904 lines - but add one more line and it fails
completely.
(verified by "put the keys of pData after msg")

http://lists.runrev.com/pipermail/use-l ... 45496.html

[BarrySumpter]

And I've found at least one case where they're not - I have a spreadsheet
which works just fine up to 3904 lines - but add one more line and it fails
completely.
(verified by "put the keys of pData after msg")

Changing

Code: Select all

    repeat for each element k in pData

to

Code: Select all

   repeat with tCounter = 1 to the number of lines in the keys of pData
     put pData[tCounter] into k

solves it. Obviously it will be slower - but "slow and correct" beats "fast
and wrong"

Seems my deductions were correct.

I wish I could see his code and data for the spreadsheet.
Could be DataOverflow.

And that looks to be targeted to Unix in 2004.
Just over 7 years ago.
Perhaps the LIveCode, OS, and hardware improvements since then have turned this into an urban ledgend as well.

Might me interesting to see what trouble I could get into experimenting on one of those 'I need a distraction' days.
Say 4000 random numbers as compared to 4000 paragraphs of text.
(can't recall the exact name of the topic someone around LiveCode created a routine to generate random length mispelled words for paragraph text samples.)

[FourthWorld]

And that looks to be targeted to Unix in 2004.
Just over 7 years ago.
Perhaps the LIveCode, OS, and hardware improvements since then have turned this into an urban ledgend as well.

"As well"? What other things do you consider "urban legends"?

And what does Unix have to do with it? IIRC Mr. Tweedly was using Windows.

In this case, the effectiveness of that specific recipe may or may not yield the same result for you, but the underlying principle is well known and freely discussed by the engineer who made it. It's the result of the hashing scheme used to store the data, and the result is that the order you put things into an array with the "split" command is not always the order in which they come back to you with the "combine" command.

This is noted in the Dictionary entry for the "combine" command:

Note: The order of the elements is not alphabetical or chronological; it is based on the internal hash order of the array. To alphabetize the list, use the sort command:

combine monthlyReceivables using return and comma
sort lines of monthlyReceivables by item 2 of each

[BarrySumpter]

Code: Select all

-- Normalize line endings:
>   replace crlf with cr in pData          -- Win to UNIX
>   replace numtochar(13) with cr in pData -- Mac to UNIX
>   --

In this case, the effectiveness of that specific recipe may or may not yield the same result for you, but the underlying principle is well known and freely discussed by the engineer who made it.

Not yeilding the same results is what I'm writting about.
Still no timeline on or reproducable evidence. 7 years being very very long in IT years.
So for me, doesn't mean its current nor does it mean it will actually every come up again.
I'm trying to make sure I'm not basing this concept on a single or few out of date occurances.
Its my right to question any and every thing.
As peviously mentions, its too easy to sort with a single script line of 2 to 4 words.
With large sorts being the main concern.
And, for me, more than effortless discussing further without further current testing and reproducable proof.

[mwieder]

Barry-

Arrays in LiveCode are what is referred to as "hashes" or "associative arrays" in some other languages, if you're coming from a different environment. And there's no guarantee that the input order will be maintained. There isn't in other languages as well, especially if garbage collection is involved. If you want to ensure an order to an array it's best to use numeric indices and sort the result. Actually, now that arrays are first-class objects in LiveCode I think numeric indices may maintain their order - it's a different type of array under the hood.

[BarrySumpter]

Acknowledged.
Will do.