Latitude & Longitude string to number through type cast

[smercurio_fc]

---

Spruce wrote

---

you still seem determined to explain that the cast wouldn't work because of the format of the string, ie the symbols contained therein. This is incorrect, the reason it doesn't work has nothing to do with the symbols.

---

Then I await with uncontainable anticipation your explanation as to why Type Cast doesn't work in this case. Please, enlighten us.

[Spruce]

---

@smercurio_fc wrote:

---

Spruce wrote

---

you still seem determined to explain that the cast wouldn't work because of the format of the string, ie the symbols contained therein. This is incorrect, the reason it doesn't work has nothing to do with the symbols.

---

Then I await with uncontainable anticipation your explanation as to why Type Cast doesn't work in this case. Please, enlighten us.

---

You don't know? Clue: a double is a 64 bit value.

[Spruce]

---

@Ravens Fan wrote:

Why do you keep arguing?  S_mercurio knows what he is talking about.

Typecast CANNOT work on a string such as that.  With or without extra symbols in it.  The only correct functions to use are the ones related to Scan from String.

---

However, if you look at the example posted by the OP, you'll find it does appear to work. Perhaps you can explain why?

[nathand]

---

@Spruce wrote:

However, if you look at the example posted by the OP, you'll find it does appear to work. Perhaps you can explain why?

---

Of course it "works" - a string is just a series of bytes, and you can reinterpret that series of bytes as an 8-byte double-precision value if you like.  However, the resulting value will have nothing to do with the numeric equivalent of the input string, and anything after the first 8 characters will be lost (as you can clearly see from the sample code to which you refer).

[Mark_Yedinak]

---

@Spruce wrote:

---

@smercurio_fc wrote:

---

Spruce wrote

---

you still seem determined to explain that the cast wouldn't work because of the format of the string, ie the symbols contained therein. This is incorrect, the reason it doesn't work has nothing to do with the symbols.

---

Then I await with uncontainable anticipation your explanation as to why Type Cast doesn't work in this case. Please, enlighten us.

---

You don't know? Clue: a double is a 64 bit value.

---

You do realize that you are arguing with two Knights of NI. Hint, there are only five Knights of NI in the entire world. You don't get there by being clueless about simple things like this. You are new to the forums and you may be a very experienced LabVIEW programmer. I can't say since your post count is very limited. What I can say is that some of the world's finest LabVIEW programmers frequent the forums. Many of them contribute heavily here. As a general rule if someone here on the forums are a "Trusted Enthusiast", a "Proven Zealot" or a "Knight of NI" you can be extremely confident these people know what they are talking about. Rather than argue with them trust what they are saying.

[smercurio_fc]

---

@Spruce wrote:

You don't know? Clue: a double is a 64 bit value.

---

Well, that certainly explains everything. In fact, let's see what will happen if we take the original example and change the datatype of the numeric constant from a DBL (8 bytes) to EXT (16 bytes). After all, we have more bits now, so it should work, right? OK, so we change the representation and run the VI... Oh dear, it doesn't work. Well, I'm certainly as surprised as when I see the hot female (post-18) chick (who naturally bared her breasts earlier in the movie) get killed by the homicidal maniac running around loose in the woods while she's out there sheepishly crying out "is anybody out there?".

Let's examine what the original goal was, shall we? The OP is saving data to a TDMS file and was complaining that the file was getting too big because there were too many strings to save. He looked specifically at the GPS data and wondered if there was a way to shrink its data storage requirements. The GPS data storage is:

Degrees: 3 bytes (0-179)

Degree symbol: 1 byte

Minutes: 2 bytes (0-59)

Period character: 1 byte

Seconds: 2 bytes (0-59)

Possible space: 0 or 1 byte (we will be conservative and assume 1 byte)

Cardinal: 1 byte

Total: 11 bytes.  (And this assumes pure ASCII)

