Number to fractional string intermittently wrong

[tst]

This doesn't actually have to do with the number of times the loop is run and the delay did seem to be required to properly cause this.

As I said, I believe that the issue occured because I used up all of my RAM and started working with my page file instead, but I can't prove it.
I was interacting with .NET, but nothing special other than that and the PC does not have a lot of services\programs running on it (other than the default, rather large, number of services which were already running).

[MRedRaider]

Okay... I think I see your point. My thoughts in removing the delay and increasing the loop count was to really LOAD the processor and create a HUGE number of copies of the array (since we are using auto-indexing versus pre-initializing the array size)...

I did observe something very interesting that maybe someone can explain:

1. I ran the VI with a large N (N = 1000000) and it ran fine. (30% load, 200MB Ram) This didn't take long at all.

2. I changed to a very small N (N=10) and reran the VI. The VI took forever and a day. I watched as my system resources wavered around 800MB of memory for LabVIEW with 50% load for a few minutes.

[tst]

It's possible that using large arrays to eat the RAM will help in reproducing this. I'll have to try that.

[sth]

---

@Bill@NGC wrote:
Could this not be the result of round-off errors? When trying to convert a real number using full precision you may sometimes see dithering in the LSB. If you reduce the number of digits of precision a fair amount you eliminate the dithering and you should ALWAYS get the same result. Then again, maybe I'm off in left field on this.

---

As Dr. Round-off error I guess this is my favorite issue and first collected into the FAQ 10 years ago. But in this case there is NO (or at least should be no) roundoff error. As long as tst is trying to convert an integer it can be represented exactly as a floating point number (unless it is greater than 56 bits or whatever the double mantissa is) any way 103 is certainly EXACTLY representable as either a single float, double float, signed or unsigned integer.

What might be more convincing would be that the constant be an integer converted into a float. That way you are sure that the displayed number is an exact and not something that is rounded to 103.

My guess is that in LV 7.0 there was a bug in printf routine that was linked into LV. As was mentioned previously, it doesn't seem to reproduce under either LV 7.0 or 8.5 on the Mac. Quality software and hardware. 🙂

[Ben]

"Setting the LV process to use both CPUs brings down the number of wrong answers to about a third of what it was with a single CPU. "

Did you ever duplicate this on another machine?

This still sounds like it could be hardware issue.*

Ben

* As illustrated with the bug that intel had with the early pentium chips, the floating point logic data paths are not protected by parity.

[tst]

No, Ben, I couldn't reproduce it on another machine, but to be honest, I didn't really try. What I can say though, is that 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.

---

@sth wrote:

My guess is that in LV 7.0 there was a bug in printf routine that was linked into LV. As was mentioned previously, it doesn't seem to reproduce under either LV 7.0 or 8.5 on the Mac. Quality software and hardware. 🙂

---

Scott, my suspicion is also that this is something which is potentially a bug not in LV itself, but in the C run-time or even in the OS\CPU. The reason I think this is potentially serious is that I'm not at all sure the problem is confined to my setup - as far as I can tell, the problem was not duplicated not because it does not occur in other systems, but because it only happens under certain conditions. I haven't been able to get it in my computer either most of the time.

At the moment this isn't impossible for me to work around - it only seems to affect conversions to strings, which is not what I would consider a mission-critical function. I do want to make certain, however, that is all it affects and for that I need NI.

[ClintM]

Hello tst,

I've tried reproducing this on several machines here and have been unable to do so.  Since nobody else on here has been able to reproduce it either, it seems to point more toward your hardware configuration.  Could you provide us with your PC specs?  I assume you are still on Win XP and LV 7.0?

Regards,

CIint M
National Instruments

[tst]

Yes, I also suspect that this is an issue with specific OS\Hardware, but I'm fairly sure it's not unique to me.

The laptop is a dual core DELL Latitude D820 with Win XP pro and 1 GB of RAM and with no mystery hardware or software with 7.0 being the only version of LV installed on it.

You should note that this is not an easily reproducible issue even on this computer - I have seen on several separate occasions, but it definitely does not happen most of the time. Each time I saw it I was running a specific program which uses up a lot of RAM. The situation then persisted in other VIs (like the example I uploaded) and I think was only resolved by rebooting, although it's possible restarting LV also helped. When this happened last, I think it stopped even without rebooting, since I tried to recreate it later and did not manage to.

I thought that this might be happening because of using up memory and going through the swap file, but I wrote a small app to eat up memory so that I could try to reproduce it and ran it a few times without reproducing this behvavior. I will need to try some more.

The only "special" thing I'm doing in the program where I see this happening is using some .NET and ActiveX objects to do all kinds of things. I suppose it is theoretically possible that one of them is corrupting LV's memory somehow, but I doubt it would produce such consistent results and I think .NET at least is supposed to have its own memory management (?). In any case, that would not explain why increasing the priority of the VI caused this behavior to stop.

Is there anything you can suggest that I do if I run into this behavior again so that you can get some more information about it? If necessary, I could probably set some INI debug keys beforehand if it would not hurt my performance or stability.

[Ben]

Hi tst,

Please see the wiki article on "Pentium FDIV bug".

Still sounds like hardware could do this.

Ben

[altenbach]

But the FDIV bug is reproducibly wrong, while here we are dealing with an intermittent problem. A weak memory bit or CPU register shold have much more dramatic effects than this.