combine scrambles array

[macsmith]

new user having problems with the combine function. An example below shows the creation of a string containing "1234567890", each element of the string copied into an array and the array converted back to a string with the combine function. The new string contains "1023456789".

Can someone point out my mistake or is there a problem with combine?

TIA

on mouseUp
local myString, myArray
put "1234567890" into myString
repeat with loop = 1 to the length of myString
put char loop of myString into myArray[loop]
end repeat
combine myArray by empty
end mouseUp

[dunbarx]

Hi.

No mistake. LC arrays are purely associative, and you cannot rely on any sort order being maintained when creating an array variable from an ordinary variable. This should never matter, since:

1- all array operations can proceed without issue, since only the relationship between keys and their associated elements are accessible
2- you can sort the data once you bring it back into the real world, that is after combining it

So, bottom line, if you have a sorted list that you "split" into an array, do whatever you need to in array mode. Then when you need to "see" it again, sort the data after combining. You can see this in the debugger, if you create an array and step through the handler. The array will appear the way LC feels like assembling it, not the way you fed it. But this should never matter.

Craig Newman

[macsmith]

many thanks for the explanation.

Unfortunately I cannot sort the array afterwards, as it stands, because there is no way of knowing how it should be sorted. My numerical sequence was just to show the effect. The application takes in a random string, converts the characters to ascii, does some arithmetic and converts the ascii back to a string.

Perhaps I need to explore having a numerical key with which to sort it later...

Thanks


Macsmith

[SparkOut]

Can you explain a little more about the operations you need to do? It doesn't sound like you actually need to use arrays/split/combine for this, LC has great text/chunk/char handling, so you might be able to do a (very fast)
repeat for each char tChar in tString
--do some conversion, mathematics and conversion back to string on tChar
put tChar after tNewString
end repeat

That would keep the order the same as the original string.

[macsmith]

thanks. I am new to livecode and agree that string handling shouldn't be this difficult!

I need to read in some string, convert each character of the string to ascii, add something to the ascii value, convert the values back to characters and and re-assemble them into a string, in the right order!

Thanks

Macsmith

[SparkOut]

Well this will add 15 to the ASCII value of each character in the string

Code: Select all

put "1234567890" into tString
   repeat for each char tChar in tString
      put numToChar(charToNum(tChar)+15) after tNewString
   end repeat
put tNewString

It will work, although as of LC 7 charToNum and numToChar are deprecated for more specific options to cater for native text/unicode. You may need to adjust the use of charToNum to become nativeCharToNum and numToChar to numToNativeChar for native text. For unicode (which seems not to be the case as you already mention ASCII) you could investigate numToCodePoint and codepointToNum.

[macsmith]

fantastic! Got that to work. Off to read the other functions you mentioned.

Many thanks

Macsmith

[RobertC]

Hi.

No mistake. LC arrays are purely associative, … … . The array will appear the way LC feels like assembling it, not the way you fed it. But this should never matter.

Craig Newman

Craig, I disagree. I just lost several hours trying to figure out why combine produced an unexpected result. There are cases where it does matter. Without going into details, the problem stems from the absence of real arrays in LiveCode. Currently there are only associative arrays. Real arrays are indexed by consecutive integers (or enumeration types, but that is syntactic sugar really).
A split produces an array with keys that look like consecutive integers. LiveCode prides itself on "natural" language programming, with as a corollary that there should be as few unexpected results as possible.
I quote from the API:
sort lines of tData descending numeric by item 1 of each
likewise we should have
combine myArray ascending numeric
which would do the combining by interpreting the keys as numbers (instead of strings) and starting from the lowest one.

In fact, I can't think of an example where the order of combining would NOT matter!

The solution that Macsmith is happy with would have worked for me if chunk addressing inside large strings were not so prohibitively slow. I needed to do an operation on each line in a text of over 2000 lines. Using split the time needed was reduced by a factor of 200. However, the combine then did not produce the expected result, the operative word here being expected. It took me a lot of time to realise why I got bad results. Finally I combined the array using a loop to add each line at the end of a result string. That takes a lot of time but it works. It is an explicit implementation of combine myArray ascending numeric.

[FourthWorld]

http://forums.livecode.com/viewtopic.ph ... 294#p76467

Also, from 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

[jiml]

Prior to splitting could you prefix each line of text with an incrementing number and space?
Then split and do your text manipulation.
Then combine and sort numeric ascending.
Finally strip the first word (the number) from each line.

[FourthWorld]

Using split the time needed was reduced by a factor of 200.

Split is somewhat computationally expensive, only slightly faster in the engine than we could script in a repeat loop (array hashing is complicated business).

If you're interest in split is primarily for performance, there may be other ways we could achieve it, possibly even faster.

Can you post the code for the older routine you'd found slower, and the revised version with split?

[magice]

Since I came to LC from C++, I started out using an array at the heart of every app I wrote. It has only been in the past few months, that I have come to realize that LC has such easy methods of navigating within a single variable, that arrays are not that necessary. instead of referencing "myArray[6][8]" you just say "item 8 of line 6 of my variable". Now granted that may be a little bit longer, but I find that it is still much easier than using do commands within repeat loops. and worrying about the 10th and 11th element coming before the second after a split because computers just order things that way. It also makes it much easier to trouble shoot issues with variable values, since you can see a whole line or even the whole field of data. I find that coding search handlers is much easier as well. The transition from the "array is better" mentality that I had has not been an easy one, but now that I have seen the light I may never use large arrays again.