Kinda a lame array problem that i've run into twice. Also does anyone know anything about #define In autoit

[markyrocks]

For one reason or another I've come into the issue where i want to store a 1d array inside of another 1d array and i've figured out how to read from it but for reasons beyond me I can't write to it.

dim $a[10]

dim $b[10]

for $x=0 to ubound($b)-1
    $b[$x]=$x+1
next

$a[0]=$b 

msgbox('','',($a[0])[3],1) ;<~~~~~~~this is fine

($a[0])[3]=99 ;<~~~this is broken...

So That being said i can make a copy of the offending array and do whatever i want to it and copy it back.   It just kills me bc like you know its in there....you can read from it..You can drop in a function parameter that takes an array and I believe it will modify it  If its byref. That wouldn't be that big of a deal if i could just make a lambda...   I realize that the easy solution is to just create a 2d array but cmon who wants to take the easy way out...Regardless its interesting behavior.  

The other question I have was does anyone know anything about #define in autoit? Creating custom symbols or whatever? I've noticed that i can put it in a script and do stuff like

#define abcdxyz $abc

and it doesn't seem to give any errors but it doesn't seem to do anything either.  I know i've seen it used searching around the in the files included for autoit to use internally or whatever but that was awhile ago.  It would be nice if I could make some custom symbols or overload some operators.  Idk how to explain it but i'm looking to get any kinda special variable or function behavior that can possibly be had.    

 

[pixelsearch]

32 minutes ago, markyrocks said:

i want to store a 1d array inside of another 1d array and i've figured out how to read from it but for reasons beyond me I can't write to it.

Hi markyrocks

Here is one way to write to it :

dim $a[10]
dim $b[10]

for $x=0 to ubound($b)-1
    $b[$x] = $x+1
next

$a[0] = $b

msgbox('', '', ($a[0])[3]) ;<~~~~~~~this is fine (4)

; ($a[0])[3] = 99 ;<~~~this is broken...

_ASA($a[0], 3, 99)
msgbox('', '', ($a[0])[3]) ;<~~~~~~~this is fine again (99)

;===== Assign to Sub-Array (ASA) ======
Func _ASA(ByRef $array, $iIndex, $Value)
    $array[$iIndex] = $Value
EndFunc   ;==>_ASA

 

[markyrocks]

7 hours ago, pixelsearch said:

Hi markyrocks

Here is one way to write to it :

 

 

Thanks.  Ya i did figure that out.  its just an odd situation. 

For as much as i've been writing the last few days... all these lil nuances really start to really start to rear their ugly lil heads.  I suppose i should be happy that theres at least one way to deal with it.  

 

Anyone know how to do hex math on here......this is why i get so frustrated bc 

dim $a[20]
dim $b[20]

for $x=0 to ubound($b)-1
    $b[$x] = hex($x)
next

$a = $b
_ArrayDisplay($a)   ;<~~~~~good

msgbox('','',$b[0x0000000f],1) ;<~~~~~~~~~~~good

msgbox('','',$b[$a[5]],1) ;<~~~~~~~~~~~fine..

msgbox('','',$b[$a[15]],1) ;<~~~~~~~~~~~no good

msgbox('','',$b[$a[16]],1) ;<~~~~~~~~~~~no good result is wrong...

seems fairly obvious that if the hex is 0000000-00000009 its fine bc it looks at it like a number.... a real hex number works no problems.  but if the return is from another variable it gets view as a string... do i really have to save the initial number as binary and bring it back.  Dammit its just unbelievable some of the wild ass behavior i run into.

It just gets so annoying so quick especially if you'r on step 15 in a chain of events that you expect something like the above will behave like any rational person would expect it to and then capow the hand gernade goes off.... 

edit:so apparently if i put the number is as binary it displays it in the opposite direction so hopefully that will fix it

omg i've been beating around the bush with this for awhile now bc i was wondering why i was experiencing such buggy behavior and thats the fix...

dim $a[20]
dim $b[20]

for $x=0 to ubound($b)-1
    $b[$x] = Binary($x)
next

$a = $b
_ArrayDisplay($a)   ;<~~~~~good

msgbox('','',$b[0x0000000f],1) ;<~~~~~~~~~~~good

msgbox('','',$b[$a[5]],1) ;<~~~~~~~~~~~fine..

msgbox('','',$b[$a[15]],1) ;<~~~~~~~~~~~amazing...

msgbox('','',$b[$a[16]],1) ;<~~~~~~~~~~~perfect

 

 

 

Edited November 14, 2020 by markyrocks

[pixelsearch]

for $x=0 to ubound($b)-1
    $b[$x] = "0x" & hex($x)
next

As this simple code gives correct results, so yes, let's store all the "hex" strings preceded by "0x", problem solved

