Mathcad provides incorrect solution

[jfluckey]

Mathcad is adding a very small number to my results. There is no explaination for it. I am using Mathcad 14.

I have attached both the Mathcad file and a PDF (in case you are not running v14).

If you don't feel like downloading the attachments, this is the jist of what is happening:

Why would Mathcad add in that 10^(-14)? The problem is I want to do something similar to the following: . My equations don't work with imaginary numbers!

I tried increasing the Worksheet Options to 1e-020 for both TOL and CTOL and neither corrected the problem. What is happening?!??!?!

[jfluckey]

I copied equations from Mathcad into the post which showed fine before submitting, but they didn't show up after submitting. So my post may be a little confusing. I also did not see a button to edit my original post. Therefore, please see the following correction:

If you don't feel like downloading the attachments, this is the jist of what is happening:

hn = 99*ft

n = 10

hincr = hn/n = 9.900000000000000000*ft

hincr*10 = 9.900000000000001000*ft

Why would Mathcad add in that 10^(-14)? The problem is I want to do something similar to the following: sqrt(hn-hincr*10)= imaginary number. My equations don't work with imaginary numbers!

[MikeArmstrong]

Looks like a bug to me.

Mike

[jfluckey]

I thought so too. There is also no way around it that I have found. I tried to redefine variable that had the anomaly, "x", to Floor(x,0.00001*ft), yet the error is persistent.

[jfluckey]

Also, is there anyway to get a bug report through PTC's 20-layer of customer dodging fortress?

[MikeArmstrong]

Mona will usually log the issue. I'm just going to check is Mathcad Prime has the same bug.

Mike

[MikeArmstrong]

Have a look below. At least the bug isn't included in the future release of Mathcad/

Mike

[wayne]

Hi Mike,

congratulations.

Is it really a bug?, or just better programming in Prime?

The error is in like the 16th significant figure (I am not sure, everything is a blur by the time I get there).

If is use foat,25 from the symbolic menu, the result is correct.

The same applies when using a program and summing.

[MikeArmstrong]

Hi Mike,

congratulations.

Thanks Wayne,

Is it really a bug?, or just better programming in Prime?

The error is in like the 16th significant figure (I am not sure, everything is a blur by the time I get there).

Prime only goes up to 15 decimal places.

If is use foat,25 from the symbolic menu, the result is correct.

The same applies when using a program and summing.

The symbolic processor might handle the numbers differently and is more accurate I believe. I still get the error when programming, see below.

Mike

[wayne]

With the program, I still had to use float,25 to get the right result.

I think these are just rounding errors is my point, not really a bug. If you really need that much precision, then use float,25 or something.

When I used prime, I got the correct result also

[RichardJ]

The symbolic processor might handle the numbers differently and is more accurate I believe.

It handles them completely differently. It can do arbitrary precision arithmetic. The default is 20 digits, but you can change that with the float keyword. If it takes 25 digits of precision for the symbolic processor to get it right then the numeric processor has no chance. It only has about 16 digits. Sorry, but I am solidly in Wayne's camp. This is not a bug, it's just a reality of numeric computing.

[MikeArmstrong]

It handles them completely differently. It can do arbitrary precision arithmetic. The default is 20 digits, but you can change that with the float keyword. If it takes 25 digits of precision for the symbolic processor to get it right then the numeric processor has no chance. It only has about 16 digits. Sorry, but I am solidly in Wayne's camp. This is not a bug, it's just a reality of numeric computing.

Fair enough, but why does Prime get the correct result then?

Mike

[RichardJ]

Fair enough, but why does Prime get the correct result then?

I don't know. Perhaps Prime is doing the calculations in a slightly different order. As an observation (although I'm not saying this is exactly what is happening), if you want to convert m to ft you only need 4 decimal places to be exact (in base 10, anyway): 0.3048. But if you if you invert the conversion factor it's not exact even with 50 decimal places: 3.2808398950131233595800524934383202099737532808399

Working at the limits of computer precision is bad practice, because it's not reliable. Sometimes it works, other times your bridge falls down

[VladimirN]

Mike, you forgot that in the document we have ORIGIN: = 1. Otherwise we have an extra row with "0" as a result for "x".

[MikeArmstrong]

Mike, you forgot that in the document we have ORIGIN: = 1. Otherwise we have an extra row with "0" as a result for "x".

Good spot Vladimir,

Mike

[VladimirN]

Hello, Juston!

I have created a new "Case" (the given problem has shown with use Mathcad 15 M005) for service of technical support PTC. I also get a fine result in Mathcad Prime 1.0 (file attached to the message):

[VladimirN]

So, PTC declared this bug as SPR # 2081201 (Severity: High; Description: Extra digit when setting number of decimal places to 17). We will wait for the following release of Mathcad 15 (since I declared for release M005) with the list of fixeded bugs.

[RichardJ]

It's not a bug. It's just computer roundoff. First, Mathcad does not store 99ft as 99, it converts it to m and stores that value (30.1752) internally. Well, sort of, because of course nothing is stored internally in a computer in base 10. It converts it to binary and stores that, and it may not even have an exact representation in binary. Second, it's not adding 10^(-14), it's adding 10^(-15), which you then multiply by 10.

The problem is I want to do something similar to the following: sqrt(hn-hincr*10)= imaginary number.

