BUG: Arithmatic shift right in expression and formula node

[Wiebe@CARYA]

Don't believe this isn't a known bug, but I couldn't find it... Tested in
LV7.1 and LV8.5.

In an expression node, if you use the << operator, the function produces
wrong results if the input isn't an I32. For instance, x<<1 in an expression
node, with an U8 as input:

1 result 2
128 result 255 WRONG, should be 0!
130 result 255 WRONG, should be 4!

The normal shift function is correct (I used it to compare the results,
after I noticed that C results where different). Also, the function works
correct when used for U32's (e.g F0000002 results in 4) or I32's. When an I8
is used, results are limitted to 128. U16's and I16;s fail as well.

As a work around: convert the input to U32, and afterwards to U8.

In a formula node, create an aditional input that is an u32: "T32=T8; var=
T32<<1;" might work in a lot of cases...

Regards,

Wiebe.

[hounddog]

I had a similar experience with the MathScript node: bitshift(0, 0) = 1, bitshift(1, 0) = 1, bitshift(1, 1) = 2, so I had to do a test for the number parameter == 0 and not use the bitshift function for this case.

[GrantM]

Hello,

The MathScript bitshift behavior with 0 is a known issue, currently tracked in a bug report (53118).  We hope to have this fixed in a future release.

Grant M.
Staff Software Engineer | LabVIEW Math & Signal Processing | National Instruments

[Andrey_Dmitriev]

LabVIEW 8.6.1 and bug still here:

Compared with CVI C compiler and Intel C++ Compiler - both return zero. But formula node returned 255.

I've lost more than hour for looking trobles in my code, but it was behaviour of shift!

Andrey.

[JCC_(SK)]

I could report that bug is still in LabVIEW 2016 32-bits!!!