Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Fundamental BUG with arrays

Author
Message
Reece
23
Years of Service
User Offline
Joined: 29th Aug 2002
Location: UK
Posted: 6th Nov 2003 00:37
Link
Using a real array in a real array returns a crazy number!
And this must be something that everyone might need to do in their programs
check out the code below

I've not been able to use DBpro since it came out because of this major fundamental bug

I can't use any of my Dark Basic v1 code because of this and it is also causing me grief when I try to write code from scratch in DBPro

Everytime a patch is released it doesnt fix it

Is this due to be fixed?
Back to top
Profile PM
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 6th Nov 2003 00:47 Edited at: 6th Nov 2003 00:56
Link
Quote: "I've not been able to use DBpro since it came out because of this major fundamental bug"


Are you sure? It is very easy to get around:

dim fred#(1)
fred#(0)=1

print fred#(1)
a=fred#(0)
print fred#(a)

do
loop

But WHY are you using a float as an array index? - Array indexes are expected to be integers. No proper language that I know of will even compile that kind of statement.

Nevertheless it is a bug, send details to [email protected]


BLUE GUI Plugin: http://blue.robert-knight.net / BLUE IDE http://blueide.sf.net/blueide_alpha3.exe
Back to top
Profile PM Email Website
Kevin Picone
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 7th Nov 2003 06:13
Link
Quote: "
But WHY are you using a float as an array index? - Array indexes are expected to be integers. No proper language that I know of will even compile that kind of statement.
"


erm, that's strange I can't think a basic langauge that won't. Well, expect Dbpro

Array indexes should be allowed to be any numeric data type the compiler supports. If users provides wrong TYPE, the compiler will recast it.

Kevin Picone
Play Basic - Visible Worlds - Kyruss II
[url]www.underwaredesign.com[/url]
Back to top
Profile PM Website
TheAbomb12
22
Years of Service
User Offline
Joined: 14th Aug 2003
Location: Amist the blue skies...
Posted: 7th Nov 2003 06:43 Edited at: 7th Nov 2003 06:57
Link
I think he is refering to a lauguage like C++, which does not allow floating type variables in the array index.


Could you imagine this...

Quote: "
dim array(4)

array(2)=4
array(2.5)=10"


Essentially, because you define your array at being a size of 4, the compiler expects Integers. The moment you introduce floating type variables in the index, the array size has to go from 4 to infinity...

This poses a BIG problem. Thats why most lauguages don't allow floating point in the array index.

Reece, when you put...

Quote: "print fred#(fred#(0))"

despite the fact that 'fred#(0)=1', because of the '#' its considered floating point, so I can only assume that means '0' becomes '0.000000'


So, I don't think its a 'bug', almost every lauguage (from my limited knowledge) has this limitation.

So don't try to 'fix' it

Amist the Blue Skies...
Back to top
Profile PM Email Website
Kevin Picone
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 7th Nov 2003 07:29
Link
To re-iterate. This is NOT normal "basic" behavior. If it was, you would have manually cast everything. For comparison, neither DB,Blitz,VB,PB, PlayBasic, AMOS etc do this.

For each inline operation, the compiler has a pre-determine input type. Any type that doesn't match, is hence converted automatically. Types that can't be matched, produce a compile time error.


So this.

print Table#(a#)

Really becomes this

print Table#(int(a#))


Moreover, when a compiler sees a type or array access / function call, it exports a temp of resulting type, back into the parent expression. The result temp would then be recast accordingly, if need be.

ie.

print Table#(Table#(100))

becomes,

Temp#=Table#(100)
print Table#(Int(Temp#))

Kevin Picone
Play Basic - Visible Worlds - Kyruss II
[url]www.underwaredesign.com[/url]
Back to top
Profile PM Website
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 7th Nov 2003 09:06
Link
@TheAbomb12, I don't believe that it's casting like you think it is.

I think it's just using the binary pattern of the float as if it were an integer, rather than converting it to an integer, so basically you'll be getting a number from a random position in memory.
Back to top
Profile PM Email Website
TheAbomb12
22
Years of Service
User Offline
Joined: 14th Aug 2003
Location: Amist the blue skies...
Posted: 7th Nov 2003 09:39 Edited at: 7th Nov 2003 09:50
Link
Yes, It treats it like a normal Integer, but there is no way to determine what memory position it will take...

