Math Operations on LV for Palm

[Cepera]

I am trying to write a program for a Treo 680 running PalmOS 5.4 (Garnet) using LV for PDA 8.0, and I observe some strange behavior in math operations. The test that I did was to calculate B = log10(A). Both A and B are defined as DBL. The B field is programmed to show 16 decimal places. When I run this program on the PC, I get the following results:

log10(10) = 1.0000000000000000

log10(50) = 1.6989700043360187

log10(100)= 2.0000000000000000

When I run the same program on the Treo (or on Palm OS Garnet Simulator - same results), I get

log10(10) = 1.0000000000

log10(50) = 1.2694732747

log10(100)= 2.0000000000

A couple more interesting results:

log10(72) = 1.4278357668

log10(73) = 1.0043294009

Two questions:

1) Why do the results on Palm have only 10 decimal places?

2) Why are non-integer results so far from the correct values?

A few notes:

1) This is not a question of DBL vs. SGL: log10(50) in SGL arithmetic is 1.6989699602127075

on the PC - the difference starts only in the 7th decimal place.

2) I have MathLib.prc installed on the Treo (and on the simulator).

3) The Palm calculator works correctly: e.g. log10(50) = 1.698970004336

TIA,

Sergey

[tst]

If you are running the exact same code on both the PC and the Palm, then I would say this is a bug in the PDA module. The PDA module converts your LV code into C and then compiles it and this process creates quite a few bugs.
Add to that the need to compile for two different OSes (Palm and CE) and you have a recipe for more problems.

NI dropped support for Palm in 8.2, so I would not expect seeing a fix for this.

[AdnanZ]

A CAR with ID# 460GB2GF has been filed for this. As tst mentioned, National Instruments no longer supports Palm OS in 8.2.

[Cepera]

I realize that NI discontinued support for LV for Palm starting with v.8.2. But if what I came across is indeed a bug, it's a pretty big bug, which renders all floating point arithmetic on Palm unusable. Do you mean that NI will not do anything about it? Incidentally, I noticed that LV for PocketPC had a maintenance release 8.0.1, while LV for Palm did not have any. Does it mean that NI is content with releasing a half-baked product, selling it and then just dropping support for it?

Well, I still hope that it was me doing something wrong, rather than a NI bug. I mean, how can you have a bug in such a fundamental operation as log(a)? 🙂

Thanks for your responses!

Sergey

[tst]

---

@Cepera wrote:

I mean, how can you have a bug in such a fundamental operation as log(a)? :)

---

As mentioned, the PDA module converts your code to C, which is an error prone process.

Couple that with the fact that the PDA module has a relatively small market (and the Palm version an even smaller one, as evidenced by its scrubbing), and you can see how bugs like this can slip through the cracks. As you mentioned, the error does not occur for all values of a.

[Cepera]

It gets even worse than that: multiplication does not work either:

• 1.00 * 1.00 = 1.0000000000
• 1.10 * 1.10 = 1.2100000000
• 1.20 * 1.10 = 1.3200000000
• 1.20 * 1.20 = 1.0105032704
• 1.30 * 1.30 = 1.2605032704
• 1.40 * 1.40 = 1.1010065408
• 1.00 / 2.00 = 0.0705032704
• 1.00 / 3.00 = 0.3333333333
• 2.00 / 3.00 = 0.2371699371
• 0.3333333333 * 2.00 = 0.2371699370

There is clearly some pattern here, but I can't think of how to interpret it...

[AdnanZ]

I was able to investigate the issue and the problem seems to be with the precision of the indicator and not with the logarithmic or any other math function of LabVIEW. If the precision of the indicator is set to 10 or more, you will get incorrect values. The workaround to this issue is to set the precision to 9 or lesser.

Message Edited by Adnan Z on 02-05-2007 06:25 PM