LabVIEW
Latitude & Longitude string to number through type cast
Spruce wroteI imagine that Labview isn't playing by the rules, as usual. The type cast function is defined as performing the equivalent of *(type *)&x, (a cast in 'C' being used to reinterpret binary data without altering anything), so it should do exactly that. Clearly there's some additional magic going on under the hood with the extended precision type, but this isn't documented in the help page for the type cast function. I also notice that when I wire the extended precision output to an indicator I get an "end of file" error from Labview when trying to access the properties for the indicator. Looks like all is not well with the Labview extended precision type.
There is no extra magic. It just takes more data to make up an EXT. The reason the type cast to DBL didn't work is because it cut off some of the string data when it casted it. The EXT would allow more bytes to be converted. But it is more than needed and actually increases the data size.
I agree that the conversion I gave is not that complex, and for GPS is plenty fast. They may be able to get away with a SGL pricision and reduce the size even more. But smercurio did give some good alternatives. Personally, I would parse the string into an actual number (in degrees) just as I gave earlier.
@Nagaa wrote:
There are many such strings to save , so as this takes more memory to save the data in pc i want to type case in floating and save .
This is a silly thread. 😄
typecasting does not save a single bit, it just reinterprets the existing bit pattern, so typecasting will not save you any memory or disk space. Of course if you typecast it to a representation with not enought bits, you'll truncate irreversibly.
Let's look at the string in question (78°20.54 E). Apparently, we just want to compress into binary and later uncompress. Given the format, the degree symbols etc are invariant and don't need to be stored with the data. We need sufficient bits to represent from -180 to 180 with a resolution of 1/100 of a minute. One such number can be fully stored in 22 bits (or 3 bytes with some extra padding).
Thus you can compress any such coordinate number without loss into 3 bytes (or 30% of the original string) and later restore the coordinate by reversing the process. Try it!
Spruce wrote
I imagine that Labview isn't playing by the rules, as usual. The type cast function is defined as performing the equivalent of *(type *)&x, (a cast in 'C' being used to reinterpret binary data without altering anything), so it should do exactly that. Clearly there's some additional magic going on under the hood with the extended precision type, but this isn't documented in the help page for the type cast function.
OK, which version of typecast in C++ follows your definition?
Type cast and flattened data are well documented in LabVIEW. As usual (sic ;)) you are making assumptions about these topic without actually reading the documentation.
Quote form the help on flattened data:
"LabVIEW converts data from the format in memory to a form more suitable for writing to or reading from a file. This more suitable format is called flattened data."
Flattened data is always big endian, even on a little endian platform, so depending on the computer, there is almost always some conversion going on. This ensures portability.
Also: "The flattened form for extended-precision numbers is the 128-bit extended-precision, floating-point format. When you save extended-precision numbers to disk, LabVIEW stores them in this format."
Quote from How LabVIEW Stores Data in Memory:
"Extended-precision floating-point numbers have an 80-bit IEEE extended-precision format.
Note In some cases, extended-precision floating-point numbers can have a 64-, 96-, and 128-bit IEEE extended-precision format depending on the computer processor. 80-bit is the most common."
Quote from the type cast function help:
"Casts x to the data type, type, by flattening it and unflattening it using the new data type. If the function must reinterpret data instead of transforming it, LabVIEW uses a temporary buffer."
@Spruce wrote:
As a matter of interest there does seem to be something extra going on with the EXT type, though. Try the attached vi.
Yes, it seems that the padding is not taking place for EXT.
From the help on typecast:
"If x is of a smaller data type than type, this function moves the data in x to the upper bytes of type and fills the remaining bytes with zeros."
Looks like this "fill" does not seem to be happening. That looks like a bug.
"Never" is a strong word. These things could, and maybe have, changed depending on changes in the compiler.
