cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - You can change your system assigned username to something more personal in your community settings. X

Translate the entire conversation x

using the Floor command and getting incorrect output.

EP_10996709
8-Gravel

using the Floor command and getting incorrect output.

using Prime 10 and 8 and getting the same result.  when using the floor command and getting the incorrect output. 

 

EP_10996709_0-1740164596932.png

did some checking and found Mathcad is rounding out to 21 decimals places. 

EP_10996709_1-1740164727984.png

is this something where we should add a step to round a previous set of calculations before adding the Floor command? 

or am I doing this incorrectly? 

 

See attached file. 

 

ACCEPTED SOLUTION

Accepted Solutions
Werner_E
25-Diamond I
(To:EP_10996709)

You are running into numerical inaccuracies, probably due to conversion from decimal to binary and retour and the limits of the IEEE number format.

 

As you can see, even though FinNom should be exactly 3.849, its actually a little bit smaller. The 10^-16 is a usual precision for IEEE numbers.

Werner_E_0-1740169974530.png

And because FinNom is smaller than 3.849, Prime's Floor function "correctly" gives the result 3.848.

Actually the round-off error already happens when calculating DimAmax

Werner_E_0-1740170704037.png

 

You also found the workaround yourself - apply some kind of rounding first.

 

You may define your own utility function to do this

Werner_E_1-1740170298815.png

or maybe its better to use

Werner_E_2-1740170332385.png

 

Another way to deal with the problem would be to use the symbolic engine which provides higher precision. But I wouldn't recommend that because that would be like shooting sparrows with a cannon. In addition, you would then also have to dispense with the inline evaluations of the calculated expressions, but rather should display the calculated variables in another region.

Werner_E_1-1740171036683.png

 

BTW, its very easy to run into these kinds of numerical inaccuracies when using software which uses IEEE format to store the numbers (which most non-symbolic math software does):

Werner_E_3-1740171776836.png

So if this may be a problem, you have to be aware of it and take measures to cope with it.

 

View solution in original post

1 REPLY 1
Werner_E
25-Diamond I
(To:EP_10996709)

You are running into numerical inaccuracies, probably due to conversion from decimal to binary and retour and the limits of the IEEE number format.

 

As you can see, even though FinNom should be exactly 3.849, its actually a little bit smaller. The 10^-16 is a usual precision for IEEE numbers.

Werner_E_0-1740169974530.png

And because FinNom is smaller than 3.849, Prime's Floor function "correctly" gives the result 3.848.

Actually the round-off error already happens when calculating DimAmax

Werner_E_0-1740170704037.png

 

You also found the workaround yourself - apply some kind of rounding first.

 

You may define your own utility function to do this

Werner_E_1-1740170298815.png

or maybe its better to use

Werner_E_2-1740170332385.png

 

Another way to deal with the problem would be to use the symbolic engine which provides higher precision. But I wouldn't recommend that because that would be like shooting sparrows with a cannon. In addition, you would then also have to dispense with the inline evaluations of the calculated expressions, but rather should display the calculated variables in another region.

Werner_E_1-1740171036683.png

 

BTW, its very easy to run into these kinds of numerical inaccuracies when using software which uses IEEE format to store the numbers (which most non-symbolic math software does):

Werner_E_3-1740171776836.png

So if this may be a problem, you have to be aware of it and take measures to cope with it.

 

Announcements

Top Tags