NaN bug: Has anyone seen this before?

[jkobor]

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.

[Werner_E]

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

[jkobor]

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.

[jkobor]

Nevermind, I decided just to hang back a little while longer and put it together.

Couldn't figure out how to attach it to this discussion -- so I put it up as a document:

http://communities.ptc.com/docs/DOC-3992

[Werner_E]

Jay Kobor wrote:

Nevermind, I decided just to hang back a little while longer and put it together.

Couldn't figure out how to attach it to this discussion -- so I put it up as a document:

http://communities.ptc.com/docs/DOC-3992

The same way you did with the three pics in your initial post, I guess. Chose "Use advanced editor" at the upper right and then you have at the end of the post the opportunity to attach whatever files you want.

I'll have a look at your sheet tomorrow.

[Werner_E]

Jay Kobor wrote:

Nevermind, I decided just to hang back a little while longer and put it together.

So did I 😉

Your sheet does not show any NaN's here!? I am using Prime2.

I attach the sheet as I was puting it together on 1 page and a pdf of what it looks like for me.

[jkobor]

Hmmm. Well, I am using Prime2 as well. I share a handful of licenses with some other people and they're all in use at the moment. When I can get on it today, I'll open up your file and see if I get the same result as you. I should mention that a few times I have had success (no NaN's) on the first calculation, but on subsequent calculations my problem has appeared. Did you try re-calculating from the function a few times?

[Werner_E]

Thats strange. Yes I did recalculate the sheet (Ctrl-F9, or Ctrl-F5 now in Prime, both work) a few times and I even changed the Data matrix Co_data by deleting some rows at the beginning and at the end.

I didn't changed anything in your file but the arrangement of the expressions to fit the page.

I notice that you changed the routine a bit - at least I am missing the call to a subroutine "select" you had in the screenshots. Did the modified sheet you posted throw the error for you, too?

[jkobor]

Well, I opened your sheet and am able to create the problem. Again, if I recalculate the sheet enough times ocassionally I will get an array without NaN, but if I keep recalculating, they keep showing up in random places. The modified routine was only changed to not depend on our database for data values. Very mysterious -- perhaps I'll see if other people in the office can recreate this on their local mathcad installations. I'm wondering if this is a bug that is specific to my installation, or to the version we are using. I have Release: 2.0. Datecode: F000 (2012.02.17.RC06/2.0.0.176). Not sure if there are patches for prime2 that I don't have?

[Werner_E]

Yes, in the meantime I was able to produce the effect, too. See my other post for an example w/o the program at all.

And yes, you are missing a maintainance releases for Prime 2 (M010, (2012.10.04.001/2.0.1)) but it obviously didn't cure the problem.

Its a crazy bug which should be reported.

[Werner_E · Accepted solution]

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.

[jkobor]

>>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.

I've been trying this out and thus far, it has been a great workaround -- I have not had issues with it yet. Thank you so much for this suggestion!

[jkucan]

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

--Jakov

[jkucan]

confirmed fixed in Prime 3.0.

[ptc-4562784]

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?

[Werner_E]

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.

[Werner_E]

Sorry, for my first reply I hadn't even looked at your sheet.

Now I did and I think that your problem is different from the bug reported here.

The NaN's you noticed in the matrices created by boxblot() are OK, they have to be here. boxplot() creates a column with at least 5 rows for every column of the input matrix. After those five rows it places the outliers - the number of which differs from column to column. So Prime has to fill the shorter columns with NaN's to complete the matrix. Look it up in the help here http://www.ptc.com/cs/help/mathcad_hc/prime2_hc/mprime_en/mprime/box_plot.html?queryId=14132e05308

There seems to be no problem with plotting if you don't use any units, but as soon as you specify your desired unit (mL) in the plot, the plot fails. Workaround is deleting the unit completely in the plot placeholder. Prime is happy and even places unit L in the parenthesis. But as soon as you try to change this (even from L to L) the plot fails. So I think you will have to live with L instead of mL.

I would call this a bug, but a different one as the one described above.