I think its similar to C++ when you assign a value to an array section that has not been declared; for instance:

int i;
int array[8];

for (i=0; i<20; i++)
{
array{i}=0;
}

...The compiler won't actually stop the program from using more array size then has been declared, however, there might be sections of memory that are accedently overwritten and the values of the array can come out extreamly distorted.

Now this might be similar to what DB is doing; its not stopping the compiler from running, but, lets say array[2.5] was called. the value would get randomly placed in sections of memory. that really CRAZY number could be "empty" memory space because the values werent placed in the "correct" section....

I don't know, this is just my theory...I could be wrong

Amist the Blue Skies...
Back to top
Profile PM Email Website
Reece
23
Years of Service
User Offline
Joined: 29th Aug 2002
Location: UK
Posted: 7th Nov 2003 14:12
Link
Interesting theories, and the later sounds the more convincing, as it always returns the same crazy number

But I must point out that DarkBasic V.1 does not have a problem with this. So the fact that DBPro does, is quite poor really.

The reason why I find this system so useful is because I use it in all my programs

I set up an array which holds all the information for each object, sometimes I have about 30 parameters for each object ranging from position,scale,rotation in each axis to storing information like it's type, mode, ammunition, energy, target etc.etc.

And because 3D space works in floating numbers, I need to be able to store these (amongst other required floating number parameters that I need to store)

So I make this array a floating array

So I often need to get my objects to follow the..
OBJECT#(OBJECT#(3,TARGET),XPOSITION)

sometimes I need an array in an array in an array
I could store the target before hand in a standard variable as Rob K suggested like..
A=OBJECT#(3,TARGET)
then..
OBJECT#(A,XPOSITION)
but this is sloppy and would take me days to go through my code

So I DO think it is nessessary to have this corrected
How do other people use this system?
Back to top
Profile PM
OSX Using Happy Dude
22
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 7th Nov 2003 14:40
Link
You should only ever access arrays using integers, otherwise you are relying on undefined behaviour. Just because it works DB 'Classic', doesn't mean it should in Pro (I think its Classic thats in the wrong here).


Avatar & Logo by Indi. Insert witty comment here...
Back to top
Profile PM Email Website
Toothpick
23
Years of Service
User Offline
Joined: 9th Feb 2003
Location:
Posted: 7th Nov 2003 15:21
Link
do you really need a mutidimention array?

stick the data into a custom type and bung that in to an array.

type good
x#
y#
z#

bulitnum
endtype

type bulit

x#
y#
z#
endtype



dim players(20) as good

players(x).bulitnum=5

etc etc..



This problem would go away if we had arrays within types
hint hint..

Back to top
Profile PM Email
Reece
23
Years of Service
User Offline
Joined: 29th Aug 2002
Location: UK
Posted: 7th Nov 2003 15:57
Link
Hmm...

I've never used this TYPE command before
I'll have to look into it
Back to top
Profile PM
Rob K
Retired Moderator
23
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 7th Nov 2003 16:09
Link
Quote: "So I DO think it is nessessary to have this corrected"


Agreed. But it won't get fixed unless the author knows.

Unfortunately DarkBASIC doesn't support casting like this:

fred#(integer(fred#(0)))

So I guess this method is needed.


BLUE GUI Plugin: http://blue.robert-knight.net / BLUE IDE http://blueide.sf.net/blueide_alpha3.exe
Back to top
Profile PM Email Website
Kevin Picone
23
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 7th Nov 2003 16:38
Link
While It's obvious what's occurring, the returned temp value from the inner float array (also functions) are being 'assumed' to be integer, rather than forced to be integer. This however is not a feature or expected behavior of any Basic language. It is simply caused by the compiler (expression resolve actually), NOT casting the successor data types correctly.

I guess it's easy for me to see, having written a few basic compilers now, so perhaps it's just easier to re-demo the fault like so.. For now you have to 'type cast' your variables manually.




As you can see, it works with the byte parameter, so it's incorrect to assume that array indexs can only strictly be 32bit integers. Now, of course what is actually happening, is the Byte is being re-cast as integer behind the scenes. This casting is meant to occur when an operation is attempting to manipulate a data type, other than what the operation expects.. This is key feature BASIC.

