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 / Weird things going on with floats...

Author
Message
Braude Interactive
19
Years of Service
User Offline
Joined: 1st Aug 2006
Location: Sheffield, UK
Posted: 20th Oct 2011 19:29
I have a text file with large numbers in it, like 70377.754 and I'm reading the string of each number from there into a variable like



I then need to work with this value, so I convert it to a number using


Now, I take the 79300 off because most of the co-ordinates are offset by this as a constant, so it just makes the active area much smaller, which is better for me. As it keeps the variables nice and small (and therefore accurate)

The value stored that I get in num# however is nowhere near the value in my text file. Say I'd stored 79298.174 in the text file, the value I get in num# is 1.586. Now if I add my constant back on I should get the number stored in the text file, but I don't, I get 79301.586. This is worrying me.

Now I have a lot of data so I'm reluctant to go through and take my constant off of every single bit of data, but I'm thinking that's what I'm going to have to do, as I'm pretty sure that my problem is because I'm trying to store too much information in val#
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 20th Oct 2011 19:50
Floats are not infinitely precise - with only 4 bytes of storage, there's no way that they can be.

The way that floats are implemented gives them, on average, 7 significant digits of precision - that means that the first 7 digits of any number you store in a float will be accurate, and any digits after that may not be.

For example: your value of 70377.754 has 8 digits specified, but only 7 will be accurately stored, and in fact results in a value of 70377.758 being displayed when printed with 3 decimal places.



Braude Interactive
19
Years of Service
User Offline
Joined: 1st Aug 2006
Location: Sheffield, UK
Posted: 20th Oct 2011 20:14
Gah. Thanks IanM. That's frustrating.

Is there not some way I can assign a variable type that's more accurate to get the information from the string up to 8 or even 9 significant figures?

As I say, I'm really not keen on changing all my data, I have about 3600 sets of x,y,z co-ordinates I want to cycle through.
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 20th Oct 2011 21:32
Yes, you can use a double float, which has 15 digits of precision, but there are quire a few limitations - they don't support anywhere near the same number of operations as floats, and when you attempt to carry out those operations (eg SIN() ), then DBPro will convert to float first, carry out the operation, and convert back later, making them slower than floats, and only as accurate as floats.

I may do something about that someday via my plug-in set.

Alternatively, you can switch to an alternate coordinate system, such as spherical (2 angles + distance), sector based (as you are almost doing already) - those two jump immediately to mind.

Braude Interactive
19
Years of Service
User Offline
Joined: 1st Aug 2006
Location: Sheffield, UK
Posted: 31st Oct 2011 19:53
Yeah, I ended up just taking the values off when I loaded them into the program, so I had enough precision without a massive leader for a spatial offset. Made it simpler. I hade a look at spherical co-ordinates and I used that elsewhere, but I have this down now. Thanks IanM.
EdzUp
23
Years of Service
User Offline
Joined: 8th Sep 2002
Location: UK
Posted: 2nd Nov 2011 22:12
You could in theory write a float to a string, perform your desired operations on that and then put it back into a float. Seeing as strings are just characters the adjustments wouldnt be tied to the floating point processor so wouldnt have the issues that arise from floating point math. Sage has been doing this for years with loads of success.

-EdzUp
Graveyard Dogs
Braude Interactive
19
Years of Service
User Offline
Joined: 1st Aug 2006
Location: Sheffield, UK
Posted: 3rd Nov 2011 13:05 Edited at: 3rd Nov 2011 13:07
Yeah, that's what I want to do, but I don't know how to add bits on to the string. Like I load in 0.224 as a float for the program to work with, but I want to display for the user the actual real-world co-ordinate. So I want to add on 79300 to 0.224.

If I do this and store it in a float, I get 79300.22656. I don't know why.

I tried to do a work around like so: (this also displays my problem quite nicely)


But I'm sure there must be an easier way to do arithmetic calculations on strings. I mean, my method only works insofar as the variable x#<1. My program has x# values that range between about -700 and 700... so obviously I need a better way of doing this!
Agent
21
Years of Service
User Offline
Joined: 7th Sep 2004
Location: Sydney, Australia
Posted: 6th Nov 2011 02:04
Ian, just adding my voice to this - floats suck. Hard. Accuracy is paramount! I've never found a good way to get around their horribleness. Whose idea was it to store floats in four bytes anyway? I choose arbitrarily to blame BatVink. Let's lynch him!

Ok, please add accurate floating to Matrix. I'll be your best friend!



IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 6th Nov 2011 12:34
Quote: "Whose idea was it to store floats in four bytes anyway?"

A physicist who needed speed and accuracy (True: Look it up if you are interested.)

However, you're right - BatVink is more convenient. Lynch 'im.

All I can do (and have started to do) is add overloads to existing functions that will allow you to use double floats (8 bytes instead of 4). It'll be up to you to use them (if they work).

Login to post a reply

Server time is: 2026-07-10 16:33:43
Your offset time is: 2026-07-10 16:33:43