Skip to main content
1-Visitor
August 21, 2013
Solved

NaN bug: Has anyone seen this before?

  • August 21, 2013
  • 3 replies
  • 17243 views

I'm trying to debug a function that is returning NaN's somewhat sporatically and for no obvious (to me) reason. I didn't write this function, but have gone through it pretty carefully and can't find anything that looks wrong -- though I'm a fairly new mathcad user. Basically, the function pulls in some part numbers, queries a database for some values that go with those part numbers (ESR, Capacitance and ESL for those interested), does a few simple matrix operations and returns the result. It works fine when the number of parts is low (below 11 seems to work every time) but when my part number matrix is too long I get random NaN's as a result of the matrix operations. Hopefully the attached screenshots will explain better in detail -- they show the function and various outputs with 6, 14 and 44 parts. Does anyone have any ideas about this?

Message was edited by: Jay Kobor Note: The parts are the same and in the same order throughout the screenshots. So the first 6 caps in the 14caps image are the same caps as in the 6caps image, and so on. I just mention this to highlight the eccentricity of the problem, since the parts are consistent but the NaN's are not.

Best answer by Werner_E

Huuuh! Scary!!

No I experienced that effect, too. I was playing around with the calculation options an suddenly I saw the NaN's.

It seems that once they are there the do not go away, whatever you do. I reduced the data to 18 rows as minimum to see the NaN's.

I thrw in some returns in the routine to get the interim data and saw that the multiplication of m with the 3-element vector with the s's produces the bug.

I extracted m and ss, assigned it variables and still the bug would be there if I multiply the two.

If I delete one row of the data vector, the bug disappears, if a add a row with arbitrary data (all 1 in my case) the bug reappears. I saved the sheet, closed Prime, opened the sheet again and the bug still is there. Its crazy!

What I haven't tried is copying the variable m and ss to another sheet and multiply or changing more data in the variables.

I would call it a bug you should report to PTC. Or wait if it still will be there in Prime3, which should be available soon.

While m*ss produces (sometimes) the NaN's, the equivalent expression (ss_T*m_T)_T (where _T should denote the transpose operator) doesn't. Not sure if this could be a reliable workaround for you.

EDIT: Sometimes when one changes values in the variables the bug goes away and will not come back, even if the original value is restored. Some kind of corrupt entrys in memory? Anyway - spooky and a bug.

3 replies

25-Diamond I
August 21, 2013

Can you post a working worksheet? Its hard to debug a picture.

jkobor1-VisitorAuthor
1-Visitor
August 21, 2013

Thanks for the response -- yes I can post a worksheet, but I'll have to make some changes to the function so that it works independent of my environment (make it independent of the database query, etc). I'll have this up tomorrow morning.

5-Regular Member
September 9, 2013

This looks like a bug. I will be testing against Prime 3.0, to make sure it is fixed.

--Jakov

5-Regular Member
September 9, 2013

confirmed fixed in Prime 3.0.

1-Visitor
September 18, 2013

I have a similar problem involving boxplots. I keep coming up with NaN errors in random spots of my matrices. I have tried to transpose and transpose back. Displaying the double transpose shows that it works, however it still pops up NaN's in my matrix when I try to boxplot it. Any other work arounds?

25-Diamond I
September 18, 2013

Any other work arounds?

None that I would be aware of. The double transpose trick was just found by chance and I never was sure it would be a 100% workaround. Thats the bad things with errors which pop up at random.

But Jakov wrote that the error is fixed in Prime3, so I guess the best workaround would be to wait the few days until P3 is available.