Join Numbers Big vs Little Endian

[Guy Drew]

I would like to see the Join and Split Numbers function to be expandable and polymorphic. I’m not arguing big vs little. Just accept there are two Endian worlds and work with them. Have you ever joined two or four numbers from a data stream in Little Endian? You have to change the order and cross wires as shown in figure (1).

This is not that clean and it gets worse when you need to split numbers and send them back to a device. Because I join and split a lot of numbers I created a library of vi’s that are clean on the diagram and visually indicate Big vs. Little Endian. A simple arrow works for me to indicate Big vs. Little Endian shown in figure (2). This Library is also attached.

I know the Join and Split two numbers in Big Endian is the same function in LabVIEW. This provide visual consistence on my block diagrams. An example of block diagram code that shows the difference between Big and Little Endian form is shown below in figure (3).

Here is what I would like to see National Instruments create. Make the Join and Split Numbers function to be expandable and polymorphic. The words are only going to get bigger and there will always be two Endian worlds. Make the Join and Split Numbers vi’s expand like the build array function. Click and drag possibly in groups of 2 i.e. 2, 4, 6 and 8 inputs or outputs for the Split Numbers vi. Of course the output data type would correspond to the number input connections. The polymorphic examples are shown below in figure 4.

To take the polymorphic function one step further it could include the data type. There are times when I need to join numbers and convert to a signed integer or a double floating point. A demonstration of the polymorphic data type is shown in figure 5 and 6 with before and after examples.

Expanding the functionality of the Join and Split Number vi’s will reduce block diagram clutter, increase coding speed and maintain visual readability. What do you think?

[altenbach]

I don't like the fact that you need to go from the byte array to scalars before joining. That seems to overcomplicate things.

If your array has the right number of elements, a typecast often works better: You get big-endian directly and if you want little endian, reverse the byte array first.

Also remember that "flatten/unflatten from/to string" has a byte order selector. Most often, raw data comes in as binary string first, so the byte order can be applied before it even turns into a numeric. This is often a better solution.

You can even flatten to string and back to do any endian conversion.

What is missing from your suggestion is scaleability. We need a toolset that can generically swap the byte order of complicated numeric clusters or long numeric arrays. Nobody works on massive amounts of data one scalar at a time. 😄

I also have a problem with your floating point suggestion. If you want polymorphism, I would have expected it to cast 4 bytes into a SGL (or 8 into a DBL), not convert it to an signed integer, then converting to a DBL. Too exotic and unexpected!

[Guy Drew]

I created a complete library containing four polymorphic vi’s with the following function.

Join Numbers 2 Polymorphic: big-endian, little-endian, U16, I32 or DBL

Join Numbers 4 Polymorphic: big-endian, little-endian, U32, I32, DBL or Time Stamp

Split Numbers 2 Polymorphic: big-endian, little-endian, U16, I32 or DBL

Split Numbers 4 Polymorphic: big-endian, little-endian, U32, I32, DBL or Time Stamp

I would like to attach the library if I knew how.

I work on massive amounts of data one scalar at a time. See below a real life example. If you know of a better method of processing this data let me know.

[altenbach]

Since this is now turning into a technical discussion, feel free to start a regular discussion over in the LabVIEW forum. You can attach code there. Include a link to the idea. Make sure your example code contains default data.

[Guy Drew]

Now, back to the original idea, it would be nice to have a polymorphic expandable Join and Split Numbers function. I’ll leave it at that.

Kudos to JDinkins with Split Number/Join Numbers primitive connector placement