Why typecast? What is the benefit? Why typecast before sending data on network?

[tsa256]

Hello everyone.

I have a rather simple and straightforward question. Yet Google does not seam to have the answer.

Basically, I curious why should we typecast something? It seams to me that it's just kind of like a "band-aid" to change the convert data to a new datatype, when it was not properly declared with an appropriate data type. What would the benefit of this be?

Furthermore, I see a lot of programs type casting data to U8 before sending it across the network. Various comments say it is for speed, but I can't comprehend how it improves speed. The same amount of data is still being sent, just in a different datatype. Is this overcoming a limitation of the network. Does the network somehow send smaller data types faster?

I been curious about this for a while, and have yet to find an answer. Any help is highly appreciated.

Thanks,
Taylor S. Amarel

[Cory_K · Accepted solution]

---

tsa256 wrote:

Basically, I curious why should we typecast something? It seams to me that it's just kind of like a "band-aid" to change the convert data to a new datatype, when it was not properly declared with an appropriate data type. What would the benefit of this be?

---

It really depends on specific situations.

For example, some functions explicitly require certain data types as inputs if they are not polymorphic.

This means that if you do not typecast the data yourself, LabVIEW will do it for you, and you will see a red coersion dot.

As for why the data wasn't the correct data type in the first place, sometimes it is unavoidable.

Some examples

- what if you are just reading a text file as one long string.

If there is numerical data in that file, you have to parse it out, then convert it to some usable type (int, sgl, dbl, etc)

- you are given a 3rd party VI, dll, etc which returns a numeric value as a double but you need the value to be I8.

You cannot change the output of the function that you were given, so all you can do to remedy the situation is typecast the data.

---

tsa256 wrote:

Furthermore, I see a lot of programs type casting data to U8 before sending it across the network. Various comments say it is for speed, but I can't comprehend how it improves speed. The same amount of data is still being sent, just in a different datatype. Is this overcoming a limitation of the network. Does the network somehow send smaller data types faster?

---

This sort of relates to my first statement, but in a more general sense.

Many of the functions way down on the OS level are performed in binary.

If your data is not already in binary, the sending computer has to convert it to binary, then send it, then have the receiving computer convert back.

The two conversions on either side of the transmission add unnecessary cycle time.

[Dennis_Knutson]

It's not a band-aid at all. I don't know what you exactly mean by 'sending data on network' but if you look at the such functions as the TCP/IP Write, you will notice that the data type of the input is a string. Anything can be represented by a string and it is an appropriate single data type for writes and reads. So, if the original data is something else, you would typecast that before sending. The original data might be a DAQ read and obviously that is appropriate and properly declared. The same is true with a TCP/IP read. You would need to typecast the string to numeric if you want to manipulate/plot the data.

If you have programs that typecast to U8 or have comments mentioning speed, it would be appropriate to link to them or attach them since it is impossible to respond to some phantom references.

[Taki1999]

Smaller data types don't transmit at a faster rate but they do complete the transmission sooner.  (i.e. 255 in U8 will be received earlier than 255 in U16 since the receiver still has to look at the upper 8 bits which aren't being used.)

Similar reasoning is used for packing an array of booleans into U8 before transmission.  (i.e. the LabVIEW representation of a boolean is 8 bits, but you can pack 8 booleans into a single U8.)

Mostly guessing but programs that typecast to U8 before transmission over a network are probably taking the above into account.

[Cory_K]

---

@Taki1999 wrote:

the LabVIEW representation of a boolean is 8 bits, but you can pack 8 booleans into a single U8.)

---

Really?! Why do they do that?

[_Ian_]

---

@cory K wrote:

Really?! Why do they do that?

---

Can't say I know the reasons, but there is some examples of it in the obfuscated code thread...

http://forums.ni.com/t5/BreakPoint/A-call-for-obfuscated-LabVIEW-code/m-p/780383#M6565

[LV_Pro]

Because each boolean is handled individually. As a discrete object the smallest unit that LabVIEW can use to describe it would be a U8.

[Cory_K]

Oh okay. Hmm, still seems wasteful 

And quasi-random "if any of the bits are true then the whole boolean is true".

So all of the following are true:

00000001

10000000

11111111

00011000

I get the explanation, it just seems weird to me.

[smercurio_fc]

---

@cory K wrote:

Oh okay. Hmm, still seems wasteful 

---

Well, in the Windows API a "Bool" is actually an int. Which in 32-bit systems is a 32-bit integer. Feel better now?

[johnsold]

I think early versions of LV did pack booleans.  At some point it was changed.  Perhaps the release notes for the version where that change was made would give some insight.  As a guess I would say it was LV 4 -> 5 or LV 5 -> 6, but that is just a guess.

Lynn