Coercion dot on Threshold 1D array

[Mads]

Can anyone explain why the Threshold 1D array function gets a coercion dot on the threshold if both the array and threshold is of the same type of integer, but not for example if the threshold is an integer and the array contains DBLs?

See picture below...

Perhaps I'm overlooking something obvious?

[Mads]

The help text on the primitive is also part of the confusion here: In the left example below it states that the threshold should be a 32 bit integer...but if you change it to such - the help text changes and states that it expects a double 

[wiebe@CARYA]

The developer that made that must have been confused as well...

As I see it, the threshold should always be a float. An array of integers with an integer threshold does make sense, but so does a double, and a double is less narrow. So, for integers arrays, threshold should be a double, for floats it should be the float type (sgl, dbl, ext). But that's IMHO.

[Bob_Schor]

I don't know how you got the Help to say different things for different inputs, but I just tried all 4 combinations in LabVIEW 2018 and they all said Array and Threshold should be Dbls.

Given this is interpolation, you are going to have to do "real" (meaning "floating point") arithmetic on adjacent Array values and the threshold, yielding a float, so the inputs need to be floating (as you'll be doing a "float" Divide, which requires a Float input to avoid the coercion dot).  It is weirdly Consistent (and almost logical).

Bob Schor

[wiebe@CARYA]

I don't think the entire input array needs to be converted. That could be very expensive.

A double threshold on an integer array can be done without converting the entire array. The double's floor can be converted to integer, do the thresholding on the integers, then interpolate the double between the two elements converted to double.

Also all floats should use the (biggest) float type, not doubles per se. Note that complex numbers are also allowed...

[Mads]

Bob Schor wrote:

"I don't know how you got the Help to say different things for different inputs, but I just tried all 4 combinations in LabVIEW 2018 and they all said Array and Threshold should be Dbls.

Given this is interpolation, you are going to have to do "real" (meaning "floating point") arithmetic on adjacent Array values and the threshold, yielding a float, so the inputs need to be floating (as you'll be doing a "float" Divide, which requires a Float input to avoid the coercion dot).  It is weirdly Consistent (and almost logical)."

I'm not sure if you agree or disagree with the claim of strange behaviour here or not?

As you can see in example 2, the function does accept an integer without coercion - as long as the input array is a double.The math within the function is going to produce a floating point result, but the function poly-morphs and can take an integer threshold.

As for the help text saying that the threshold should be an integer when it is a float (for the case with an integer array input), and then saying that it should be a double if you actually change it to an integer (!!), we can reproduce that on two different machines both running LabVIEW 2018. The picture in the help dialog shows an orange wire in both cases, it is the text on the threshold type that changes - and seems incorrect.

[Mads]

Given this is interpolation, you are going to have to do "real" (meaning "floating point") arithmetic on adjacent Array values and the threshold, yielding a float, so the inputs need to be floating (as you'll be doing a "float" Divide, which requires a Float input to avoid the coercion dot).  It is weirdly Consistent (and almost logical)."

I'm not sure if you agree or disagree with the claim of strange behaviour here or not?

As you can see in example 2, the function does accept an integer without coercion - as long as the input array is a double.The math within the function is going to produce a floating point result, but the function poly-morphs and can take an integer threshold.

As for the help text saying that the threshold should be an integer when it is a float (for the case with an integer array input), and then saying that it should be a double if you actually change it to an integer (!!), we can reproduce that on two different machines both running LabVIEW 2018. The picture in the help dialog shows an orange wire in both cases, it is the text on the threshold type that changes - and seems incorrect.

[Bob_Schor]

---

wiebe@CARYA wrote:

I don't think the entire input array needs to be converted. That could be very expensive.

A double threshold on an integer array can be done without converting the entire array. The double's floor can be converted to integer, do the thresholding on the integers, then interpolate the double between the two elements converted to double.

Also all floats should use the (biggest) float type, not doubles per se. Note that complex numbers are also allowed...

---

I think maybe you are commenting on the "internals" of the Interpolate function, how NI is handling this "under the covers".  You may be correct -- this is the only function I've so far encountered where the Coercion dot can change when you run the function.  If you pass in an integer Array and a Float X, you get a coercion dot (not 100% certain why) on X.  Changing X to Integer doesn't change that.  But if now you change the Array to a Float (which I do by putting "To Dbl" on the Array wire), the coercion dots are still present on the X inputs, until I run the VI, when they disappear!  If I now remove the "To Dbl" (using Quick Drop) and set the arrays back to I32, the coercion dots on the X inputs instantly reappear!  [Just to make sure this wasn't a Quick Drop "thing", I just repeated this doing the add/removal of "To Dbl" by hand, and saw the same thing].

Weird.

Bob Schor

[wiebe@CARYA]

It seems different in 2013. Still wrong\weird, but different:

Never mind. I'll give up on understanding this weirdness.