I hate floating point operations
-
<Using MFC>
double dValue = atof("0.1"); ASSERT(dValue == 0.1); double dSecondValue = (1 + dValue + dValue + dValue + dValue); ASSERT(dSecondValue == 1.4); // Crash
Where do you expect us to go when the bombs fall?
Floating point values stump the brightest. A week or two ago, I had an argument with an quite bright student, I only barely won :cool:
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us! -
Tim Smith wrote:
it will tell you that floating point addition is inherently more imprecise that floating point multiplication
It works only if one of the term of the multiplication is an integer. :~ I understand it's like incertitude calculation, for addition you sum absolute incertitudes, for multiplication you sum relative ones.
Where do you expect us to go when the bombs fall?
WTF are you talking about? Please read about floating addition and multiplication. http://en.wikipedia.org/wiki/Floating_point#Floating_point_arithmetic_operations[^] Even though both suffer from rounding problems, multiplication doesn't suffer from "cancellation or absorption problems". I have run into many instances where addition based algorithms had huge precision problems that were eliminated by recoding the software to be more multiplication based.
Tim Smith I'm going to patent thought. I have yet to see any prior art.
-
My macro can be of great help if you know where you put your foot. Eg when dealing with strict positive numbers set, or strict negative numbers set, without mixing the two. However the test case only works with 0xFF... values padded with 0, not like your 0xFFFFFEFF example. I think you wanted to say 0xFFFFFE00 which is correct :) Kochise PS : If I remember right, there is a 'magical trick' explained in a raticle on CP which explain how to cast double to float and the way back only using integer operations, and it works pretty well and fast, and also deals with the sign...
In Code we trust !
No, I said what I meant. I gave you two hex representations of two almost equal floating point numbers that your system fails to detect. I also pointed out a large number of other problems. Even if you just limit your algorithm to positive numbers (0x000000FF and 0x00000100 for example), you algorithm fails.
Tim Smith I'm going to patent thought. I have yet to see any prior art.
-
K(arl) wrote:
I hate floating point operations
So do we. Any data type where "equality of values" is ill-defined is clearly half-baked. Someone should have put a more thought and less transistors into the matter.
-
<Using MFC>
double dValue = atof("0.1"); ASSERT(dValue == 0.1); double dSecondValue = (1 + dValue + dValue + dValue + dValue); ASSERT(dSecondValue == 1.4); // Crash
Where do you expect us to go when the bombs fall?
Yeah - floating point numbers should be called "approximate" to remind us not to use them when we want exact figures.
'--8<------------------------ Ex Datis: Duncan Jones Merrion Computing Ltd
-
No, I said what I meant. I gave you two hex representations of two almost equal floating point numbers that your system fails to detect. I also pointed out a large number of other problems. Even if you just limit your algorithm to positive numbers (0x000000FF and 0x00000100 for example), you algorithm fails.
Tim Smith I'm going to patent thought. I have yet to see any prior art.
Oh, OK, what you provided were RAW floating point numbers (I'm used to see them in their RAW format, and it don't struck my eyes) :
0xFFFFFF00
0xFFFFFEFFI think my macro should work on them :
#define FCMP(x,y) (*((int*)&x)&0xFFFFF800)==(*((int*)&y)&0xFFFFF800)
float dSecondValue; *((int*)&dSecondValue) = 0xFFFFFF00; // RAW : 0xFFFFFF00
float dTest2; *((int*)&dTest2) = 0xFFFFFEFF; // RAW : 0xFFFFFEFF, last 11 bits are differents, so don't compare them -> 0xFFFFF800
ASSERT(FCMP(dSecondValue,dTest2)); // *NO* CrashI just tested, my macro works really well, even if what you provided are not numbers but QNAN. But let me tell you, WHAT THE F... my macro have to be useful on testing QNAN ? These are not numbers and should not be used ! You should throw an error instead, catch it in an ASSERT if you want, but from me to you, your example is just here to try to find a flaw in my trick, which only remains a trick, and show everybody how I'm bad in finding solutions. Bad move... Kochise
In Code we trust !
-
I may have oversimplified. The case was more like the following: double dTime = 0.; double dT = atof(<some value read in a file>); double dFinal = atof(<some value read in a file>); do{ ... dTime += dT; ... while(dTime < dFinal); A loop was missing because of the 'epsilon' induced by atof.
Where do you expect us to go when the bombs fall?
The way you put it now makes your irritation more understandable. But this is still something you'd find in a standard textbook covering floting point arithmetics. The way to solve the above problem would be to eliminate the series of additions
dTime += dT;and instead have a loop variable that you multiply with dT:for (i=0; i<iterations; i++) dTime = i*dT; -
<Using MFC>
double dValue = atof("0.1"); ASSERT(dValue == 0.1); double dSecondValue = (1 + dValue + dValue + dValue + dValue); ASSERT(dSecondValue == 1.4); // Crash
Where do you expect us to go when the bombs fall?
When I was writing a tax calculation app many years ago, I wrote a function called AlmostEqual that looked something like this: bool AlmostEqual(double nVal1, double nVal2, int nPrecision) { CString sVal1; CString sVal2; nPrecision = _min(16, nPrecision); sVal1.Format("%.*lf", nPrecision, nVal1); sVal2.Format("%.*lf", nPrecision, nVal2); return (sVal1 == sVal2); } We had a need to check for equality at different precisions depending on where in the calculation cycle we were. I'm sure you can come up with many other ways to do the same thing, but this was fast and worked very well.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
Chris Maunder wrote:
You may consider floating point storage a bad solution,
(1) We think it's ill-defined - "equal" should be a reasonable operator with any numeric data type. (2) We think it's limited in applicability, even in cases where one would think it would work - like money. (3) We think it's expensive - an entire second processor to do the job.
Chris Maunder wrote:
If your computations-using-fractions works for you then perfect.
They do, in many cases. In other cases, we used scaled integers (which you seem to have forgotten about). And we really believe that 64-bit scaled integers are a much better solution for most problems than floating point. (1) you can tell when they're equal; (2) you can use them everywhere, even for money; and (3) they don't require a separate processor. If that isn't enough for you, then I guess Occam is dead in more ways than one...
Chris Maunder wrote:
But I honestly do not think it's practical. Not for the things such as forecasting weather or perform amazing feats of engineering.
Regarding the weather. In our view, this problem, like the Traveling Salesman Problem, is not effectively solved using a computational approach. A school child with a tiny bit of training can beat the most robust weather-prediction system with just a glance at the maps from preceding days (and without real numbers at all); this problem is better solved using human-like techniques. Regarding "feats of engineering". Almost all of the early satellites were programmed in FORTH with scaled integers. Isn't a satellite a "feat of engineering"? And what modern skyscraper, submarine, or jet plane couldn't be build with 64-bit scaled integers?
Chris Maunder wrote:
No, but every time I go to the butchers I ask for 200g of sliced ham.
Probably force of habit. I, of course, say, "a pound" or "a half pound" or "a quarter pound". But I suspect you don't ever say, "192 grams" or "214 grams", illustrating the point that the unit of measure forced on you from your youth is much too specific for the job - too much accuracy is an inconvenience. Y'know, Chris, we expect a closed-minded, defensive posture from some of the others here, but I really thought we'd find a bit more understanding "at the top". Everybody knows floating point representation is
The Grand Negus wrote:
Probably force of habit. I, of course, say, "a pound" or "a half pound" or "a quarter pound". But I suspect you don't ever say, "192 grams" or "214 grams",
In Austria, they traditionally use the term "dekagram" or just "deka", (being 10 gams) to overcome this problem that a gram is awfully small. The same with lenght: We use centimeter or even decimeter, because its more convenient. And the rest is just education: Imperial measures ar by no means better. With your bread-example, anything smaller than "half a loaf" would be "%NUMBER% slices, please!" anyway.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation." -- Caius Petronius, Roman Consul, 66 A.D.
-
Anyone who dares to equality-compare floating point values with literals probably doesn't have a understanding of basic computer architecture. :) /ravi
There used to be a warning message that stated 'equality comparisions between floating point values may not be meaningful.' or something like that. of course that was a long time ago on a Fortran compiler...;) Didn't this come up a month or so ago???
-
The way you put it now makes your irritation more understandable. But this is still something you'd find in a standard textbook covering floting point arithmetics. The way to solve the above problem would be to eliminate the series of additions
dTime += dT;and instead have a loop variable that you multiply with dT:for (i=0; i<iterations; i++) dTime = i*dT; -
WTF are you talking about? Please read about floating addition and multiplication. http://en.wikipedia.org/wiki/Floating_point#Floating_point_arithmetic_operations[^] Even though both suffer from rounding problems, multiplication doesn't suffer from "cancellation or absorption problems". I have run into many instances where addition based algorithms had huge precision problems that were eliminated by recoding the software to be more multiplication based.
Tim Smith I'm going to patent thought. I have yet to see any prior art.
Tim Smith wrote:
WTF are you talking about?
It was about rounding precision, but it doesn't matter, I don't seem able to make myslf understood in that thread :sigh:
Tim Smith wrote:
http://en.wikipedia.org/wiki/Floating\_point#Floating\_point\_arithmetic\_operations\[^\]
Thanks for the link.
Where do you expect us to go when the bombs fall?
-
Yeah - floating point numbers should be called "approximate" to remind us not to use them when we want exact figures.
'--8<------------------------ Ex Datis: Duncan Jones Merrion Computing Ltd
Ah, yes, "approximate" and "doubly approximate". Then maybe David St. Hubbins' girlfriend's statement "you should do it in doubly" might make some sense.
-
There used to be a warning message that stated 'equality comparisions between floating point values may not be meaningful.' or something like that. of course that was a long time ago on a Fortran compiler...;) Didn't this come up a month or so ago???
rollei35guy wrote:
that was a long time ago on a Fortran compiler
It can be put in the 'positive points about fortran' column... That makes two, with the efficient math libraries (matrix were well handled IIRC) :)
Where do you expect us to go when the bombs fall?
-
Floating point values stump the brightest. A week or two ago, I had an argument with an quite bright student, I only barely won :cool:
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us! -
rollei35guy wrote:
that was a long time ago on a Fortran compiler
It can be put in the 'positive points about fortran' column... That makes two, with the efficient math libraries (matrix were well handled IIRC) :)
Where do you expect us to go when the bombs fall?
K(arl) wrote:
It can be put in the 'positive points about fortran' column... That makes two, with the efficient math libraries (matrix were well handled IIRC)
:laugh:
-
When I was writing a tax calculation app many years ago, I wrote a function called AlmostEqual that looked something like this: bool AlmostEqual(double nVal1, double nVal2, int nPrecision) { CString sVal1; CString sVal2; nPrecision = _min(16, nPrecision); sVal1.Format("%.*lf", nPrecision, nVal1); sVal2.Format("%.*lf", nPrecision, nVal2); return (sVal1 == sVal2); } We had a need to check for equality at different precisions depending on where in the calculation cycle we were. I'm sure you can come up with many other ways to do the same thing, but this was fast and worked very well.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
Where did you hide the body? :-D
Where do you expect us to go when the bombs fall?
He was last seen "alive" in the hardware R&D department. :cool:
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us! -
That's one way of putting it. :omg:
Anna :rose: Linting the day away :cool: Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
-
K(arl) wrote:
I hate floating point operations
So do we. Any data type where "equality of values" is ill-defined is clearly half-baked. Someone should have put a more thought and less transistors into the matter.
The concept of numerical equality is a human concept that you are trying to enforce on a world where it doesn't exist. Two lengths are never exactly equal. Any collection of particles will always have virtual particles which are constantly being created and destroyed. If you say I have two baseballs or 5 nails, none of those objects are the same, you are only counting the number of objects that fit the abstract concept of baseball or nail. Exact equality only works with these abstract concepts. If you take that approach, floating point values are a good representation of lengths because lengths get the same errors when you add and multiply them using physical tools like a straightedge and compass. Integers and scaled are a better fit for abstract concepts like money which isn't a real thing.
Using the GridView is like trying to explain to someone else how to move a third person's hands in order to tie your shoelaces for you. -Chris Maunder