Problem with POW

[Albert]

Hi!
I'm experimenting with 3D and I'm trying to learn from the samples comes with glBasic. Unfortunetly that samples are rather old (just as the Help  ) so before I could try any of that 3D sample program I have to fix that.
So I found a bug around POW and float/int types while I fixed the ObjectCreation.gbas:

Code (glbasic) Select Expand


cubeSize=5
DIM ObjectTypes[POW(cubeSize, 3)]
DEBUG BOUNDS(ObjectTypes[], 0) //124


So the POW(cubeSize,3) returns 124 to the DIM

I've made a little test to figure out what is going here.

Code (glbasic) Select Expand


LOCAL res%, res2#
res=POW(5,3)
res2=POW(5,3)
LOCAL obj[], obj2[]
DIM obj[res]
DIM obj2[POW(5,3)]

WHILE TRUE
PRINT res, 0,0 //124
PRINT res2, 0,20 //125
PRINT BOUNDS(obj[],0),0,40 //124
PRINT BOUNDS(obj2[],0),0,60 //124
SHOWSCREEN
WEND


res% gets 124, res# 125. The big problem is that if you want to use directly the resolt of POW(5,3) then your fv gets 124 (DIM obj2[POW(5,3)])

[MrTAToad]

Trying the beta ?  If not, the first example returns 125 here

[Kitty Hello]

the problem with POW is, that it returns a floating point number. So, it could be 124.999999999 or 125.00000000001, depending on your PROCESSOR!!
That's pretty bad, but that's daily soup for programmers.
In your case try (POW(anything, 3)+0.5) to round to the next integer number, safely.

[Albert]

Using Premium.
It's ok for me, I just wanted to point that even that 3D sample went wrong because of this, and it's not so BASIC compatible thing. So its processor dependent.
Ok, I reported it, and it's enough for me. Maybe someone will found this topic someday and can use your workaround.