Floating point problem
Blitz3D Forums/Blitz3D Beginners Area/Floating point problem
| ||
| Is there a problem with floating point numbers? I'm trying to get a number to increase by a tiny amount with each loop, but I want it to stay steady, so I'm using a millisecond timer to keep it accurate. Each pass, I use the command x=x+(timer*0.001). The timer is generally about 20, since that's how long a loop is taking, but it fails to increment the variable properly (yes, they are both FP vars). If I pause the main loop slightly, it does work properly, or if a huge amount is happening on the screen and the loop takes a bit longer, the variable starts increasing, but when the timer is 20 or so milliseconds, it does nothing. Is this a known problem and is there a way I can fix it? |
| ||
| http://www.blitzbasic.com/bbs/posts.php?topic=26011 Andy |
| ||
| The "problem" with floating point numbers is that you have an infinite ammount of number (all possible real numbers) that you want represented using a finite ammount of bytes (namely 4). General mathematical considerations rule this out as impossible, as there is no way to "fit" an infinite ammount of apples into 4 billion crates. The immediate solution to your problem is to scale your variable by a factor 1000 and use integers instead. |
| ||
| I'm getting old and can't remember very well now but didn't the old ZX81/Spectrum handle FP numbers to high accuracy in a few bytes (32 bits)? I have the books in the loft and may get them out later. My ZX81 had 1k ram about 12k rom and would handle FP maths far better than B+ with thousands of times more memory and power! I was in heaven when the 48k Spectrum came out:) When I was a lad........ SJT |
| ||
| Yeah, I started on a Spectrum too. Such happy memories :) Having said that, it makes you appreciate the power of B+, when you'd spend weeks programming a sprite handler on the Spectrum in assembler, and then you'd get 6 sprites moving very slowly and flickery, whereas now you can get 1000 moving smoothly in a couple of minutes :) I remember the first 3d program I ever saw - a program that drew a 3d cup (in black and white) and took about 30 minutes to do it. And even then, it didn't look 3d :p |
| ||
| It's not B+, it's the intel CPUs. And the floats used on these CPUs are standard (an IEEE standard). For higher accuracy there are double precision floats, but I doubt the ZX81 had such floats :) You must also note that the float to string conversion will only take into account 6 decimals (meaning by example that "Print Str(1.0/3)" displays "0.333333"), but internally the number of decimals is slightly higher. |
| ||
| My ZX81 had 1k ram about 12k rom and would handle FP maths far better than B+ with thousands of times more memory and power! Your ZX81 wasn't using *floating* point maths, it was (probably) using *fixed* point math. Which is more accurate, but cannot represent really large numbers. It also cannot represent irrational numbers nearly as accurately as floating point numbers. Or they could have used BCDs. |
| ||
| Ah! BCDs that rings a bell, but I don't remember the details. Was the number split in two around the decimal point or is that fixed point? SJT |
| ||
| Was the number split in two around the decimal point or is that fixed point? That's fixed point. :o> |
| ||
| BCD stands for Binary Coded Decimal: take the decimals and encode them in 4 bits each (thus wasting 6 of the 16 values). This had the advantage of being simpler to display (no divisions, just take a block of four bits and it's your decimal), and also for float numbers that can be accurately represented with a decimal radix (as 0.01), then it can also (set aprat the overflow issue) be accurately represented in BCD format. |
| ||
| I read some book said that intel FPU will convert any bit to 64bit during loading to FPU register, and its even faster to use 64bit fp because no convertion needed. The FPU will calculate any calculation in 64bit only and when sending back to memory 32bit its has to convert back. Is this true?.. I wonder why blitz use only 32bit, if 32bit won't help in term of speed. Its really really cool to have 64bit fp. It's make me forgot the fp limition.... |
   |