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 Discussion / sqrt() function error: DBC is trying to treat it as an array

Author
Message
Pixelator
13
Years of Service
User Offline
Joined: 8th Jul 2007
Location: here
Posted: 17th Jan 2011 06:52
Hello fellow programmers, i have been having a strange problem recently, as the title suggests. I'm messing around with some pseudo-gravity (havent gotten around to adding in any sort of compensation for distance yet), and every time I try to use the sqrt() function (as is rather nessisary), DBC decides that im trying to use an array that I havent dementionalized yet. I've gone twice over my code, but havent had any breakthroughs yet. Any insights?


Everything is more than the sum of its parts.
TheComet
12
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 17th Jan 2011 08:50
That's because you are trying to assign a variable to the function sqrt(). Change this:



to this:



TheComet

Pixelator
13
Years of Service
User Offline
Joined: 8th Jul 2007
Location: here
Posted: 17th Jan 2011 19:28
Oh my! Thankyou Comet! That part is working now, however im haing another odd problem when i try to use abs() instead of


When ever I try using
, I get an error telling me that abs() "expects real". Does this mean a real number, because in the help files it sais abs() can take an integer or a real number.

Everything is more than the sum of its parts.
Sixty Squares
14
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Somewhere in the world
Posted: 18th Jan 2011 04:33
I'm no DBC expert, but maybe ABS() is confused by your use of real and integer numbers in the command. Try changing the integers to real numbers by adding a decimal point and a zero to the end, like this:



Guns, cinematics, stealth, items and more!
TheComet
12
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 19th Jan 2011 08:46
I also suggest keeping the above code, or at least sticking it into an abs function of your own. The reason I say this is because it is REALLY slow. What the function actually does is the following:

output=sqrt(sqrt(input^4))

And we all know how slow square roots are...

This should be much faster:



TheComet

Phaelax
DBPro Master
17
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 19th Jan 2011 16:48
Where did you hear DB's ABS function uses sqrt like that? It makes no sense and I can't see any reason it would been programmed that way.

"Only the educated are free" ~Epictetus
"Imagination is more important than knowledge..." ~Einstein
TheComet
12
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 19th Jan 2011 17:02
To be honest, I am making a guess It's the only thing that explains why the function is so slow, and I know for certain that that's how it was programmed on calculators. The reason it's not just sqrt(input^2) is because it wouldn't work with imaginary numbers : sqrt(i^2)=i

So they just "doubled" it : sqrt(sqrt(i^4))=1

But I suppose DBC has the first version, because it doesn't support imaginary numbers : sqrt(value^2).

TheComet

Latch
14
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 19th Jan 2011 20:47 Edited at: 19th Jan 2011 20:49
I think TheComet is right depending on the circumstance in the programming. I don't know how deep DB goes into parsing it's built in commands but I think in C or C++, abs for integers is handled like TheComets suggested function:



or by using 2's compliment. If it's assembly then integers would be handled using registers and 2's compliment.

For floats and imaginary numbers, in C and C++ it would be similar to what TheComet posted, I think. For DB, it all depends on how it's commands are translated. DB may not differentiate between integers or floats or imaginary and just use a "one case fits all" approach which would be the most computationally taxing.

Enjoy your day.

Login to post a reply

Server time is: 2020-08-06 08:39:27
Your offset time is: 2020-08-06 08:39:27