Numerical accuracy. . .

I'm sure everyone knows about this but are there any previous forum posts or documentation on the fact that switching off debug leads to lower numerical accuracy and also lower accuracy when reading pixel colors from images/screen?

The lower accuracy with debug off means that I occasionally experience errors that occur during a 'fast' run but do not occur while debugging. These can be nasty bugs to identify.

I would like people to post their comments, ideas and work-arounds relating to this topic and also any kind of explanations for the behaviour that anyone may have. . .

I would love to know the answer to this:
"In order to preserve numerical accurracy in my Blitz program, do I have to compile my EXEs in (the slower) debug mode, or is there another way?"

Numerical accuracy should not (and does not) alter depending on whether debug is on or off.

Please post a small piece of code to demo your problem.

P.S. You should never need to create an EXE with debug on!

I have experienced this in many many MANY situations on many different PCs. I think that all the PCs have been pentiums, so perhaps it's a pentium problem . . .

I will dig out a few examples and post them tonight or tommorow.

I have only really been concerned with this phenomenon because I write accuracy-critical programs such as erosion simulations.
I especially notice it whenever I use the pixels on the screen to store numerical (height) data as I occasionally do with this type of program.

SOMEONE PLEASE TELL ME THAT THEY HAVE ALSO EXPERIENCED THIS OR SOMETHING SIMILAR OR ELSE I WILL GO INSANE!!! :O)

I have experienced situations where code crashes out, but when I go step-through it works. This has been with managing objects though and I don't know about numerical accuracy. I also can't be sure if my experiences are 'bugs' or just me being a crap coder not knowing what I'm doing ;)

Pixel 'accuracy' has nothing to do with floating point accuracy. It is more likely because debug is windowed and release mode isn't, so you are getting a different screen 'depth': 32 or 16.

That might explain that. . . although I always have my system running in 32-bit color, whether windowed or full screen. But I get your point, there could be something in that.

I'm still fairly sure I've experienced it with floating point numbers separately, though I'm not totally sure of myself now. . . I'll have to do a few checks this weekend to see if I can replicate :O)

Although you did not specify I would like to predetermine one possibility with an explanation:

DO NOT use floats in this situation. Floats are an estimate only. An estimate, guess, a ball park figure... Not precise.

Integers are your accurate data type.

If you need a floating point number to be numerically accurate then you will need to control your own data type. A quick method would be an integer that is 1000 times it's real value to hold 3 decimal places, etc.

I say again, floats are not meant to be accurate, for a computer to handle them completely precisely would be very slow.

Just because they are not actually that bad does not qualify them as accurate, they can and do get it wrong sometimes, although their accuracy is not effected by debug status to my knowledge.

BTW: whilst this may or may not be related to the reported "Pentium bug" which I thought was just an issue with P60's and P90's, you might like to know I first came across innacuracies in floats using a ZX-Spectrum, so I dont think it's a Blitz specific "feature" ;)

Okay, I've been playing around, and it seems that I stand corrected. . .

I think y'all right about floats not being affected by debug - I am only experiencing it with pixel values which could be numerous things to do with the graphics card - I am therefore quitting using the pixels to store numbers, which was probably a dumb idea in the first place :O)

Anyway, thanks Becky - I had not realised until just now that integers are more accurate. . . but I guess that makes sense as you have to store extra info for the float in the same number of bytes (i.e. location of decimal) You have enlightened me! :O)

I guess what I really am after is a double precision type - and it does annoy me that I would have to implement all the math operations etc. . . I expect I'd do a shoddy job too, and make it a really slow implementation. Perhaps your idea of using integers will have to suffice.

Thank you all!!! :O)

The tone of my post, having just re-read it, I believe may well be down to a nicotene craving i've been having all afternoon... I'm several weeks into giving up and have been quite calm of late - but this afternoon i've just been flipping! Sorry if I seemed off, or more likely, if I seem ... well, wierd. Almost Jasper Carott'ish "This Parrot is dead. Deceased, it is no more......"

"This Parrot is dead. Deceased, it is no more......" comes from John Cleese, not Jasper Carrott ;) Anyway, keep up the giving up. As if the tobacco in cig's wasn't bad enough the other stuff they put in them (deadly toxins like formaldehyde) really are a recipe for death. I dunno how they ever get away with it. If Cadbury's put deadly poisons in their chocolate they'd be hung, drawn and quartered, dead, deceased, no more...

mrsnidesmin : The reason Floats aren't accurate is because they hold a finite representation of potentially infinitely small values. Consider the value for 1/7. In maths you'd keep that as 1/7 in your calculations, but converting to a decimal you get 0.142857142857142857... repeating forever. If your floating point rounds to 8 decimal places, you get an exact figure for 1/7 of 0.14285714 which isn't mathematically correct. Now use that value in a calcuation. Let's say we want (1/7) * (3 & 3/4), which is in absolute terms 15/28, which in limited decimal is 0.535714285714285714285(...repeating 714285 forever). Rounded to 8 decimal places that's 0.53571429.
Performing this calculation using 8 dp FP figures you get the sum 0.14285714*3.7500000 = 0.52571428. It's 0.00000001 out from an 8 decimal place representation of the true calculation. By using more and more calculations with fixed precision, these rounding errors pile up to produce results that are just plain wrong, but not wrong enough to matter in most applications like 3D graphics.

Also regards FP accuracy on PCs, I heard recently from an experienced professional games developer that...


Apparently DirectX can change the results from floating point calculations. This explains why my physics simulation can have slightly differnt outcomes on different runs, and why floating point results from calculations on a PC can have changing values.

Ahhhhh. . . so maybe it's not just me being insane then. I guess that must be what happened in those various rare circumstances I encounter from time to time, that I've not been able to replicate in the last couple of days. DX affecting the outcome of FP calculations. Who'd have thought eh?

Thanks Shifty, this is the best explanation so far. . . Doesn't help me solve the problem of there being no 8-byte double precision float in BB though. Don't suppose you want to implement one for me? :O)

You said you were storing numbers as pixel data. Well, i can't be too specific as i don't recall, but there's certain RGB combinations that can't be stored if i recall correctly. You can store them, but if you read a pixel colour value back, it changes slightly. Something to do with blitz using 24 bit colour?

yep, that wasn't the problem - I was using (or thought I was) 32-bit color all the time and I should have had 256*256*256 possible values (red*green*blue). But for some reason when reading the pixel values I sometimes got small errors.