Floating point precision of "Flatten to XML"

[Jaegen]

It appears that the "Flatten to XML" function (LV 7.1.1) truncates floating point numbers to 5 decimal places.  This is a rather annoying limitation, since I'm trying to store a relative time in hours, accurate to the second (chosen by a previous coder that I have to be compatible with - otherwise I'd just use seconds).  Is there a workaround to this?  (other than multiplying by some power of 10 before flattening, and dividing after unflattening)

Jaegen

[DavidJCrawford]

Jaegen

I have uploaded an example (LV7.1) that shows that the precision is 10us (ten micro-seconds) before it starts to roll over. That would mean that you have better precision available than your 1 second requirement.

Does this help?

David

[Jaegen]

Your VI is flattening a time in seconds - I need to store the time in hours.

Thanks a lot for taking the time though.

[falkpl]

I havent found a way of specifying the format of the data from a float or double, you can convert the time into a multiple of its self and save it as an XML int,

like multiply the float hours by 360000, type cast into a 32 or 64 bit int then when you read it back divite by 360000.  Here you will save the values in millisecond increments (or better/worse depending on your resolution needs).  Ints will keep all significant digits.  Alternativly, you could rewrite the flatten to xml string as follows, see attachment.

paul

[Jaegen]

I hadn't thought of rewriting the flatten myself ... unfortunately, the floating point number is just one of a few values inside a cluster.  I suppose I could search the flattened string for <DBL> and then replace the value, but I'll stick with multiplying/dividing the value for now.

Thanks,

Jaegen

[falkpl]

I would also recommend multiplying and then dividing by a time constant, this way you don't have to worry about the polymorphic nature of the flatten to XML, where you would have to override just the double and single float cases.  Maybe in a future version of the XML vi NI could fix this (either use full precision, or allow for the default precision to be used) since the code is locked, we cant fix this ourselves.

Paul

[Philip_Courtois]

Hi Paul and Jaegen,

I checked our databases and found entries of product suggestions and corrective action requests for the behavior of the limited precision when flattening to XML. I found an interesting reply from a LabVIEW developer on the request for further precision:

The Flatten To XML primitive puposefully cuts off all numbers at 5 digits after the decimal. There are 3 main reasons for this:

1. Information regarding precision is not propagated on the wire. Therefore, there is no real way to know how many significant digits or even places past the decimal point is appropriate when data is flattened to XML.
2. Bloat. If all floating point values printed all of the possible decimal digits all of the time, this would provide for some very large blocks of XML code.
3. Given the arbitrarily complex nature of LabVIEW data, it is difficult to provide a method for specifying precision. For example, if a user has a cluster of clusters, each of which contain a single, double and extended representing various measurements of differing accuracy, how can one precision setting be applied to each of these values? The user would have to unbundle (and index if an array was involved), flatten, concatenate, and then the reverse on the unflatten side.

I suggest that you go ahead and file a new product suggestion by using the "feedback" link on www.ni.com/contact. It would be best if you could give some detailed information on how you would like LabVIEW to handle different scenarios while getting around the above issues.

Thanks for the feedback!

[falkpl]

Philip,

Thanks for the great response.  Maybe a flatten by reference would be a good option, here all the attributes could propagate and be passed as attributes in the XML code.  An unflatten by references could return the control back to the original state.  I do agree with the issue of bloat. I will have to think about this a little before I submit a request to NI.  Thanks,

Paul

[Philip_Courtois]

Thanks Paul - we truly appreciate the feedback from our customers, so don't forget the product suggestion when you have it thought through.

[DFGray]

Jaegen,

What are you using the flattened data for?  You might be better off using some other format.  SQL databases and HDF5 come to mind immediately - both are open standards and have LabVIEW implementations.  TDM is also a possibility.  All of these can store data in binary format so you do not lose any precision.  Any time I see "flatten to xxx", I get very nervous.  Retrieving that data usually requires knowing the data format.  Said data format tends to get lost with time, especially if all you have is the data, not the program to retrieve it.  HDF5, and TDM do not have this problem, as both are self-describing (I don't know enough about SQL databases to say).  XML theoretically shouldn't, but I have never seen an XML data storage system that didn't have problems.  XML is great for documents, but it is pretty poor at data storage.

NOTE:  The opinions above are mine and are not necessarily those of NI, my employer.