Idea for arrays

[water]

Why not use two arrays? One to hold the data, a second one to hold the meta data? Easy to code, easy to understand, no changes of the current AutoIt functionality needed.

[Guest]

Why not use two arrays? One to hold the data, a second one to hold the meta data? Easy to code, easy to understand, no changes of the current AutoIt functionality needed.

 

This is what I wrote before:

.... without the need to create more space in dimension 2 (Which it is expensive as long the array grows)

 

 

I did pictures that explain why -
Option 1 (as you suggested):

 

Option 2 (as I suggesting):

 

EDIT:

 

I misunderstood what you suggested.
Use two arrays it the best solution at this time.
But still if you could do what I suggest in the pictures above - it seemed to me better

 

 

Edited December 12, 2015 by Guest

[czardas]

The solution suggested by water is better than having negative indices - especially if there is some correlation between the positive and (these suggested) negative values of each numeric index.

Edited December 12, 2015 by czardas

[Guest]

The solution suggested by water is better than having negative indices - especially if there is some correlation between the positive and (these suggested) negative values of each numeric index.

I did not understand the red part. Can you explain more?

[iamtheky]

If there were many potential fields, with the amount unknown, and to be added at any point in the future:  I would still go map or dictionary, only because I could call the metadata by what it actually is, rather than have to remember where i put it.

[czardas]

I did not understand the red part. Can you explain more?

If $aArray[1] were to have meta data stored in $aArray[-1],  $aArray[2] were to have meta data stored in $aArray[-2],  $aArray[3] were to have meta data stored in $aArray[-3] etc... then there would be a correlation between the positive and (these suggested) negative indices. Perhaps this is not what you are implying, in which case I'm at a loss to understand what you mean.

Edited December 12, 2015 by czardas

[Guest]

If there were many potential fields, with the amount unknown, and to be added at any point in the future:  I would still go map or dictionary, only because I could call the metadata by what it actually is, rather than have to remember where i put it.

I understand. for "metadata" map seems to be very convenient solution.
But there are few questions:
a) can I store map in the array ( in [0][0] or [0] ) ?
b)s Is it faster then what I suggested?
 

About "b)" -  my logic says NO.
Why?  Because map itself must to be some kind of "array" but slower..
When the code looks for map.keyabc then what it probably does is something similar to:
_ArraySearch($aArray,'keyabc') -> get memory address -> read the value of "'keyabc'".

That's what I think .. I believe if I'm wrong, then I'm not mistaken too much about this.

On the other hand, in arrays you know the "address"  immediately.

 

... rather than have to remember where i put it.

I understand the downside that you have to remember the address when you keep coding the code..
But you don't really have to remember it.

You can code this way:
 

#AutoIt3Wrapper_Run_Au3Stripper=y
#Au3Stripper_Parameters=/PE
Global Const $meta_data1 = 0,$meta_data2 = 1,$meta_data3 = 3
Global $aArray[6]
$aArray[$meta_data1] = 'abc'
$aArray[$meta_data2] = 'efg'
$aArray[$meta_data3] = 'hik'
ConsoleWrite($aArray[$meta_data1]&' , '&$aArray[$meta_data2]&' , '&$aArray[$meta_data3] & @CRLF)

 

After you compile it with Au3Stripper (with the /PE ) then the code changes to:
 

Global $aArray[6]
$aArray[0] = 'abc'
$aArray[1] = 'efg'
$aArray[3] = 'hik'
ConsoleWrite($aArray[0]&' , '&$aArray[1]&' , '&$aArray[3] & @CRLF)

 

You don't need to remember that "meta_data1" is always in index 0 and that "meta_data2" is always in 1 and so on..
The fake variables remember it for you.

The same can be with negative indexes of course.

So at the end you write code that working more efficiently because it never not need search where "keyabc" is stored. It just knows it directly because the preprocessing that done by Au3Stripper

[iamtheky]

I would not make any of the assumptions you did about speed, and it is absolutely not doing anything similar to an arraysearch when you are calling them in object notation, it IS that value; moreover your penalties are not coming from the datatype as much as they are AutoIt.  It may be preference, and an abuse of KV storage, but it makes it much easier in my head.

 

Edited December 12, 2015 by iamtheky

[JohnOne]

I'm not sure this kind of functionality belongs in Arrays. For starters it would not be an array anymore. This seems like something you would create as a class in oop, or a structure.

A map is what you would use in AutoIt natively if it were available.

Non natively you could go with iamthekey dictionary, or that class syntax that was posted not so long ago, somewhere where I cannot remember.

You mention unused ram, then what if you have a normal 1D array to use as standard, then every time to add an element, another negative element is added?

That's also unused ram, and with a hell of a lot more people using regular arrays, i don't think it's a great idea.

[Guest]

I would not make any of the assumptions you did about speed, and it is absolutely not doing anything similar to an arraysearch when you are calling them in object notation, it IS that value; moreover your penalties are not coming from the datatype as much as they are AutoIt.  It may be preference, and an abuse of KV storage, but it makes it much easier in my head.

 

Yeah, on second thought, I thought I might be wrong about this.
I would love to know how the map variable working.
Is it more similar to normal variable declaration?

And is Au3Stripper can also strip the names inside the map?
I mean for example: strip $map.keyabc to - $m.k

 

[JohnOne]

Also, for something like this, it would have to be done internally as suggested you do yourself. ie. starting at a higher non negative element, as though it were 0 and resizing it each time an element is added.

[Guest]

If $aArray[1] were to have meta data stored in $aArray[-1],  $aArray[2] were to have meta data stored in $aArray[-2],  $aArray[3] were to have meta data stored in $aArray[-3] etc...

 

No, this is not what i mean.

This will give you the Idea:

But I agree - it's not so necessary feature. it is just a bonus gives you more of what I call "space-order" in one single array (like "space-time" )

I know that this use-case example is very bad.. Please ignore it .. Look just at the ability to do it.

This is just some kind of data organization that I believe can be not bad in some cases.
And this form of data organization is impossible in Autoit.
There are alternatives  to this form of data organization that are good as this (and for this use-case there is match better option)

 

Edited December 12, 2015 by Guest

[czardas]

I see. It's a bit like 1 dimensional chess.

[water]

If I had such data, I would use a database. AutoIt supports "lite" SQL databases. Easier to understand and easy to code.

[BrewManNH]

The amount of memory being used in an array shouldn't be much of an issue unless you have huge arrays, or an extremely low memory computer.

You shouldn't have to worry about this memory issue if the rest of the script is written correctly. Also, as suggested, you could always use a database to hold your data, either an in-memory one or a file.