LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Scan from string repeatability with floating point numbers

I know floating point equality comparisons are BAD, but, empirically this seems to be OK so I'm hoping for a sanity check.

 

I have a cluster that I want to use as a map key, in order to uniquify some data, but some of the elements are singles or arrays of singles. Worth noting, the map seems to do a bit-level equals comparison, as I would expect, which means the singles must be identical.

 

Now, that said, these singles will always be constants of some value with 3 decimal points or less, which are read in as an ASCII string, then converted to numbers using Scan From String. There is absolutely no math involved (explicitly at least). So, will a Scan From String always yield the exact same number on the same machine with all other factors held constant? Doing a fair bit of testing, the answer seems to be yes, but it would be nice to get verification.

 

(Note, I recognize this would definitely work if I did the string conversion later in the process; I'm open to that possibility, but it is a little less messy to do it up front if possible.)

--------------------------------------
0 Kudos
Message 1 of 7
(2,477 Views)

Like you, I would expect the answer is yes, but just for fun (?), here's a related story:

 

Back in LV 7.0, I had a program which did the reverse process (convert a number to a string). You would naturally expect that if you convert the same number with the same number of digits repeatedly, you would get the same string, but I was seeing cases where this wasn't happening.

 

The short version of what happened was that I was interacting with .NET code which was changing the precision of the processor and not changing it back, thus causing the conversion to be done at a different precision and give slightly different results.

 

You can see the discussion starting from the basic answer here:

 

https://forums.ni.com/t5/LabVIEW/Number-to-fractional-string-intermittently-wrong/m-p/587799#M274930


___________________
Try to take over the world!
Message 2 of 7
(2,329 Views)

@tst wrote:

...

The short version of what happened was that I was interacting with .NET code which was changing the precision of the processor and not changing it back, thus causing the conversion to be done at a different precision and give slightly different results.

...

Now that you mention it, (and since we're doing story time 😀) I actually remember seeing someone hit that same basic issue using a CLFN. Their DLL was changing the rounding mode (or something of that nature), and not setting it back, which caused some strangeness down the road. I'd argue that was self-inflicted, however.

 

Also, wrt this post, I just realized that my database actually stores some of the data as actual floating point numbers instead of strings. I don't necessarily trust the OLE driver I'm using to be bit-for-bit consistent, so the original question is somewhat moot.

 

I think if I scan the number I get from the database to a string with 3 decimal points, I assume I can trust that to be consistent to use for a key. Kinda gross going number -> string -> number, but speed isn't particularly important in this application.

--------------------------------------
0 Kudos
Message 3 of 7
(1,878 Views)

@ChrisStrykesAgain wrote:

I think if I scan the number I get from the database to a string with 3 decimal points, I assume I can trust that to be consistent to use for a key. Kinda gross going number -> string -> number, but speed isn't particularly important in this application.


A decent DB interface allows you to work with binary values. In LabVIEW, this is often done with variants, coming from either AX or .NET data types. With .vims these can be handled almost transparently.

 

Much better than dealing with ASCII conversion, especially with doubles and timestamps.

Message 4 of 7
(1,867 Views)

At the moment, I'm interfacing with an Access database using the NI Database Connectivity Toolkit and the Jet OLE driver.... I'm not sure how you want to categorize that, but I'm not immediately familiar with how to pull binary values using DBCTK nor am I convinced that the Jet driver would interpret them consistently or that Access would store them appropriately anyway.

 

(NOTE: This is only to do a one time migration of the existing data to a new database. The new database is still being determined, but will NOT be Access and doesn't necessarily have to be interfaced with using the DBCTK. That's a different conversation though.)

--------------------------------------
0 Kudos
Message 5 of 7
(1,815 Views)

@ChrisStrykesAgain wrote:

At the moment, I'm interfacing with an Access database using the NI Database Connectivity Toolkit and the Jet OLE driver.... 


IIRC, the DBCTK uses ADO. ADO does allow interfacing with ActiveX (binary) data types. IIRC, the DBCTK even has VIs for that, accepting\returning variants. I'm not an expert on the DBCTK though, but I think I looked over someone's shoulder. IIRC the other (open) database toolkit has this as well. Or perhaps I added it to it myself. I now use a .NET bases DB driver, that also allows variants.

 


@ChrisStrykesAgain wrote:

I'm not sure how you want to categorize that, but I'm not immediately familiar with how to pull binary values using DBCTK nor am I convinced that the Jet driver would interpret them consistently or that Access would store them appropriately anyway.


The point of the variants is that they are interpreted consistently. For some databases (Access) you'll have to convert timestamps (and floats?) to the system settings.

 

I know half of the world ignores this, but some computers are configured to use commas as decimal separators, and time can be configured just about 50 different ways. Passing binary objects eliminates the need for this configurating.

 


@ChrisStrykesAgain wrote:

That's a different conversation though.)


It is. Sorry to get OT.

Message 6 of 7
(1,772 Views)

wiebe@CARYA wrote:

I know half of the world ignores this, but some computers are configured to use commas as decimal separators


The countries that do have a official system split pretty 50/50, i thought it was more skewed.

http://www.statisticalconsultants.co.nz/blog/how-the-world-separates-its-decimals.html

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 7 of 7
(1,755 Views)