LabVIEW Idea Exchange

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

MinValue and MaxValue constants for integer types

Status: New

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.

 

1 C# min and max values.png

 

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.

 

3 Where to place the constants in LabVIEW (edited).png

 

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

17 Comments
wiebe@CARYA
Knight of NI

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)
NI Employee (retired)

> 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
Knight of 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.

 

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

AristosQueue (NI)
NI Employee (retired)

> 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)
NI Employee (retired)

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
Active Participant

>> 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
Active Participant

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
Knight of NI

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
Active Participant

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
Knight of NI

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