LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
crelf

Make "Split Number" and "Join Numbers" primitives growable

Status: New

Say I've got 4 U8s that I want to join into a U32 - right now, I have to build 2 of the U8s into a U16, then build the other U8s into a U16, then build the 2 U16s into a U32.  I'd like to see these primatives growable to each datatype width.





Copyright © 2004-2023 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
10 Comments
Norbert_B
Proven Zealot

Just a little question for clarification:

Should the growth be 2=>4=>8 or "linear"?

If it should be "linear", should be a '0' pre- or suc-ceded?

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
crossrulz
Knight of NI

I'd say make it linear and fill with 0 in the MSBs.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
AristosQueue (NI)
NI Employee (retired)

I'd say exponential, but only because we don't have any nodes that grow that way and it would be more fun to build.

 

Sometimes I have strange criteria for features, which is why I have to be conscious about taking off my LV R&D hat and putting on my LV User hat. 🙂

altenbach
Knight of NI

Here is a related idea.

JackDunaway
Trusted Enthusiast

+1 for growth by 2^N - let the application programmer explicitly wire the 0's in the high or low bytes as a self-documentation exercise and diagram readability.

crelf
Trusted Enthusiast

Yep, definately exponential.  Unless you're going to start supporting U12s 🙂





Copyright © 2004-2023 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
Intaris
Proven Zealot

We use oddly sized data on FPGA and there it would require linear expansion......

 

Please linear and not exponential expansion....

Dragis
Active Participant

I could use this in many places. I would prefer a linear expansion where any padding can be defined to be undefined or the type default. For my use cases, undefined would work fine as I would only pull the data back out or use the bits that I explicitly put in. Kudos!

crelf
Trusted Enthusiast
What would happen if you pulled out an undefined element? Would you expect the VI to break? Or would you just expect the developer be savvy enough to remember what's supposed to be in there? The




Copyright © 2004-2023 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
Dragis
Active Participant

I wouldn't expect the VI to be able to break since the Join and Split may be in different VIs (i.e. this is probably something we wouldn't include in the type of the wire). As a compiler implementor, I would hope users would expect ANY value of the given type to possibly come of the node, although the most likely case is that a default-default for that type would be given. Yes, choosing that puts extra burden on the developer to ensure they handle it properly, similarly to how you would use typecast or any other reinterpret-like functionality.