Bug in labview?

[Pasquale Poggi]

Dear group,
I would like to signal a possible bug I found in several version of
Labview.
The operation is quite simple:
I tried to multiply two numbers in I16 representation and show the
result in I32 representation.
If, for example, I multiply 400 for 400, I obtain an uncorrect result (
28928).
I think this could be an important problem, so I would like to ask you
if I made some mistakes or this is a reported feauture (or bug?) of your

software.

I would be grateful if you could answer to my questions.

Best regards.

Pasquale Poggi
Istituto Nazionale di Ottica Applicata
Florence-Italy

[Henrik Skupin]

Hi Pasquale,

it's not a bug! I16 numbers can only store values till 32767. When you
now multiply your to I16 numbers you get an overflow. To avoid this you
have to convert one number to I32 before you multiply both. Then you get
the right result.

good luck
Henrik

[Pasquale Poggi]

Henrik Skupin wrote:
>
> Hi Pasquale,
>
> it's not a bug! I16 numbers can only store values till 32767. When you
> now multiply your to I16 numbers you get an overflow. To avoid this you
> have to convert one number to I32 before you multiply both. Then you get
> the right result.


Hi Henrik,
thanks for your reply.
I understand your answer, but do you think is it normal that Labview
doesn't provide any error
message when, due to the number representation, an operation leads to an
overflow condition?

Pasquale Poggi
Istituto Nazionale di Ottica Applicata
Florence-Italy

[CraigGraham]

Programmers are expected to understand at least the basics of how a computer
works 🙂

Sure there could be checking, but with checking comes a performance
overhead. In Labview the designers have had to make a compromise between
something that runs pig slow because of excessive checking and something
that runs fast but is unstable because not enough checking is done- not
making sure references and handles are valid before attempting to use them
for example. I think the current level of checking is a good choice; you
can't crash the thing easily, yet performance remains good.

If you have difficulties with the numeric datatypes, just stick with SGL or
DBL and you'll hit few difficulties. Though again, there are difficulties
testing for equalities with
these two types. So if you have difficulties,
get a text and read it.

Pasquale Poggi wrote in message
news:3A2CFDEF.225F0930@ino.it...

> Hi Henrik,
> thanks for your reply.
> I understand your answer, but do you think is it normal that Labview
> doesn't provide any error
> message when, due to the number representation, an operation leads to an
> overflow condition?
>
> Pasquale Poggi
> Istituto Nazionale di Ottica Applicata
> Florence-Italy

[Henrik Skupin]

Hi,

perhaps it's not a really error in your vi. Because only syntax errors
will be shown your semantik error not appear.
Perhaps such warnings would be greatful, but i don't know if LabVIEW can
show them.

In this case a question for all: Is there a way to display this
warnings?

Henrik


Pasquale Poggi wrote:
>
> Henrik Skupin wrote:
> >
> > Hi Pasquale,
> >
> > it's not a bug! I16 numbers can only store values till 32767. When you
> > now multiply your to I16 numbers you get an overflow. To avoid this you
> > have to convert one number to I32 before you multiply both. Then you get
> > the right result.
>
> Hi Henrik,
> thanks for your reply.
> I understand your answer, but do you think is it normal that Labview
> doesn't provide any error
>
message when, due to the number representation, an operation leads to an
> overflow condition?
>
> Pasquale Poggi
> Istituto Nazionale di Ottica Applicata
> Florence-Italy

[TSchmid]

hi

I dont think it is nesesary to display as errror because it is part of the
basic knowled about computers and in some cases you want to have this what
you call an error. I think some how you can get an overflow/carrybit to get
an better result. This programing stile is still used in Assembler.

There is a way to set the values if overflowing to the smalest error
possible
that would be that if you get overflow you can set the number to the
biggest number, that means your error distance to the real number is not
that far than from the overfloved number !!!!!:-)

To set these values "what to do when overflow happent" click to the desired
Terminal or Indicator by --right mousclick / data range / If Value is Out of
range-- and set to Ignore,coer
ce or suspend.

I'm shure you can access this values over variables too.

good luck
Tobi

[Paul Augart]

Hello Pasquale,

Your problem is you must first convert the I16 numbers to I32
representation THEN multiply.
If the two inputs to the multiply are I16, it will do the multiply in I16
representation, with all it limits.
If you take two I16 numbers for example 400 * 400 = 160000 (This number is
much bigger then I16 limit of +32768).
The I16 representation will overflow (rollover). I your case, 160000 / 32768
= 4.8828, it rolled over 4 times leaving 0.8828 which times 32768 = 28928.
When you convert the number AFTER the multiply to I32, it is too late. This
is NO bug, just normal integer math.

-Paul


Pasquale Poggi wrote:

> Dear group,
> I would like to signal a possible bug I found in several version of
> Labview.
> The operation is quite simple:
> I tried
to multiply two numbers in I16 representation and show the
> result in I32 representation.
> If, for example, I multiply 400 for 400, I obtain an uncorrect result (
> 28928).
> I think this could be an important problem, so I would like to ask you
> if I made some mistakes or this is a reported feauture (or bug?) of your
>
> software.
>
> I would be grateful if you could answer to my questions.
>
> Best regards.
>
> Pasquale Poggi
> Istituto Nazionale di Ottica Applicata
> Florence-Italy