-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0|553|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
SoCoder -> Snippet Home -> Variables

Created : 08 December 2006
Edited : 11 December 2006
Language : Blitz Max

List v.1.2

Dynamic Arrays in Blitz Max

This is my implementation of Dynamic Arrays (which I'm now calling List as it's easier, shorter, nicer) in Blitz Max, very easy to use just 'create', 'add' and 'get' methods to use for creating, adding and getting values.

There are also 'getSize' and 'resize' methods. 'getBlockSize' and 'setBlockSize' methods for changing the amount of fields the array will increase by, as well as a 'isField' method to check if a field is in the array.

See the Blitz3d version for more information.

I do plan to add more methods for working with the arrays, probably based on many currently provided in both Java and Ruby.



Friday, 08 December 2006, 13:25
power mousey
oh man!,


I thought you 're the son of or even nephew of Columbo.
The only Josephs that I know are my friend, the Joseph in the Bible, and that kid in the tv series King of the Hill.

besides this, thank you for sharing some code and insight into dynamic arrays. I'll be taking a look here and ther at the code and algorithm too. And oh this is for BlitzMax. Wondering if the code applies for Blitz 3D.
hmmmmm.....arrays within types. true.

thank you, you are the Dynamic Diablo Dynamo. Not 2 D's as in DD or Dare Devil, but the Dynamic Diablo Dynamo.

power mousey
Saturday, 09 December 2006, 06:17
Yes but you have to 'slice' them when you want them to be a different size. This also means checking the bounds first. What if you don't want to do that? What if you want to add an unknown amount of object an unknown amount of times? You have to either write in to check and slice each time (which shouldn't be done as your repeating code) or make your own routines. I'm just doing the latter for you.

I may change the Blitz Max version so it just has a single array it checks and slices accordingly. This is initially a translation of the Blitz Basic version.
Sunday, 10 December 2006, 17:10
In response to your comments Agent Smith:

First, yes, this is just encapsulating an array into a class to remove resizing all the time. An extra method call behind the scenes will incur practically non-existent overhead. To call it extra overhead would be taking the technical amount of extra processing power way out of proportion. It's all those new programmers who say 'don't use functions because their slower'.

The only time I have ever found functions a real slowdown was when I was iterating through approximately 2,500,000 colour values and using an alpha function to work out the alpha. Having it not call a separate function to calculate the alpha did make a large difference to the execution speed (and I made this change to optimize the speed). However although in this example the existence of a function made a large difference to the execution speed, I would still say it was the iteration of 2,500,000 values that was the real cause of slowdown not the function.

Second I called it dynamic, because through wrapping a class around the array it is now able to be any size, and resizes automatically. You shouldn't have to read the source code of any extra class you wish to use, only the documentation. The fact it is actually static is hidden under the hood is irrelevant unless you plan to either learn or change how it works. Therefore what you perceive is that it isn't static, and instead is dynamic, so I would say claiming this in the documentation at face value (with correctly stating it achieves this through the resizing of a static array) is perfectly acceptable. Hence the name.

Also 'ActsDynamicButActuallyStaticArray' is a tad too long for me (even then I'm just calling it a 'List' now).

Third, I had the same thought. But what else should I return? You can argue that returning 0 is fine because all integers are 0 when created and 0 is also 'false'. The real point however is that it's not static, so you should be able to look out of bounds without a problem. If you did look out of bounds what would you see? Well I'd say an empty integer, an empty integer holds 0, so I return 0. If you would rather it resized and then returned that value I can make this method for you. I'd say this is far better then an exception in this case.

How does this stop one from storing 0? You could have 100, and they will all be stored. The one aspect I'd say this does fall down on is that it is not documented a value not found will return 0. Much other documentation is needed, but I will add that as I improve further on the class.

Finally, as I said before above, this is really just a translation of the Blitz 3d version. You cannot resize an array in Blitz 3d, which is why it was more planned for that. I simply thought moving it across to Blitz Max would be nice.

Also checking and then resizing the array every time is repeating your code, and so you should wrap it into a function, or in this case, a class. The reason it says 'a.resize(1000)' is because I was testing how much faster it would be. It was also testing and showing the code in use. Resizing yourself improves on speed, but 90% of the time you do not need the extra speed. If you had of read my showcase properly you would have known that line isn't necessary, as it resizes automatically.
Sunday, 10 December 2006, 23:58
First, yes your right, but it is only in extreme cases (like my alpha example) where I find this is a factor. Always concerning yourself about 'overhead' will distract you in the long run, like not making extra functions/methods where it would help break down the code and make it far easier to read. Personally 'speed is only a problem when it is a problem'. If speed is not a problem, then why worry?

Second, good point. It's repetitive code and you could argue it is only the resize methods responsibility to check. I will change this.

Third, I was thinking the same thing. I'm am going to change it to have it resize the array in tens, with the option to change the new 'arrayIncriment' value which the size will be changed by.

Finally, you can get the array size and compare this against the field you are after to check for 'out-of-bounds'. I will add an 'isField' method however to do this for you.

edit: blockSize sounds fine, so I'm just using that instead of 'arrayIncriment'.