Rob. Unfortunately, this is an extremely old bug. I submitted this one to it lee well over a year ago, and got a 'fixed response'. Can't believe it's still here.

Kevin Picone
Play Basic - Visible Worlds - Kyruss II
[url]www.underwaredesign.com[/url]
Back to top
Profile PM Website
TheAbomb12
22
Years of Service
User Offline
Joined: 14th Aug 2003
Location: Amist the blue skies...
Posted: 7th Nov 2003 16:49 Edited at: 7th Nov 2003 17:00
Link
Quote: "You should only ever access arrays using integers, otherwise you are relying on undefined behaviour."


Yeah, that was basiclly the point I was trying to come across.

However, Im not sure what the difference between Classic and pro is.

Everyone look at the code I modified:



Reece, you may have noticed that I removed the '#' from the array; this fixed the crazy number problem

I also increased the array size... and then gave a value to 'fred(1)'

Im not sure why this happend. but when I tried to assign '1' to 'fred(0)', it still returned '0'; But when I assigned '1' to 'fred(1)' everything worked fine...

Maybe this is becuase Dark Basic Pro doesnt start with an array index of '0' like C++ does. So when you called 'fred(0)', this would NOT be very good because it is outside the array declaration of 'fred(1)' and would thus, use inapropriate sections of memeory resulting in memory being overwritten. However Its not noticable in your program right now, but if you had a large program with lots of variables, you could have some major errors.


I don't know exactly how DBpro workes, so again, Im only guessing


Quote: "
Quote: "So I DO think it is nessessary to have this corrected"

Agreed. But it won't get fixed unless the author knows.

Unfortunately DarkBASIC doesn't support casting like this:

fred#(integer(fred#(0)))

So I guess this method is needed."


Im kinda puzzled as to how you would fix a problem like this.

Amist the Blue Skies...
Back to top
Profile PM Email Website
OSX Using Happy Dude
22
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 7th Nov 2003 17:34 Edited at: 7th Nov 2003 17:35
Link
fred(0) should work okay as DBPro indexes from 0. Dont forget that uninitialised indexes in arrays default to 0 (empty strings for string arrays)



You do need to be very careful about attempting to read from an undefined area of the array. Arrays should always be initialised first too.


Avatar & Logo by Indi. Insert witty comment here...
Back to top
Profile PM Email Website
TheAbomb12
22
Years of Service
User Offline
Joined: 14th Aug 2003
Location: Amist the blue skies...
Posted: 7th Nov 2003 18:46 Edited at: 7th Nov 2003 18:50
Link
Quote: "fred(0) should work okay as DBPro indexes from 0. Dont forget that uninitialised indexes in arrays default to 0 "


Hmmm... thats wierd. When I tried to assign 'fred(0)' = to 1 before it wouldn't work, it always returned a '0'...

But I am going to have to test out your code TCA when I get home to see if it does work (I hope).

Also, if Dark Basic indexes from '0', then is it similar to C++ arrays where the fourth element is 'fred[3]'?

maybe I have been getting it wrong all this time...

[edit] opps, didn't see uwdesign's post...

Amist the Blue Skies...
Back to top
Profile PM Email Website
OSX Using Happy Dude
22
Years of Service
User Offline
Joined: 21st Aug 2003
Location: At home
Posted: 7th Nov 2003 19:46 Edited at: 7th Nov 2003 19:47
Link
Quote: "Also, if Dark Basic indexes from '0', then is it similar to C++ arrays where the fourth element is 'fred[3]'"

More or less - with DBPro you can use the last index (so the number of elements is +1 more than that defined - for single dimensions).


Avatar & Logo by Indi. Insert witty comment here...
Back to top
Profile PM Email Website
TheAbomb12
22
Years of Service
User Offline
Joined: 14th Aug 2003
Location: Amist the blue skies...
Posted: 7th Nov 2003 21:50
Link
Well, when I get home, Im going to be poking and proding just to see the limitations of DbasicPro...

Amist the Blue Skies...
Back to top
Profile PM Email Website
Back to top

Login to post a reply

Server time is: 2026-07-26 15:31:03
Your offset time is: 2026-07-26 15:31:03