Graph Autoscale Bug/Feature?

[X.]

Sorry, this is a long post.

I am trying to debug a nifty little extended precision calculation issue and for this, I am plotting the results of some computations.

I discovered the following behavior, which I hesitate to call a bug (or a series thereof), so any comment is welcome.

I am attaching a VI containing a simple Graph with an example of the incriminated data.

1) When I first autoscale the Y axis, nothing happens:

 

Changing the Y Scaling option to autoscale doesn't change anything to the display (notice all the points at the bottom?).

2) If I use the vertical band zoom tool (bottom left) and zoom repreatedly around the bottom, I eventually get to something like this:

 

Much better. Now, curiously, if I autoscale once the Y axis, here is what I now obtain:

 

How interesting! Now autoscale seems to function. Why did it not the first time? That is the first question I would like to be answered and my first suspected bug.

3) Since I now know that there is something interesting in my graph, I will switch to a logarithmic scale in Y. It does work:

 

4) Hmm, it looks like there is something be looked at below 6E-146... Why don't I autoscale the Y axis once? Here is what happens (after a SIGNIFICANT amount of CPU usage - I am talking about 10-20 s at 50% of a dual core 3.4GHz pentium):

 

Looks familiar? Well, it does indeed, if you compare it with the first snapshot above...

But the interesting thing is that not only does it look familiar, but if you look at the Y scale, it has REVERTED AUTOMATICALLY to a linear mapping!

Why? That is my second question and my second suspected bug. 

5) Now, the original data is EXT and the Graph is DBL, so maybe there is something to do with the very small values of the original data (DBL is limited to ~ 1E-323). After going back through step 1-3 above, I can manually edit the logarithmic Y scale lowe bound and reach the minimum DBL value:

 

Ah! So the graph still continues further down to the right... And indeed, if I switch to linear X:

 

Since the graph was computed every 1E-3, I am clearly missing all the values above X (well S) ~  0.71.

So how do I do this? This is my third question (and here I don't suspect any bug).

6) I could of course try to export the raw data of the graph (right-clicking and using Export Data to Clipboard). The problem is that the data will be that of the GRAPH and therefore of type DBL and thus truncated below 1E-323... or won't it?

So I tried that (making sure that I set the largest possible precision for the Y axis - using the Graph Properties) and pasted the result in Notepad:

I am just pasting the last few lines:

0.706 1.5316035021078643E-322 
0.707 6.4228533959362049E-323 
0.708 2.9643938750474792E-323 
0.709 9.881312916824931E-324

So indeed LV clips the array once the DBL limit is infringed (above X = 0.71). But since I am sure that I computed all values up to X = 1, I looked at the EXT array output by creating an indicator on my original VI.

