LabVIEW has trouble graphing very large numbers

[nanocyte]

When you try to graph a data set that has very large and very small numbers, I just get the spinning wheel of death. I tried filtering out infinities and NaNs but it still crashes. If I filter out the large/small values (see disabled case), it does fine graphing.

[billko]

What was I supposed to see?  It seemed to graph just fine.  It took maybe three seconds and then displayed a graph?  Didn't bother to check whether or not the graph was accurate or not, though, just whether or not it finished.

Edit: LV 2024 Q3

[rolfk]

You are operating very close to the theoretical range of double precision values (1.7E +/- 308).

If LabVIEW tries to do anything with those numbers, such as determining the min and max for autoscaling scales, it is bound to run into some difficulties due to rounding errors and such. While it should not hang or crash but simply skip over such limitations, it's a fact that you are stressing the actual possible range of your numbers. Changing to extended floating point only would buy you a little more lee-way and it only works on Intel CPUs, all other currently still supported CPUs in LabVIEW, basically only ARM in LabVIEW for MacOS and for ARM based cRIO/sbRIO targets, do not have extended floating point support but simply use double nevertheless for the extended floating point datatype.

[altenbach · Accepted solution]

---

@billko wrote:

What was I supposed to see?  It seemed to graph just fine.  It took maybe three seconds and then displayed a graph?  Didn't bother to check whether or not the graph was accurate or not, though, just whether or not it finished.

Edit: LV 2024 Q3

---

In 2020 it hangs forever (or however long I was willing to wait). Since you are using 2024, maybe it got already partly fixed.

I agree that there is probably no valid reason to ever graph such numbers, but it should not lock up. If fixing the code to deal with such numbers causes an overall performance penalty, it should be left alone, though.

In any case, I left a note in the 2024 annual bug thread .

[paul_a_cardinale]

---

@altenbach wrote:

---

@billko wrote:

What was I supposed to see?  It seemed to graph just fine.  It took maybe three seconds and then displayed a graph?  Didn't bother to check whether or not the graph was accurate or not, though, just whether or not it finished.

Edit: LV 2024 Q3

---

In 2020 it hangs forever (or however long I was willing to wait). Since you are using 2024, maybe it got already partly fixed.

I agree that there is probably no valid reason to ever graph such numbers, but it should not lock up. If fixing the code to deal with such numbers causes an overall performance penalty, it should be left alone, though.

In any case, I left a note in the 2024 annual bug thread .

---

For me it doesn't hang in LV 2020.  It takes about 8 sec to complete.

[Yamaeda]

What if you turn off auto range? If you know you'll be working in that range there's no reason to have it active.

Yup. turning off autoscale makes it basically instant.

[nanocyte]

Interesting. It seems like different people with different hardware are experiencing different results. I tested in 2024 and got it to hang forever but it was running on a virtual machine. 8 seconds sounds bad. Autoscale "off" is an acceptable workaround for me but those large numbers were unexpected in my application, so it took a while to track down why my application was randomly freezing.