Number to fractional string intermittently wrong

[Ben]

tst wrote "To be honest, this bug really scares me now. "

Same here. I wonder if this is in some way associated with Kevin's scepticism about the timestamps returned in the waveforms of DAQ reads. He has written that he does not think they are precise enough for what he does. Although I have never seen anything close myself, my DAQ systems timing requirements are not pushing that many sig-figs.

Ben

[sth]

This is a bit scary. But we always have relied on compilers to do what we told them. There is always the problem of underlying bugs in libraries. One of the costs is the quality and reliability of what you use.

The old debate of Opensource/freeware where you can inspect and find the error yourself vs. commercial ware which has much more quality control but you are at the mercy of a software black box. Things can be used for years and still have fundamental flaws that you don't know about until you look for it. We had a commercial power supply controller (non-LV) and found out that it skipped a beat about 1/day. The designer said that it had never happened before and stuck to that until I challenged that it had never been run on a system that checked this. He had to admit that it could have happened all along but we were the first installation sensitive to that error.

It is difficult to test all possible combinations so one goes for the corner cases. Identifying those corner cases is a bit difficult and obviouly this one got through. Joel On Software explains some of the problems of testing and a big Excel bug in formatting that is related. This will disturb more folks than a small change in LV. Does NI use the same library as excel and does the "close to 65535" bug show up in LV on windows?

[tst]

---

@sth wrote:

Does NI use the same library as excel and does the "close to 65535" bug show up in LV on windows?

---

You should note that the problem is not LV's math skills - I assume LV implements all the math in straight C to conform to IEEE 754 and *maybe* uses some external libraries for it. The problem here is that sometimes, when you (the user) call a Microsoft external code function, it changes the precision of the CPU to double and doesn't set it back after it's done. That means your thread now has double precision when it thinks it has extended precision.

[sth]

As Joel points out, that testing wouldn't show this since the value is correct, but the conversion to a string to display in the cell is the problem. It appears that you are bitten by this same routine which sometimes executes in EXT and sometimes in DBL precision and gets different answers. The Excel bug is that a certain bit pattern triggers an incorrect conversion to string. The second bug also depends on the exact representation of a string that is almost an integer but not quite (ie 3 * 0.3333333333... != 1.0) this may or may not also be a problem within LV depending on library usage.

All of these diagnosis are somewhat theoretical unless you have the actual source code in hand.

[tst]

Here's an example of the issue I mentioned in reply 16. It's the same program, so it's probably the same cause.

The VI rounds an array of DBLs to a precision. When this was working wrong, the VI rounded these numbers wrongly (e.g. 200.41500000000002 with a precision of 2 was rounded to 200.410000000000025000 instead of 200.420000000000016000, which caused it to be 200.41 instead of 200.42). I saved the VI with the current values as default after a wrong run, so running the VI now will show this clearly, as it produces the correct result, which you can see alongside the wrong result.

[Kevin_Price]

Not to divert the thread, but Ben mentioned my skepticism about timestamps in DAQ and I figured I should clarify.  My skepticism concerns other matters that seem entirely unrelated to the issue in this thread.  For example:

1. In a triggered or an externally clocked acquisition, the "t0" value is set by the call to DAQmx Start, even if the trigger edge or external clock edge doesn't occur for several minutes or hours.  Thus the t0 timestamp field of a waveform datatype can be misleading. 

2. In an externally clocked acquisition, the "dt" value of an AI waveform seems to be set by whatever you wire into DAQmx Timing as the "rate".   I guess that's the only sensible behavior, but it still burned me the following way.  I configured a counter pulsetrain to clock my AI.   Then I queried the counter task for its frequency which I wired into the AI task as the "rate" input.  Trouble was: the user-specified rate wasn't possible to implement on the counter, but my query to the counter task returned the requested freq rather than the actual freq.   I don't now recall whether this was *only* because the counter task had not yet been started, or whether there was a flaw in an older DAQmx version that did this even after the task started.  In any event, it was another reason for me to be wary of waveform timing info.

Back to the regularly-scheduled thread...

-Kevin P.

[Travis_M.]

Hello tst,

Still not sure if anyone has been able to reproduce this or if we have a good explanation other than external code setting your fpu precision incorrectly.  You put a note in your VI that you are using this unusual rounding method because LabVIEW rounds to the nearest even integer.  You may know this already, but if not, the even rounding is done in accordance with the scientific rounding rules for base-10 numbers ending in a 5.

With regards to this problem specifically, I'd really like to see if anyone else can reproduce this... if not, it seems to be specific to your system (perhaps it's a problem with your processor or memory) or with the unique software configuration you are using (i.e. are you concurrently running anything that would interfere with the precision like was mentioned by Brian). 

About the only thing I can think of for debugging right now would be to further try to isolate this problem to a specific node.  Can you create indicators for values after each node in the diagram and check those values on a 'bad' run?  It could be something like the "power of 10" function is responsible somehow....



Message Edited by Travis M. on 12-05-2007 01:41 PM

[tst]

This is the same program and the same section of the program as before, so it has all the same interaction with .NET, which is probably the source of this. This VI is actually several weeks old, but I didn't get to uploading it until now. At some point I changed the execution system of either the VIs that do the calculations or the .NET VIs as a workaround and I haven't seen it since, but I only get to work on this program about one day a week, so it's also possible that it didn't help.

This also happened the same way as the other issue (intermittently), which is why I noticed it. What I actually wanted to point out here was that a number which was clearly supposed to be rounded up (since it had a *500...01 as a fraction) was rounded down, presumably because the changing resolution moved it below the 5 value. This also shows clearly that this affects numerical calculations as well (like Brian said) and not just conversions to strings.

P.S. Yes, I'm aware that the IEEE 754 standard implements banker's rounding, but my client didn't want it.

[Gabi1]

---

With regards to this problem specifically, I'd really like to see if anyone else can reproduce this... if not, it seems to be specific to your system (perhaps it's a problem with your processor or memory) or with the unique software configuration you are using (i.e. are you concurrently running anything that would interfere with the precision like was mentioned by Brian). 

---

i was sure i observed it yesterday when running tst vi, but i cant reproduce now (tough on a different computer).

Message Edited by Gabi1 on 12-05-2007 09:26 PM