If you try to do computer based arithmetic at the limit of computer floating point precision you are going to run into problems. Rearrange your math so this doesn't happen. That should be possible for almost any real application, because you can shoot a cannonball to Pluto with 15 digits of precision. If you really can't do that then you will have to use the symbolic processor, which can do arbitrary precision arithmetic. The symbolic processor doesn't handle units though, so you would have to deal with them manually.

[MikeArmstrong]

Excellent explanation Richard.

Mike

[jfluckey]

So it souds like it is not a bug, but rather a poor limitation of Mathcad. If I am able to view 17 decimal places, then store 18, 19 or 100 decimal places and round back to 17 at solution. I know this is simplified as to what is really happening in the program, but it can be done, and sounds like it was for Prime.

[RichardJ]

So it souds like it is not a bug, but rather a poor limitation of Mathcad.

It's a limitation of the floating point processor in the Intel chip.

If I am able to view 17 decimal places, then store 18, 19 or 100 decimal places and round back to 17 at solution.

You can't store at 18 or more decimal places. All numbers in Mathcad are stored as 32 bit floats, so about 15 to 16 digits of precision.

I know this is simplified as to what is really happening in the program

Unless you convert the number to binary you will never see "what is really happening". It's the nature of numeric computing.

and sounds like it was for Prime.

As far as I am aware, Prime also stores all numbers as 32 bit floats.

[wayne]

Juston,

Is 2.9999999999999999999999999999999... really 3? In the limit it is 3, otherwise everything falls apart.

Do you really require that level of precision, Richard (as usual) provided a very good explanation.

Prime gave a better result in this case, maybe it will in most cases, but we don't really know yet. There is also a time consideration, the more precision, the more time. I assume that in most cases the numeric processor is faster than the symbolic one.

For most of us, the level of precision you are looking for is a philosophical discussion, not a practical one.

[RichardJ]

I assume that in most cases the numeric processor is faster than the symbolic one.

Enormously so.

[jfluckey]

It's been a while, so sorry for dredging this up again but I didn't want to sound unreasonable, but it is not I but the program that requires that level of precision. 10^-14 is the difference between an integer and a non-integer. I don't want to have to add extra programming to account for an error that is not intuitive. That is a programmer's job, not an engineer's. If this is an error due to binary conversion, then don't allow the program to report past the number of significant digits that it can safely convert without introducing error. That is where my precision requirements fall. Cut off the end rather than introducing error closer to the decimal. 2.99999999999999999 = 3 to me, but not to the program that is expecting an integer so it can run a loop.

I often get flac from my coworkers because of the complexity and precision that I use and/or report, but in this case it's not my fault. I needed that integer! 🙂

[RichardJ]

It's the 16th digit, which is the limit of precision of a 64 bit float (sorry, I said 32 bit float above; that was due to a neuron misfiring). It's the nature of numeric computing. Don't report things to the limit of the precision and you won't see the problem. It's not Mathcad's fault you chose to display that many digits. You are allowed to, because some people have a reason to look at that many digits, even with round-off errors, but you are not forced to.

2.99999999999999999 = 3 to me, but not to the program that is expecting an integer so it can run a loop.

I would have to see the program to comment, because I don't see why a roundoff error like this would stop you from running a loop.

[jfluckey]

I wasn't reporting the answer to the limit of the precision. I was mistaken also. It was not the for loop that caused my problem. I only found the error because it did not report as an integer when I needed it to be (e.g. as an argument for a matrix element). If it were a formating issue, it would have been fine, but it wasn't something I was expecting.

From MathCAD Help (integer requirement found below):

Array Subscript Operator

Keystroke: [

v[n

Returns the nth element of v. If v has no nth element, you see an appropriate error message.

M[m,n

Returns the element in row m and column n of M. If M has no mnth element, you'll see an appropriate error message.

Operands:

• v is a column vector.
• M is an array.
• m and n must be dimensionless integers. The acceptable range of m and n depends on the size of v or M and the ORIGIN of the worksheet.

[Werner_E]

I have not the slightest idea what your problem is. This thread is very long and quite old and the pics in the postings seems to be gone or you had inserted them incorrectly in your original post (simple copy and paste won't work).

Maybe you can explain with the help of a simple example what your problem is now and post an appropriate worksheet. Maybe you even consider opening a new thread

I guess its quite clear to most of us that a vector index has to be a dimensionless integer, so I obviously am missing your point in posting that help excerpt.

[jfluckey]

I came back here because I am now using MathCAD 15 and ran into this problem again. Why would I start a new thread? I hate when I am searching something that multiple threads are created on the same subject. I have Prime 2.0 but don't much care for it so I use v15. If you really want to see the problem reproduced, the attachments in the original post can be downloaded (or a little simpler file is now attached). The exact way that I stumbled upon this is not so simple, so the attachment's only value is to simply show that there is error and how to reproduce it.

The help excerpt was to show that sometimes MathCAD does require an integer. Why I need or how I use an integer is not the question. Yes, I cannot use 9*ft as an array location, BUT I could use (9*ft)/ft which would an acceptable array location.

Bottom line: A result that should be an integer is not.

P.S., at one point the thread read correctly. I don't know why this thread seems incomplete now. HTML update?

[RichardJ · Accepted solution]

[jfluckey]

Wonderful! Thanks so much. I often wondered if there was an option that I could change to fix this. I don't know if this will negatively affect me anywhere else, but it fixes this problem.

To be clear, the result is still Element= 6.999999999999999, but in the logical expression Element=7 returns true.