Mathematical problem with a template

[MikeAThon]

Ok, now it returns another value, which amazes me much more:

0.4994994994995

All this talk about the accuracy of floating point math, although theoretically correct, is absolutely irrelevant in the context of the error the OP is seeing. Doubles have an accuracy of 15 (approx) digits, whereas this answer of 0.4994994994995 is wrong in the fourth digit.

If OP said that his answer was 0.499999999999905, then the above discussion makes sense. But when his answer is wrong in the fourth digit, it's a red herring.

Clearly there is something else going on here.

I tend to think that Wildfrog's first question, which remains unanswered, is the correct approach: How did you check the value of getaspectratio()? Are you printf'ing it? If so give us the format string. Are you certain that you are actually using the code you posted, or have you simplified and, and without testing the simplified code, have you made the incorrect assumption that the output remains the same? Are you actually outputting the value of "ratio", and are you outputting it while it is still in-scope?

Mike

[MikeAThon]

Incidentally, I think AlionSolutions (the OP) might have edited his original post, and changed the code. Please don't do that. It makes it impossible to guess why the first version (which no one can see) returned an output of zero (0) while the changed version returned an output of 0.4994994994995

Mike

[AlionSolutions]

Thanx jfaust, but I'm afraid, my application WILL need it, because there's a lot of very complex floating point calculation going on. And I need to show the values in edit-fields. Now imagine using an application, where, when you zoom two simple steps into something, one or more of the edit fields show a value with many digits after the point.

1. The user would not expect that after zooming with an integer a zooming factor, that he gets a fractional result.

2. It would be a struggle to edit values for a user.

3. Rounding is not an option as it would affect the result.

Yepp, that's it. It does not really look like a source of fun and joy to code a own math-library, but I think I'll try it

Greetings

Juergen

[AlionSolutions]

Incidentally, I think AlionSolutions (the OP) might have edited his original post, and changed the code. Please don't do that. It makes it impossible to guess why the first version (which no one can see) returned an output of zero (0) while the changed version returned an output of 0.4994994994995

Mike

Nope, I did not change anything. I frst posted a version that uses variables of the template data type T. Later (seperate post) I changed them to double.

Greetinx

Juergen

[MikeAThon]

Nope, I did not change anything. I frst posted a version that uses variables of the template data type T. Later (seperate post) I changed them to double.

Ah, now I see the difference. In my mind I had already substituted the template type "T" with a "double", so I did not see the difference from your second version at once. Thanks.

Anyway, Wildfrog's first question remains unanswered: How are you checking the returned value of getaspectratio()?

Please also tell us if you have single-stepped into the function, and have confirmed that the erroneous value already appears before the function returns. (My guess is to the contrary, i.e., that it's completely correct inside the getaspectratio() function.)

Mike

[AlionSolutions]

All this talk about the accuracy of floating point math, although theoretically correct, is absolutely irrelevant in the context of the error the OP is seeing. Doubles have an accuracy of 15 (approx) digits, whereas this answer of 0.4994994994995 is wrong in the fourth digit.

This is the value the debugger shows me for the result. I tested the floating point division of 500/ 1000 on another machine and it produces a slightly different result.

I tend to think that Wildfrog's first question, which remains unanswered, is the correct approach: How did you check the value of getaspectratio()?

Please read the thread. I allready answered this before. I am using a debugger. And the BCB-debugger is able to show variable values in their current state as each debugger can. So I checked the value by evaluating the expression "width/height" inside getaspectratio() AND I checked the return value in the calling function. All those checks gave the value mentioned and not 0.5 as expected.

To set things a bit clearer: I need this for adjusting the aspect ratio of a portion of a 2 dimensional matrix to the aspect ratio of an output image. I do this to avoid stretching and deformation of the resulting image if the output aspect ratio differs from the matrix ratio.

I also have the possibility to zoom in and out and scroll across the matrix. With each computation the little errors of the floating point calculations sum up a bit until they again deform the image. So after each zoom or scroll step I have to adjust the ratio again, which again adds a bit of incorrectness. This ends up in a mess. I found several little workarounds to make it less bad, but they are not really perfect solutions.

Greetinx

Juergen

[jfaust]

Although there is some amount of error inherent in floating point calculations, you can keep that error constant by avoiding operations that accumulate the error. For instance, to iterate over a range, calculate from the start using multiplication rather than incrementally adding values.

Jeff

[AlionSolutions]

Aww what a sh*t: Just stepped through the function again and saw that there was a flaw in the computation of the width and height values. They were only 499 and 999. This was because I computed them incorrectly. What a mess. Ok, it was my error SORRY!!!

Thanx for pointing me at my stupidity

Juergen

[Paul McKenzie]

What a mess. Ok, it was my error SORRY!!!

If you're still intereseted in a fixed point library:

http://wiki.yak.net/675

Regards,

Paul McKenzie