Rube Goldberg Code

[altenbach]

Creating a marker values color ramp for an intensity graph apparently requires:

A stacked sequence with 4 frames.

• In the first frame, we define the variables and place all terminal disconnected inside it.
• In the second frame we ensure that Max>Min, requiring a case structure, a temporary "variable" and a three frame flat sequence (picture 1)
• In the third frame we calculate several intermediary variables
• In the last frame, we create the ramp, e.g. converting a DBL to U32 that then gets immediately coerced 3x to U8 (picture 2)
• (The problem is that the result is incorrect, for example the max never appears in the output.)

Picture 1

Picture 2

I think this does it better:

 

[wiebe@CARYA]

---

@altenbach wrote:

---

I always forget about that output configuration...

You could argue that a To Unsigned Byte integer is clearer, but actually I don't even know how to get the output configuration working 🙄...

The output stays a double or breaks the wire when connected to a Join Number:

Probably a Monday morning ( 🌴😑 :palmface:) issue, but honestly I never use the output configuration.

[VinnyAstro]

---

wiebe@CARYA  a écrit :

---

@altenbach wrote:

---

I always forget about that output configuration...

You could argue that a To Unsigned Byte integer is clearer, but actually I don't even know how to get the output configuration working 🙄...

The output stays a double or breaks the wire when connected to a Join Number:

Probably a Monday morning ( 🌴😑 :palmface:) issue, but honestly I never use the output configuration.

---

Talking about a palmface: I am just discovering about the output configuration 😅

Would be nice to have it as a Right Click menu instead of full properties menu only.

[altenbach]

---

wiebe@CARYA wrote:

---

The output stays a double or breaks the wire when connected to a Join Number:

Probably a Monday morning ( 🌴😑 :palmface:) issue, but honestly I never use the output configuration.

---

Works great here!

Still, the output configurations is missing for some important function (LabVIEW 2020), for example I really would like to have it for:

• Boolean to (0,1): (Locked at I16, but sometimes I want U8 (half the memory for large arrays!) and sometimes I want I32 (e.g. when summing for counting TRUEs in an array and the number might exceed the I16 range). (Yes, there are better way to count trues, of course!)
• Round to +/-Inf or round to nearest: Here the result is a guaranteed integer, so why is the output orange and why cant we tell it what integer flavor we want???
• probably some others...

[rolfk]

---

@altenbach wrote:

---

Still, the output configurations is missing for some important function (LabVIEW 2020), for example I really would like to have it for:

• Boolean to (0,1): (Locked at I16, but sometimes I want U8 (half the memory for large arrays!) and sometimes I want I32 (e.g. when summing for counting TRUEs in an array and the number might exceed the I16 range). (Yes, there are better way to count trues, of course!)
• Round to +/-Inf or round to nearest: Here the result is a guaranteed integer, so why is the output orange and why cant we tell it what integer flavor we want???

---

While I agree about the Boolean to [0.1] function (I16 is a remainder of pre LabVIEW 5.0 times when LabVIEW Booleans were under the hood an I16) I'm not exactly sure I would want to support integer type for the Round nodes. First there is no number in any of the Integer types that represents +-Inf. Second a large part of the possible non-fractional floating point values is NOT exactly representable by an Integer value, even if you use an I64. It's not infinite because the total number of representable numbers in a floating point value is also not infinite, but the number of exactly representable rounded numbers as any integer is a lot smaller than the number of such numbers that would further have to be coerced to fit in the configured integer range.

[altenbach]

I agree with the limitations, but you can make the same argument for any other operation that currently allows output configuration (add, multiply, etc). It should just blindly act the same as if wiring an explicit "toInteger" right after it. (But yes, just wiring a conversion is probably often fewer clicks than configuring the output 😄 )