Here is what I read from the indicator for the last value (X = 0.999), once I set the display format right (which, BTW, will result in some interesting other bug, but this is another topic😞

3.95279718785E-436

BTW, the value of the Notepad excerpt above become:

1.55109418182E-322

6.55112062913E-323

2.76633420611E-323

1.1678996958E-323

when read directly from the EXT indicator.

So now I am confused... I mean even more confused.

I thought that the Notepad output was expected, up to the rounding off of the last displayed value, but now I have an EXT display which seems to display values below the DBL limit (check the last value of ~4E-436!)???

Try to enter a value of 4E-436 in an EXT control and get back to me with the answer if it is different from 0! Or read this thread and try out the posted VI.

CAR are welcome and insightful explanations even more.

It sounds like I want an EXT Graph type. Who wants one too?

[SerJames]

Hi X,

Thank you for your feedback in this case. I can definitely see that there is some undesired functionality with the data you posted on your graph. I am having some trouble reduplicating this issue on my end with sample data and formatting so I was wondering if you could give more information on the data format, input and setup that you are using and possibly help give some steps on how to reduplicate this issue.

My gut reactin is that this particular issue is happening due to the extreme range of detail under question but without knowing how the initial graph was created (under what conditions and settings) it will be hard for us to reduplicate this issue on our end to find out if it is a definitive issue or working as intended given the data range we are working with. I will definitely check with some of the teams that have a little more knowledge on our end on whether or not this is "working as intended" (as undesireable as it may be) or an actual bug. What we will need is some more information on the conditions and setup that creates the error.

Again, without the ability to reduplicate this issue on our end it will be harder to find the issue so any help you can provide will be most useful in this case.

Regards,

[X.]

OK, thanks for looking into this. I am attaching an enhanced version of the VI (close to the one I was using when I discovered the problem).

Basically open it, run it and press "Plot". You can stop the VI at any time by clicking in the "Close window" box. It won't close the window, just stop the VI.

Check the following sequence (see video 1 here and video 2 here, where I follow these steps and write "live" comments in the "message" string to describe what does not show up).

1- autoscale Y in linear mode: nothing happens

2- switch to log scale and autoscale: the scale reverts to linear after the CPU is completely bogged down for 10 s (on my PC at least)

3- manually zoom down on the plot until you see a bump. Now you can autoscale (still linear mode).

4- switch to log scale: OK.

5- autoscale: BAM, back to the beginning...

6- go back to step 4

7- adjust the lower value of the scale manually. Eventually you reach the minimum of the BDL type, but you'll see more of the plot. However, we are now missing the last values of the plot...

Now, instead of the default parameter values (S = 100, g I0 t = 1000), try S = 100 and g I0 t = 1E4 or even S = 200 and gI0 t = 1E4. You will see that the array values go into the 1E-4000, which of course the graph cannot display.

I hope this illustrates the problems I was trying to describe in my original post.

[SerJames]

We meet again X...

Thank you so much for that second VI, that really helped give some good insight (and a better data set that my mere mortal brain could set up).

One thing that I have found is if I change the y scale to any level (I set it 0 to 1 and 0 to1E-150) and then run your application with auto scale y on it appears everything works correctly. What I noticed is that the autosize does not work when there is only a high and low level (like the initial state of your graph) with no steps in between. I am guessing the autosize fails because of this fact, that there is only a high and a low it autoscales to the closer value for some reason.

When you zoom, if you notice, it will give you the steps between the high and low and the autoscale works again.

Another thing I attempted was deleting the xy graph and replacing it with a new one, not changing any of the settings but making sure autoscaling was on and things appeared to work.

My best guess is that your graph is in a weird state with its settings and so when it graphs it sometimes only sets a high and low graph value. My best bet is that it is a combination of working with such small finite precision numbers in scientific notation and default settings internally responding weird to said finite precision numbers. A "perfect storm" of settings, LabVIEW default behavior and finite precision data if you will.

Regards,

[X.]

OK, good catch. However, if anything, I'd call this ANOTHER bug.

Now, if you continue through the steps I described (switch to Log scale then autoscale), you should fall back into my tracks and in particular, you will see the Y scale end up with only two ticks, which is the state I saved the VI in.

[Nathan-P]

What version of LabVIEW are you using?  It seems that there have been several reports of simular bugs for LabVIEW 2011 that have been fixed in LabVIEW 2012.

Let me know.  Thanks!

Nathan

[X.]

Latest and greatest: LV 2012 f3 32bit

[Nathan-P]

Great!  I was able to reproduce the strange Autoscale Y behavior in my own VI.  This is an edge case scenario, but the behavior is correct when the graph has the "Loose Fit" property set to TRUE.

http://zone.ni.com/reference/en-XX/help/371361H-01/lvprop/grphscl_loose_fit/ 

"LabVIEW rounds the end markers to a multiple of the increment used for the scale."  

In your case, there is no Y scale, just a two point scale of 0 and 1E-135.  Since there is no increment, it doesn't do anything.  You can force the graph to have no scale by changing one of the "tick mark" values to the MAX value, and all the tick marks disappear.

The XY graph will begin working properly, the Autoscale Y, when loose fit is unchecked/false.  In summary, the problem is the combination on scale and the "Loose Fit" property.

[X.]

OK, I verified that when I uncheck "Loose Fit" on the Y axis of my VI, things behave better.

BUT:

1) the default setting for XY Graphs (and others) appears to be "Loose Fit". I suspect few people bother to change it, therefore they are bound to face the same predicament as I have. I'd argue that there is no logic in the Loose Fit setting preventing me from seeing my full plot in Linear mode. Now, I am not a NI employee and don't drink the cool-aid, so maybe my opinion does not count...

2) Unchecking Loose Fit comes with a price: Autoscale will set the min and max values of the Graph to be those of the plot. So no margin above and below.

3) I still don't have an explanation why my CPU usage shoots through the roof when, in Loose Fit mode, I switch to Log scale... AND THEN the scale reverts back to linear and 2-ticked.

4) I still do not have an answer on EXT type representation: as discussed, numeric indicators display the correct values, so why are the graphs not?

[Nathan-P]

X,

1) I agree with you, and yes, your feedback is important to us. I've filed a CAR (#380816) for the Autoscale Behavior. Its definitely an edge case scenario for the Loose Fit Algorithms, and is undesirable behavior.

2) True, filed CAR for this reason, though if you avoid the situation with not having a Y Scale, that would be a vaild work around.

3)  Your right about the XY Graph, it doesn't allow the display of values outside of the Double range. I found that when I try to move the graph beyond the limits of the double data type, it reverts to a previous valid configuration. I have a feeling that the same thing is happening with the Autoscale algorithm: it tries to display the data outside of the double data range, and then it "crashes" and reverts to its last known working state, a linear Y axis scale in your case.

I've also found that the "revert" behavior is irrespective of the data, and will happen if there is actually no data, but happens when you try to view data on the XY graph that goes beyond the double data range. I will file a car on this, but I think it will be returned as expected behavior since graphs are only designed to display double data, not EXT data.

4)  To get your idea directly in front of our R&D teams, post your idea of an EXT XY Graph Control on our NI Idea Exchange:
http://forums.ni.com/t5/NI-Idea-Exchange/ct-p/ideas

Currently you cannot graph EXT data since the graphs coerce the data to a double data type (if coerced).

-Nathan