[LabVIEW CAR] y-th root of x function: inconsistent input types

[X.]

Starting from this:

where the type of the y input is I32 (but cast to DBL as shown by the coercion dot), I create a constant from the X input, expecting to get a DBL...

However, a quick look at the Context Help window reveals:

OK, so the function is polymorphic and adjusted itself to the type of the y input.

But wait, why is there a coercion dot then?

Let's look at the y input:

Ah, OK, so after all, the y input is expected to be a DBL.

This is a new type of polymorphic function:

- it guesses from the type of one input what the other input type should be

- it does not adapt to the input type of its own input

Anyhow, why should the type of x be identical to that of y? Ever heard of the cubic root of pi or the pi-th root of 3?

The fact of the matter is that the created constant is in fact of type I32:

and there is still a coercion dot, despite the claim by the Context Help that the input for x is I32.

But hold on a second, is it still the case? Looking at the Context Help:

Ah no, it's not anymore.

Really a strange beast.

Of course, if you drop a function without anything connected to it, the Context Help shows an "orange" type:

This got me curious and I repeated the drill with an EXT wire. In this case, the type of the input wire and the expected input type for x and y are EXT (and there is no coercion dot). I don't have any qualm with the fact that x should be of the same type as y, as it makes sense to perform all calculations in the type with most precision.

Repeating this experiment with all integer types gives the exact same behavior as the one I described for I32.

I think this is not expected and should be corrected, even though this is a minor cosmetic annoyance. Who knows if there are any skeleton in this attic?

Tested in LV 2015.0f2 64 bit on Windows 7

[ouadji]

i agree with you, this is a strange behavior.
ditto with LV2014 sp1.
This behavior needs to be improved / polished !

[X.]

As a side not (and another potential CAR), I doubt the context help says what the authors meant:

x^(1/y):

if x is not complex, x must be greater than or equal to zero unless y is an integer.

Otherwise, the result is NaN

I don't quite understand why, if x is not complex and is negative, having y an integer changes anything to the fact that the result has to be complex...

Try -1^(1/2) (x = -1, y = 2), which should return i (iˆ2 = -1) but returns NaN.

[Using a CDB as output doesn't tell this "special" polymorphic function to spit a complex result - which would be neat -, it just casts the NaN result: NaN + 0 i]

[thuyanhl]

Hi X. 

Thanks for bringing this to our attention. I will be filing a car about this issue and hopefully it will be fixed soon.

[X.]

Thanks, no worry. Please post the corresponding CAR number when filled.

[thuyanhl]

The CAR number is 583375

[Sci-Vi]

Hello,

It looks like this bug is still there in LabVIEW 2021 (and all versions in between) : Context help text is still misleading / wrong, and polymorphic behavior totally broken for y as I32... I suspect that the "linkage" of integer polymorphic versions have a swap in input identifiers (partly mixing x and y)...

Any hope to see it fixed once ?

Thanks !

[rolfk]

This and more serious bugs that remain in LabVIEW for a long time really make me wish there was some way to get access to the LabVIEW source code. A lot of these things are almost certainly very simple fixes that take more time to find in the bug database and put on a task list than actually fixing them in the code, yet they fall under the rug time and time again with every new LabVIEW release.