Number to fractional string intermittently wrong

[Ben]

"But the FDIV bug is reproducibly wrong, ..."

If my memory of that issue serves me correctly, the diagnostic that was run to test for that flaw, looked for a certain number of errors out of some total number of attempts. But that is just my memory.

The main point I want to relay with that link is that FP errors will result in small "rounding errors" and that there are no checks inside the FPU.

Memory and other data paths are generally protected by parity and will result in crashes if bit get dropped going to a from memory.

Ben

[tst]

As mentioned, when this happens, it happens all the time (i.e. you can run the a VI which demonstrates this over and over, close it, open and it run it again and it will keep demonstrating the issue for a long time). When it doesn't happen, it doesn't happen, no matter how many times you run the VI. The key is finding out what causes the switch from a working state to a faulty state and I was hoping the workarounds I mentioned could help point NI in the direction of what might be causing this.

Whatever is causing this is not a simple thing, but it's also not something very esoteric, because I've seen it at least 3 or 4 times over the past several months.

[altenbach]

NO, certain inputs reproducibly show the error. It was 100% deterministic, for example (from your quoted link):

4195835.0/3145727.0 = 1.333 820 449 136 241 002 (Correct value)
4195835.0/3145727.0 = 1.333 739 068 902 037 589 (Flawed Pentium)

AFAIK, most consumer computers are not protected by parity errors in memory. They don't use RAM with parity (i.e. 9 bits/byte) (http://en.wikipedia.org/wiki/RAM_parity).

[Gabi1]

i cant reproduce either.

yet, i had a very weird experience with one of my AE, which was sometimes "missing" a step. reason: the value which was supposed to be 3 was 2.999. i found it was related to either or not the fan (...) of the laptop has turned on. you might want to check that. i dismissed it as a hardware thing and on its target place the code is working ok.

[Ben]

OK it was a long time ago and I remebered there was some random factor involved.

This image

Is linked into the Byte.com article on this flaw.

So it looks like you are correct Christian in that the bug is reproducable. The chance factor affected how likely a random user would see this error.

Ben

Message Edited by Ben on 09-24-2007 01:23 PM

[tst]

---

@Gabi1 wrote:

i cant reproduce either.

---

Thanks for trying, but I don't really want people to try to reproduce this. This only happens under specific circumstances and unless we can find out what those are, there's no real point in attempting to reproduce this.

What I want is for NI to try to determine what might be the cause of this based only on the available data. I realize what that means, but just trying blindly to reproduce this and then closing the CAR as "not reproducible" is not a solution which I see as optimal.

[JeanPierre]

That is interesting... In LabVIEW  7 I can't have a numeric conversion to 102.9999999999998560 but to the nearest is 102.9999999999998580

which hex reads as 4059 BFFF FFFF FFF6 while 103 reads as 4059 C000 0000 0000

So it is not a swapped LSB but the whole mantissa that is substracted by 10 (base 10!!) somewhere.

The precision quantum at 103 is 0.0000000000000140 which mean you ask one digit of precision more than what is numerically available. Does the problem occur with formats %0.15f or %0.14f?

[tst]

After seeing this, I was about to say that it's possible that I got this wrong and that it was 80, but then I looked at the image I posted in reply 7 which shows this actually happening and it's definitely a 60, so maybe that's a clue.

---

@JeanPierre wrote:

Does the problem occur with formats %0.15f or %0.14f?

---

I'm guessing it wouldn't occur or I would have used less digits, but I can't tell for sure without reproducing this. I can say that when I first saw this bug, the code was using 32 digits of precision, so it's highly likely that for my example I made the number the smallest it could be while still reproducing the issue.

One thing that concerns me is that this would not seem to explain the issue I mentioned in reply 16 -

---

I ran into what be might another variant of this today - converting a number like 209.08500001 to a string with a precision of 2 and running in a loop (over the same number) resulted mostly in 209.09, but occasionally in 209.08, which is definitely wrong. I'll try to see if I can get an example of that.

---

When I ran into that, I copied the relevant code to a small VI which could serve as an example and ran the small VI several times to make sure that the issue is reproducible. I then closed the VI and went back to work since I was at a customer's site. When I tried opening it again later (I think it was that evening) and running the example, the issue would not reproduce. I still have that VI, but haven't been able to reproduce this yet.

[Elizabeth_S]

Hi tst,

I noticed that when I run the code without the delay, constant folding is enabled.  This may have something to do with the problem that you are running into.  Are you still able to reproduce this issue?  I am escalating this issue to R&D and will let you know what we find.

[tst]

---

@Elizabeth S wrote:

I noticed that when I run the code without the delay, constant folding is enabled.  This may have something to do with the problem that you are running into. 

I doubt it's related. The constant folding isn't enabled with the delay simply because that would not be possible - the delay forces the code to be executed at run time. Also, this delay was only for the example. In the original code where I saw this, the delay only came from the time it took the code to execute and the inputs weren't constants, so they couldn't have been constant folded.

---

Are you still able to reproduce this issue?  I am escalating this issue to R&D and will let you know what we find.

---

I can't reproduce it, but I've only seen this in some of the times I worked on a specific program. Most recently a couple of weeks ago (or at least a variant of it).

I can think of several reasons why:

• This is caused by that program somehow.
• It's caused by the laptop, which I've had for about 6 or 7 months.
• It requires specific conditions which I haven't reproduced in other times.
• I don't really convert numbers to strings in other programs (not sure about that one).
• It does happen, but I didn't notice it.

Since I was using that program each time it happened, I'm willing to take the time and try to run that program just to reproducing this, but not unless I have a good reason to. I'm hoping R&D can give me tools to pinpoint the issue. Thanks for the escalation.