The OP thought that since a DBL is only 8 bytes, then he could simply Type Cast the string to a DBL and save 3 bytes per value. Nice idea. Too bad it doesn't (and CANNOT) work. The OP wanted to know why it didn't work. And this whole mess of a thread started.

OK, so what are the options?

• If Type Cast would "magically" work here, perhaps if we use more bits we can do it. If using an EXT worked then we could that. Except now we've increased our storage requirement from 11 bytes to 16 bytes. So that doesn't help.
• We represent the GPS string as a value which we can then save. How do we do this? Well, we clearly need to perform some form of transformation on the values so they can be "mapped" to a DBL. (Gee, that certainly sounds like a coordinate transformation to me.). crossrulz showed one way of doing this. This transformation would give you a DBL, allowing you to use 8 bytes for storage. Great. Except now we've made the code mode complicated and certainly slower (Scan From String is not known for it speed). You would also need to perform the equivalent opposite transformation when reading the values back. So, we've exchanged storage requirement for complexity, speed, and maintenance.
• We don't change anything, and compress the file after the fact. Depending on the compression algorithm, this could save a lot, but it also depends on the data itself.
• We get a larger hard drive.

OK, so with all of that, what are our conclusions?

• Type Cast is a waste of time (despite a certain person's belief that it will magically work here).
• We can get our storage decrease requirement by using the string functions to parse the GPS string and perform a transformation of the coordinate to a numeric value that is a DBL. We pay the price of increased complexity, slower execution, and increased maintenance (more code, more maintenance).
• We can get our storage decrease requirement by compressing the file after the fact. If using the ZIP algorithm (which isn't the most efficient), we can do this in LabVIEW directly using the ZIP VI.
• We can simply buy a larger hard drive. This is probably the most economical solution given the low cost of storage these days.

Have I missed anything?

[crossrulz]

I find it really sad that the OP asked a simple question and you guys are turning it into a major argument over symantics.  Both of you agree that the type cast does not work.  Both of you agree you need to do some parsing of the string.  So stop the arguing and start helping the OP.

[smercurio_fc]

I think you misread the intent of my last message. I was trying to summarize what the purpose of the original message was (since, as you said, this whole mess of a thread turned into an argument over semantics), what the options were, and what the consequences were, if any. As i pointed out, you do not need to use the method of string parsing. You can simply leave things alone and compress afterwards.

The OP can decide for himself which method to go with.

P.S. I disagree with you about a part of the "arguing". I don't believe it's arguing to try to correct a misconception someone has on why a certain function should work, regardless of the inputs of that function. After all, all functions have certain working boundaries.

[Spruce]

---

@smercurio_fc wrote:

---

@Spruce wrote:

You don't know? Clue: a double is a 64 bit value.

---

---

@smercurio_fc wrote:

Well, that certainly explains everything.

---

It explains why the OP got the result he expected from the first of his two examples and not from the second. Do you dispute this?

---

@smercurio_fc wrote:

In fact, let's see what will happen if we take the original example and change the datatype of the numeric constant from a DBL (8 bytes) to EXT (16 bytes). After all, we have more bits now, so it should work, right? OK, so we change the representation and run the VI... Oh dear, it doesn't work. Well, I'm certainly as surprised as when I see the hot female (post-18) chick (who naturally bared her breasts earlier in the movie) get killed by the homicidal maniac running around loose in the woods while she's out there sheepishly crying out "is anybody out there?".

---

Goodness, where did all that come from?

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. 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. 

---

Let's examine what the original goal was, shall we? The OP is saving data to a TDMS file and was complaining that the file was getting too big because there were too many strings to save. He looked specifically at the GPS data and wondered if there was a way to shrink its data storage requirements. The GPS data storage is:

Degrees: 3 bytes (0-179)

Degree symbol: 1 byte

Minutes: 2 bytes (0-59)

Period character: 1 byte

Seconds: 2 bytes (0-59)

Possible space: 0 or 1 byte (we will be conservative and assume 1 byte)

Cardinal: 1 byte

---

It's worth noting that the string is actually a degrees, decimal minutes value rather than degrees, minutes, seconds. But no matter.

---

@smercurio_fc wrote:

Total: 11 bytes.  (And this assumes pure ASCII)

The OP thought that since a DBL is only 8 bytes, then he could simply Type Cast the string to a DBL and save 3 bytes per value. Nice idea. Too bad it doesn't (and CANNOT) work. The OP wanted to know why it didn't work. And this whole mess of a thread started.

---

Frankly, I doubt he thought that. I suspect he thought that a type cast was the correct way to convert data types rather than the correct way to reinterpret them.

---

@smercurio_fc wrote:

OK, so what are the options?

• If Type Cast would "magically" work here, perhaps if we use more bits we can do it. If using an EXT worked then we could that. Except now we've increased our storage requirement from 11 bytes to 16 bytes. So that doesn't help.

---

Quite.

---

@smercurio_fc wrote:

• We represent the GPS string as a value which we can then save. How do we do this? Well, we clearly need to perform some form of transformation on the values so they can be "mapped" to a DBL. (Gee, that certainly sounds like a coordinate transformation to me.).

---

 

No, the values remain latitude and longitude. A coordinate transformation would result in a different coordinate system.

---

@smercurio_fc wrote:

•  crossrulz showed one way of doing this. This transformation would give you a DBL, allowing you to use 8 bytes for storage. Great. Except now we've made the code mode complicated and certainly slower (Scan From String is not known for it speed). You would also need to perform the equivalent opposite transformation when reading the values back. So, we've exchanged storage requirement for complexity, speed, and maintenance.

---

It is very unlikely that whatever device the OP is using is capable of determining position with sufficient precision to require a double - a 32 bit float should be fine. If that string is indeed from a GPS then updates are unlikely to be faster than a handful per second. As for complexity and maintenance issues I think you're just being silly - this is a trivial bit of code.

---

@smercurio_fc wrote:

• We don't change anything, and compress the file after the fact. Depending on the compression algorithm, this could save a lot, but it also depends on the data itself.
• We get a larger hard drive.

• ---

  Compressing after the fact increases the peak disk space requirement, which may compound the original problem.

---

@smercurio_fc wrote:

OK, so with all of that, what are our conclusions?

• Type Cast is a waste of time (despite a certain person's belief that it will magically work here).
• We can get our storage decrease requirement by using the string functions to parse the GPS string and perform a transformation of the coordinate to a numeric value that is a DBL. We pay the price of increased complexity, slower execution, and increased maintenance (more code, more maintenance).
• We can get our storage decrease requirement by compressing the file after the fact. If using the ZIP algorithm (which isn't the most efficient), we can do this in LabVIEW directly using the ZIP VI.
• We can simply buy a larger hard drive. This is probably the most economical solution given the low cost of storage these days.

Have I missed anything?

---

Yes - you still haven't explained why you think the fact that the string contains symbols is significant to the result when casting that string to and from double.

[Spruce]

---

@Mark_Yedinak wrote:

---

You do realize that you are arguing with two Knights of NI. Hint, there are only five Knights of NI in the entire world. You don't get there by being clueless about simple things like this. You are new to the forums and you may be a very experienced LabVIEW programmer. I can't say since your post count is very limited. What I can say is that some of the world's finest LabVIEW programmers frequent the forums. Many of them contribute heavily here. As a general rule if someone here on the forums are a "Trusted Enthusiast", a "Proven Zealot" or a "Knight of NI" you can be extremely confident these people know what they are talking about. Rather than argue with them trust what they are saying.

---

As far as I'm aware there's only one Lobster Man from Mars, but I'd still happy to argue with him.

Quite frankly I've found the attitude of one of your 'Knights of NI' to be somewhat arrogant. This doesn't leave me feeling disposed to ignore his errors.