Edit: your message did change while I was preparing my answer. Anyway, I'll leave my reply as it was.

Edited November 14, 2020 by pixelsearch
we replied at nearly same time

[JockoDundee]

11 hours ago, markyrocks said:

For one reason or another I've come into the issue where i want to store a 1d array inside of another 1d array and i've figured out how to read from it but for reasons beyond me I can't write to it.

dim $a[10]

dim $b[10]

for $x=0 to ubound($b)-1
    $b[$x]=$x+1
next

$a[0]=$b 

msgbox('','',($a[0])[3],1) ;<~~~~~~~this is fine

($a[0])[3]=99 ;<~~~this is broken...

So That being said i can make a copy of the offending array and do whatever i want to it and copy it back.   It just kills me bc like you know its in there....you can read from it..You can drop in a function parameter that takes an array and I believe it will modify it  If its byref.  

it’s not that unfine, is it?

dim $a[10]

dim $b[10]

for $x=0 to ubound($b)-1
    $b[$x]=$x+1
next

$a[0]=$b 

msgbox('','',($a[0])[3],1) ;<~~~~~~~this is fine

$b[3]=99  ;<~~~~is this
$a[0]=$b  ;<~~~~not fine?

 

[markyrocks]

7 hours ago, pixelsearch said:

for $x=0 to ubound($b)-1
    $b[$x] = "0x" & hex($x)
next

As this simple code gives correct results, so yes, let's store all the "hex" strings preceded by "0x", problem solved

Edit: your message did change while I was preparing my answer. Anyway, I'll leave my reply as it was.

Lol cmon man thats just banana's why doesn't the built in function return it in a useable form?  Probably just to make my life hell.  HA.   Hex even though it contains letters....is a number.  I've been beating my head up against the wall with this for hours.  After the initial post i just started changing everything to binary.  I have too many moving parts in this thing already.  Any unknowns that i can remove from the equation the better.  I think i just got what i was trying to do to be relatively functional.  I have a pretty crazy concept that i'm working on.  I usually do have some pretty pie in the sky ideas, but i've finally got enough skills to be dangerous.  I can code just about anything i want in c++ without even a fraction of the headache.  The only reason I play with autoit is to see if i can break it......and this time i just may have done it.  I don't want to spoil it.  Noone will probably notice or care when i start dropping some parts of it anyways.  But it offerses similar functionality to this..

dim $a[0]

for $x=0 to 40000
ReDim $a[UBound($a)+1]
Next

And MUCH MUCH more but in a fraction of the time.  On my laptop it took about 22 seconds to run that code on average.  what i'm working on so far accomplished it in about 3.5 seconds. So the point being it might be a slightly not idiot proof method to speed things up dramatically.

I just ran my solution to 100,000 equivalent  and it did it in about 6 seconds.  Whereas it takes this laptop so long to run the above code from 0-100000 that i'm probably better off taking a nap.  I'm pretty pumped about it though.  What i'm working on is more of the behind the scenes portion.  Hopefully tomorrow i can start working on the centerpiece.

I guess it did finish.  127 seconds. It just lets me know that what i'm working on is worthwhile.  Obviously what i'm working on here has some overhead with it but honestly based on the tests and how few times the basis of this whole thing will actually have to run....I think its totally worth the effort.  I realize the above is one of the most taxing aspects of autoit... but i'm seeking to make ubound obsolete, well and dim, and redim... for that matter. 

[JockoDundee]

 

14 hours ago, markyrocks said:

do i really have to save the initial number as binary and bring it back.  Dammit its just unbelievable some of the wild ass behavior i run into.

How wild is that ass exactly?  After all, hex() returns a string - how does the array subscript know what base you want to convert to?

you can do this as well:

for $x=0 to ubound($b)-1
    $b[$x] = ptr($x)
next

 

[markyrocks]

9 hours ago, JockoDundee said:

 

How wild is that ass exactly?  After all, hex() returns a string - how does the array subscript know what base you want to convert to?

 

 

its wild that it would return a string....bc its a number. I realize that all numbers are basically strings in autoit and the interpreter handles them accordingly but it seems like the ball was dropped here.  if "0x" & hex(num) puts a hex return into a state where it can be used like a number and theres no difference between "0x00000000" and 0x00000000 according to the interpreter then the hex function is broken.  It just doesn't make any sense.  if you can give me an example of a situation where using the return straight from the hex function is useful then i'll concede.  if i wanted the string representation of a hex number i'd be more than happy to  string(hex(number)).

if i wanted the 0x trimed off i'd do stringtrimleft(string(hex(number)),2)

   I just converted everything to binary that way i know its not going to magically turn into a string if it gets passed around.  

[JockoDundee]

3 hours ago, markyrocks said:

