MinValue and MaxValue constants for integer types

[Petru_Tarabuta]

In .NET each of the integer data types provides two constant fields, named MinValue and MaxValue. These constants return the minimum and maximum values that can be stored in that data type. For example, for Int32 MinValue would return -2147483648 and MaxValue would return 2147483647.

It would be nice if there would be similar constants in LabVIEW for all eight integer data types. These constants would be similar to the DBL constants that already exist: +Inf, -Inf, Machine Epsilon and NaN, and would be similar in concept to string constants such as Space Constant and End Of Line Constant.

The new constants could be placed in the Numeric palette, or in a new sub palette of the Numeric palette, as shown in the image below. I would be happy with any location.

I am aware that I can easily create constant VIs to implement this functionality, which would be very similar to how Space Constant.vi is implemented, but it would be nice if the constants were built-in.

My current workaround when I need the min or max values of an integer data type is to drop a numeric constant and type something like -9999999999999999 or 9999999999999999, which after Enter is pressed LabVIEW correctly coerces to the min or max value.

Thanks

[wiebe@CARYA]

Range Limits for Type.vim returns those values.

It's bottom left on the picture you posted.

I'm not sure what a constant containing the value would add.

[AristosQueue (NI)]

> I'm not sure what a constant containing the value would add.

Use of a named constant would document intention of developer instead of leaving a magic constant on the diagram.

[wiebe@CARYA]

>> I'm not sure what a constant containing the value would add.

>Use of a named constant would document intention of developer instead of leaving a magic constant on the diagram.

But wouldn't using Range Limits for Type.vim document intention?

[AristosQueue (NI)]

> But wouldn't using Range Limits for Type.vim document intention?

It's two outputs when I only need one. Not as clean.

[AristosQueue (NI)]

And it needs a type wired into it, but numeric diag constants don't show their type. Independent icons for i32 vs u32 vs etc would be better.

[Petru_Tarabuta]

>> Range Limits for Type.vim returns those values.

Thanks, good to know! However it still seems like a workaround. I would prefer the constants for the same reasons that AristosQueue mentioned.

[BertMcMahan]

You could make a polymorphic VI that handles this pretty easily. The subVI's can use the Range Limits behind the scenes, and you can select your type with the right-click menu. Make each icon be roughly 1/4th the size of normal and it'd look like it was a baked-in constant.

(Just throwing this out there since it seems to me that ideas that CAN be user-implemented are rarely implemented by LV R&D)

[wiebe@CARYA]

If you really want 22 individual icons, you can simply make one VI for each of them...

Key here is that they are added (by NI) to a palette.

It would be nicer though if these where not VIs, but primitives, like empty string (prim), not space constant (vi).

[BertMcMahan]

Is there a performance difference between primitives and inlined VI's? I don't see any use-case differences between the two, but I can definitely understand if there were behind-the-scenes differences. Maybe it's faster?

[wiebe@CARYA]

You can open a VI, and (accidentally) mess it up.