Support Extended Precision for Wire Values in Debug Mode

[X.]

I am probably the only one to be using Extended precision numbers considering the feedback on these requests:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-graphs-to-display-extended-type-values-i-e-creat...

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-All-LabVIEW-Supported-Number-Types-in-Formula-No...

but so be it.

One other area where LabVIEW ignores extended precision is wire values in debug mode. To illustrate what I am talking about, consider this snapshot of a debugging session:

The result of my modified Bessel calculation (that reminds me I haven't suggested to implement special function calculation in extended mode...) returns a perfectly valid extended precision number, such as 5.03E+418, but LabVIEW doesn't recognise this as a valid value and returns an "Inf" value (which would be the correct reaction if the wire could only display double precision floating point values).

This wire is connected to the logarithm primitive, which happens to be polymorphic and hence accepts the extended type. The result is the correct logarithm of 5.03E+418, i.e. 964.15.

On the face of it though, it appears that the output of my VI is +Inf, and that LV went wahoo and estimated an arbitrary value of log(Inf)...

My code actually stores such values in shift registers, so when I debug problems with the code, I have 3 or 4 wires carrying an "Inf" value, which, when I am trying to understand the reason of overflow problem, is not exactly helpful.

Suggestion: display Extended Precision wire values correctly in debug mode.

[ToeCutter]

I would almost go as far as to say the current behaviour is a bug.

You'll never get enough support for this in idea exchange - but maybe a bug report will be considered? Interested to see what an NI official makes of this if they see the thread.

[crossrulz]

I agree that this is a bug.  I rarely ever look at the values coming out of highlight execution anymore.  That's what probes are for.

[X.]

@ToeCutter: not sure it is a bug, since, as I mentioned, NI seems to not have considered it useful to properly display EXT values in most cases. I think it is a deliberate choice.

@crossrulz: I appreciate the feedback, but I have ~20 left-to-right propagating wires in this VI. Are you suggesting it is practical to use that many probes? I didn't think so either...

[RavensFan]

---

@X. wrote:

@crossrulz: I appreciate the feedback, but I have ~20 left-to-right propagating wires in this VI. Are you suggesting it is practical to use that many probes? I didn't think so either...

---

No. Probes wouldn't be that practical to use in this case.

What would be nice is Attached Probe or Block Diagram Indicator  (just hoping to get more support for this idea.)

I did kudo your idea because I believe the highlight execution wires should more accurately reflect the data they are carrying.

[crossrulz]

No, X, that isn't practical.  I admit that probes have their limits.  And I did give this idea a kudo as soon as I made that post.  This is something that should be fixed.  I just think it will turn into a CAR.

[Christina_R]

This was addressed with a bug fix in LabVIEW 2020 SP1.