Skip to main content
TonyTwoshoes1-Visitor
1-Visitor
Oct 7, 2025 3:10 PM UTC
Solved

213 ft Issue

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.

StuartBruffAnswer
23-Emerald V
Oct 7, 2025 3:41 PM UTC

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

 

2025 10 07 A.png

 

 

Stuart

View in thread

10 replies

TonyTwoshoes1-VisitorAuthor
1-Visitor
Oct 7, 2025 3:11 PM UTC

Attached File

Translate
StuartBruff23-Emerald VAnswer
23-Emerald V
Oct 7, 2025 3:41 PM UTC

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

 

2025 10 07 A.png

 

 

Stuart

Translate
    Werner_E
    Werner_E25-Diamond I
    25-Diamond I
    Oct 7, 2025 8:03 PM UTC
    @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

    Werner_E_0-1759867024892.png

    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.

    Werner_E_1-1759867294973.png

    The symbolics does not suffer from this annoyance because it treats units as unknown variables and cancels them

    Werner_E_2-1759867347812.png

    But using symbolic evaluations with units may lead to other problems...

    Translate
      StuartBruff23-Emerald V
      23-Emerald V
      Oct 7, 2025 10:20 PM UTC

      I'm not sure what Mathcad Prime does internally, but IIRC, Mathsoft Mathcad used the FPU's 80-bit extended double precision format for internal calculations (whilst using the 64-bit double precision format for storage).  Perhaps this is the reason for the difference in behaviour between ceil and ceilMc11?

       

      Stuart

      Translate
      Werner_E
      Werner_E25-Diamond I
      25-Diamond I
      Oct 7, 2025 11:47 PM UTC

      Real Mathcad sure shows the same problem, here Mathcad 15

      Werner_E_0-1759880585668.png

      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.

      Werner_E_1-1759880816543.png

       

      Translate
      TonyTwoshoes1-VisitorAuthor
      1-Visitor
      Oct 8, 2025 11:47 AM UTC

      Thank you, all, for the responses.

      In conclusion, MathCAD is storing the value in way we don't exactly know why, but it comes to light when we use this function and provides an incorrect result because of it (when units are involved). Let's hope it gets fixed soon in Prime? Is there are good way of notifying PTC?

      Translate
      StuartBruff23-Emerald V
      23-Emerald V
      Oct 8, 2025 1:26 PM UTC
      @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.

       

      2025 10 08 A.png

       

      (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

      Translate
        StuartBruff23-Emerald V
        23-Emerald V
        Oct 8, 2025 3:08 PM UTC

        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.

         

        2025 10 08 B.png

         

        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

        Translate
        Terms & ConditionsAccessibility statement