if you can give me an example of a situation where using the return straight from the hex function is useful then i'll concede.  if i wanted the string representation of a hex number i'd be more than happy to  string(hex(number)).

if i wanted the 0x trimed off i'd do stringtrimleft(string(hex(number)),2)

Look, you’re just using the wrong function, hex() returns a hexadecimal string representation of a numeric value, like I said you want to use ptr(), it returns a pointer variant, that when you use it as a string, it will work correctly because it will pretend the 0x to the front of it.  Hex just returns a hex string without any such prefix.  

Which is exactly what you want sometimes:

FileWriteLine("index.html", "<h2 style='color: #" & hex($color, 6) & ";'.")

Besides arguing about the name, I don’t see the problem here.

[markyrocks]

Thats fair use i suppose but again hex is a number and in the above scenario it wouldn't make a bit of difference whether it was treated like a number or a string.  In math it definitely matters... Thats the point i'm trying to make.  Ptr() would have solved the issue and i do appreciate that.  I'm well past that now.   i am making a pseudo pointer system.  Its actually a full on memory management system that basically takes control of memory away from the interpreter level and brings it back into the scripting level.  I'm not messing around in the bits or doing anything to change the way autoit works or anything. I could have just allocated memory using virtualalloc and handled it that way but i don't think all that is necessary.   

Edited November 16, 2020 by markyrocks

[JockoDundee]

1 hour ago, markyrocks said:

Thats fair use i suppose but again hex is a number and in the above scenario it wouldn't make a bit of difference whether it was treated like a number or a string. 

hex is not a number, it’s just a character representation of a number.  Normally, a computer system will use base 10 when the time comes to make them human readable.

in the example above, if I were to “treat it as a number” by removing the hex, it would not work for different reasons, depending on the data type:

FileWriteLine("index.html", "<h2 style='color: #" & $color & ";'.")

If it were an Int, a hex value of 01FFFF would print as 131071 and cause the wrong color to print. If it were of type ptr or binary, it would print as 0x01FFFF and print black because the “0x” thing is not expected here (in this html case).

The “0x” thing is not really hex, it’s just something we stick on the front of string representations of hex numbers sometimes, so that when they are later interpreted they can be converted appropriately. But since the hex function does not return the “0x” thing, you have to know the string is hex to deal with it properly.  

In your original case, you tried to use a hex string without a 0x prefix as a subscript, and autoit interpreted correctly as hex when it saw a letter in the string, but when there was no letter, it defaulted to decimal.

It is blameless in this situation.

 

 

[markyrocks]

4 hours ago, JockoDundee said:

hex is not a number, it’s just a character representation of a number.  

 

(HEXadecimal) Hexadecimal means 16, and the base 16 numbering system is used as a shorthand for representing binary numbers. Each half byte (four bits) is assigned a hex digit or letter as in the following chart with its decimal and binary equivalents.

whatever you say dude.  what you're talking about between the directions is just little endian or big endian.  

obviously if $color is 1234 or whatever its not going to print 1234 without a conversion.  Regardless of whatever it is you thought that hex was it wasn't invented so you could make websites pretty.  Saying hex isn't a number is like saying spanish isn't a language bc its not english....

[JockoDundee]

1 hour ago, markyrocks said:

as a shorthand for representing binary numbers.

 

[markyrocks]

13 hours ago, JockoDundee said:

 

If you want to get into the nitty gritty in programming theres no such thing as a string.   All characters are stored as a number ascii code so as far as more lower level languages are concerned you can add numbers and letters together no problem (as long as its not parts of a class without an operator overload).  Even then you could overload the operator and parse the bits and do whatever you want with them.  A string is just a wrapper over a char* array. Just like a char is a wrapper over and int which is a wrapper over binary.  

In my opinion the main reason why autoit even made strings and numbers so interchangeable is bc its must easier at an interpreter level to break strings of numbers down into arrays of numbers bc it gets you around the size limits.  Doing math on numbers that exceed imits is a major pita.  

If you want to challenge yourself write a calculator that does math operations on arrays of numbers.  Way more difficult than you'd expect.   

When I say that array1 is one number and array 2 is a different number.   For a real challenge don't use stringsplit.  

[JockoDundee]

not so fast...

before we can move on to a philosophical examination on the true essence of strings, I think it’s fair that we seek a resolution to your incendiary salvo, namely:

On 11/14/2020 at 8:51 PM, markyrocks said:

Lol cmon man thats just banana's why doesn't the built in function return it in a useable form?  Probably just to make my life hell. 

I’m assuming you are not just bitching about the name of the function hex(), since I offered that option several posts prior.

Therefore the question is how you would escape the inferno?

1) I wish the hex function was not a cast to string, but a cast to binary

2) I wish the hex function pre-pended a 0x to its output

3) I wish it just worked the way I expected it to