Multiplying integers - beware!

[finnh]

Beware if you multiply two integers in the straightforward way. The result may not be as expected! See attachment.

[P@Anand]

It always happens when the result of your multiplied value exceeds the represented memory. My earlier post is somewhat similar to this.

[Gak]

Its out of range right? What is the solution for this?

[finnh]

The solution is of course to use DBLs in stead, but my (hidden) point in the original post was that this should be unnecessary. We should expect LabVIEW to be able to multiply two integers in a straightforward way.

[FraggerFox]

From what I see, 4000 * 10 falls out of range for I16 datatype.....

4000*16 overflows inside the memory and hence the wrong result

The solution is using DBL datatype while multiplying

[finnh]

From users' perspective, the solution is to improve the pertinent basic math functions so the results are as expected.

[FraggerFox]

I differ, if the coder is changing the default datatype of controls, he must know the consequences of overflow for wrong value entry.

Not only LabVIEW, but all other programming languages exhibit this behaviour, since the concept is first multiplying and then casting to other datatype, rather than vice versa.

[GerdW]

Hi finn,

"From users' perspective..."

Well, a user might expect this. But: you're not a user - you're the programmer!!! And you probably know: most problems sit in front of the monitor

[mikeporter]

LabVIEW multiplies integers in a very straightforward and correct way. The problem is that you posed the problem poorly and so don't like the answer you got.
As the programmer it is your job to pick the appropriate way to represent your data.

Mike...

[tst]

---

@finnh wrote:

From users' perspective, the solution is to improve the pertinent basic math functions so the results are as expected.

---

In a perfect world, there would probably be a single numeric data type and that would solve that, but we're not in a perfect world - if I multiply 6 (U8) by 9 (U8), I expect to get 54 (U8). In the same way, multiplying 6 (U8) by 90 (U8) should return a U8 even though 540 can't be represented as a U8, because the decision is an edit time decision, when we don't know the values.

If you want, you can go into the multiply primitive's properties by right clicking it and change the output to be an I32 or I64. This should automatically coerce the inputs the well.