ACCEPTED SOLUTION
Accepted Solutions
This is a known issue. I've got no idea whether PTC officially know about it, but it's certainly cropped up on the Community before.
https://community.ptc.com/t5/Mathcad/Mathcad-Prime-fold-function/m-p/761171/highlight/true#M198539
Stuart
This is a known issue. I've got no idea whether PTC officially know about it, but it's certainly cropped up on the Community before.
https://community.ptc.com/t5/Mathcad/Mathcad-Prime-fold-function/m-p/761171/highlight/true#M198539
Stuart
@TonyTwoshoes wrote:
Does anyone know why the attached issue is occurring? It seems that when you run units of feet, there is some kind of internal rounding error.
Correct!
While the result looks like its exactly 425
we can see by calculating the difference that actually due to rounding/conversion errors its ever so slightly larger, hence Ceil an ceil come up with the next higher integer 426.
The symbolics does not suffer from this annoyance because it treats units as unknown variables and cancels them
But using symbolic evaluations with units may lead to other problems...
Real Mathcad sure shows the same problem, here Mathcad 15
Don't know why ceilMc11 does better than ceil. I would have thought that both would access the same (inaccurately) stored value of x. Apparently not.
@TonyTwoshoes wrote:
In conclusion, MathCAD is storing the value in way we don't exactly know why,
I think we know why. Mathcad converts all units to the default system (only SI in Mathcad Prime 10 and earlier). Because Mathcad's numeric processor uses the default PC 64-bit real number representation, some precision may be lost when doing the conversion for numbers that don't have an exact binary representation in 64 bits (eg, 0.1).
@TonyTwoshoes wrote:
but it comes to light when we use this function and provides an incorrect result because of it (when units are involved).
It's not just when units are involved. Unit conversions are one example of where this can occur, but it can occur in unitless calculations as well, simply because there might not be an exact 64-bit binary representation of a given decimal number. Here's an example where repeated subtraction works for integers, but can fail for decimal fractions.
(I used a recursive definition of the while function because I only have Mathcad Express, so no programming)
@TonyTwoshoes wrote:
Let's hope it gets fixed soon in Prime? Is there are good way of notifying PTC?
If you are a support customer, then you can report it.
Stuart
Arggh! Belay the above example. That was a genuine recursion limit. 1000 / 0.001 = 1000005, which is way beyond Mathcad's recursion limit (about 4700, IIRC). The following uses the undocumented function fold to get around the recursion depth limit.
You'd think I'd remember how low the recursion depth limit was, as I'd literally just been working on some Express-friendly functions specifically designed to get around that limit. But, oh, no, not me. 👿
Honestly, if I didn't have my head screwed on, I'm sure I'd forget ... Drat, where've I put the blessed thing now?
Mathcad Express 10 worksheet is attached so that others can identify the obvious mistake(s).
Stuart
