Possible bug: Saving array with extended and double precision to spreadsheet

[altenbach]

I am just quoting what the help says:

"The instance at the top of the list is the default instance of the polymorphic VI and determines the default connector pane for the polymorphic VI." 

I assumed that when selection is set to "automatic" and we wire something that does not have a matching polymorphic instance, the default would be selected and a coercion dot added, but the help is actually not very clear about this.

Maybe a better solution would be to break the VI in this situation until an instance is manually selected. Only the programmer knows what representation is most appropriate.

In the case of "write to spreadsheet file", I64 is definitely not the correct substitution for EXT. It has no fractions and the range is much smaller. ~10^20 vs. ~10^4000. Let's remember what this function does: it formats the number using decimal ASCII representations, an inherently lossy endeavor. Most likely, the precision is not enough to distinguish DBL from EXT in the final output for typical data.

 The second problem here is that certain drivers output EXT for no good reason at all. I would think that hardware that can measure with a resolution that requires EXT over DBL is exceedingly rare, so why create an instrument driver that outputs EXT??? Virtually all signal processing function (FFT, etc.) only handle DBL anyway, so EXT won't survive very long anyway. 😉

Even NI is not entirely innocent with EXT abuse: Create a control on the lower input of "scale by power of two" and it will be DBL. However, if you first create a constant on the upper input (will be I16) and then create a control on the lower input, that control will be EXT. Makes no sense!

[smercurio_fc]

---

altenbach wrote:

I am just quoting what the help says:

"The instance at the top of the list is the default instance of the polymorphic VI and determines the default connector pane for the polymorphic VI." 

I assumed that when selection is set to "automatic" and we wire something that does not have a matching polymorphic instance, the default would be selected and a coercion dot added, but the help is actually not very clear about this.

---

I believe that only applies to when you first place the polymorphic VI on the block diagram. I would agree that the help file is not clear about which instance actually gets selected. 

I think breaking the connector would definitely create a notification the programmer cannot ignore and would probably lead to less errors, so this may be a good idea. Side-note: Does the VI Analyzer have a test for this condition?

I would also agree that EXT is highly overused in many cases. 

[Roy_F]

It's a bug. The proper coercion should have been to double. This was reported to R&D (CAR #231877) for further investigation.

Coercion of data types is kernel to LabVIEW, so it would be inappropriate to break a poly VI when coercion is done. The coercion dot is shown to get your attention; if you suspect it might not be correct, you should investigate. This is true when wiring to a primitive, VI or poly VI.

Coercion logic is to select best fit, which often means promoting to a wider representation if necessary, but if that is not available, it can be smaller. A way to determine what a poly VI should select would be to use an add primitive and wire inputs ext and double - outputs Ext. Wire Ext and I64, outputs Ext. Wire double and I64, outputs double. So by extrapolation, wiring Ext to a poly with instances of double and I64 should select double.

As stated previously, Default is only used to determine the initial selection when dropped or when nothing is wired; it is not the catch-all for "no exact match".

When concerned about adapt to type for a poly VI, you can turn off Adapt to Type, which then forces the user to select the instance. You can also have the poly VI draw the instance icon instead of the poly icon to raise visibility (if the instances distinguish themselves).