Latitude & Longitude string to number through type cast

[altenbach]

I am pretty sure it is true today. It cold have been different in ancient versions or it could change in the future 🙂

[sth]

How many Champions does it take to screw up a type cast......  🙂

The OP's question shows a lack of understanding and what we need is a clear goal.  The OP has to decide how he/she wants to store the data but typecasting won't save file space if it keeps all the string information.

1. Can pipe the strings through a compression algorithm to the file.  This keeps the file as having strings but reduces file size as requested.

2. Re-encode the data to a more compact form.

the original data showed resolution of 0.01 arc minutes this is just a hair over 21 bits of resolution (21.04 bits) this could be accomodated by encoding to a single precision float (4 bytes for convenience) or scaled to 24 bits and recorded at 3 bytes to the file saving even more.

How much effort is worth it is up to the OP.

Typecasting is wrong.  Either it will truncate information and make the file shorter or it will keep the information and make the file longer depending on the type it is cast to.

[altenbach]

---

@sth wrote:

2. Re-encode the data to a more compact form.

the original data showed resolution of 0.01 arc minutes this is just a hair over 21 bits of resolution (21.04 bits) this could be accomodated by encoding to a single precision float (4 bytes for convenience) or scaled to 24 bits and recorded at 3 bytes to the file saving even more

---

I thought that's what I said above. 😄

[sth]

---

altenbach wrote:

I thought that's what I said above. 😄

---

You did.  But this thread has gotten so redundant that I just put that same calculation back with the option to encode as a single which I believe has 24 significant bits but is easier to do binary reads and writes.  The message was that there were increasing compression with increasing work to encode/decode.

[smercurio_fc]

---

@sth wrote:

How many Champions does it take to screw up a type cast......  🙂

---

None. This whole mess of a thread was basically one big argument over semantics. I didn't see much point in continuing participation in it, since getting a thrashing from crossrulz in one thread is more than enough for me.

No offense, crossrulz.

[Spruce]

---

@altenbach wrote:

---

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?

My definition? *(type *)&x is straight from the Labview help on the type cast function. As for C++ I'd guess that a reinterpret_cast would achieve the same thing, but if I were to do it in c++ I'd use... *(type *)&x. There's a fleeting mention of "C-style casts" in the "explicit casts" section on that page, but to C++ guys proper casting is a dirty little secret they'd rather forget.

I must admit I thought that *(type *)&x was a 'C' idiom that had been around for so long everyone just knew what it meant, but seemingly not. It's a three stage process:

Create a pointer to x. (That's the '&')

Cast the type of the pointer to the type specified by, er, 'type'. (That's the '(type *))

Dereference the pointer. (That's the '*')

(Dataflow in 'C' is right to left:))

That's a fully platform dependent conversion from one type to another - all bits identical to the original. If the new type is smaller than the old any extra bits will be truncated by the dereference, if the new type is larger then whatever happens to be lying around in adjacent memory will form part of the new data. Note that unless the new type is unsigned char (u8) the final dereference invokes undefined behaviour according to the 'C' standard, but the technique has been in common use since well before the first standard was a twinkling in ANSI's eye, but provided you understand the platform, it works as expected.

---

@altenbach wrote:

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.

Oh dearie me no, I've read all the documentation. It's quite clear from the documentation for the type cast function that for an input of 'x' I should get an output of '*(type *)&x'. What magic Labview performs to get there it entirely up to it, as long as the result is as described. The only things it brings to the party are platform independence (which is fine - I know my LabviewPC is big endian:)) and the zero padding when casting up size (which seems a pretty sensible decision - if this were 'C' I'd know what lay in the adjacent memory and could take advantage of that, in Labview I'm generally not going to have a clue, so if I were to cast up in Labview I'd at least get something predictable). But - why would I want to do that in Labview? Generally there's going to be a better way of doing it.

---

@altenbach wrote:

---

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

---

I'm not sure what you're seeing when you run that vi, but when I run it I seem to be getting plenty of padding - for the 13 character string I see an all bits zero result in the array, ie none of the original data has found its way there, for the 16 character string I see the first 10 bytes from the string followed by six zero bytes.

[crossrulz]

---

@smercurio_fc wrote:

...I didn't see much point in continuing participation in it, since getting a thrashing from crossrulz in one thread is more than enough for me.

No offense, crossrulz.

---

I wouldn't call it a thrashing.  And no offense taken.  I actually laughed a little.