LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
McTOM

Upgrade format string's "%d" behavior to serve large numbers

So today it seems that my company has reached a critical enumerator value of 2147483647. It caused some trouble since I'd never expect a "%d" to be restricted merely to 32-bit signed integer! A provided picture shows a solution to a problem, treating a number as 0-precision float.

Also, what kind of idea is to coerce an input value into the range unrelated to input's data type?

 

I use LabVIEW 2011 SP1.

9 Comments
AristosQueue (NI)
NI Employee (retired)

Short story: This is a behavior that cannot be changed without breaking run time behavior of existing applications. It has been explicitly rejected by LabVIEW R&D. Although using the %f code that you noted does work, I suspect that the fix that you probably want to be using is to cast your values to a U64 or I64 data type and then wire that into the Format Into String primitive.

 

Long story: For 25+ years, LabVIEW (and most other progams) did not have 64-bit integers. The %d thus represented the largest integers possible in the system. All floating point values were coerced to I32. This applied on both read and write.

 

When LabVIEW began support for larger integers, we could not change the rules for coercion without breaking applications that were perhaps relying upon that coercion (like checking "equal to MaxI32" to trigger special code sections). Thus when a floating-point number is connected to a terminal represented by a %d, it continues to be converted to I32. If however you wire a U64 or I64 type to that terminal, it works as you would expect for those large types. Thus if you are explicit about the coercion that you want -- by dropping your own To I64 or To U64 node -- you tell LabVIEW which way to do the coercion instead of it supplying the coercion.

Darren
Proven Zealot
Status changed to: Declined
X.
Trusted Enthusiast
Trusted Enthusiast

Just out of curiosity, where is this subtlety detailed in the Help files? I could not find it in the "Format Specifier Syntax" Help page...

AristosQueue (NI)
NI Employee (retired)

I doubt it is explicitly called out any where. That's simply the behavior it has always been.

X.
Trusted Enthusiast
Trusted Enthusiast

I mean the fact that if you connect a float into a %d format to string input, it will be essentially casting the value to a I32 (if I understood the above correctly). If that is the case, it would seem worth mentioning in the Help. But that may just be me...

AristosQueue (NI)
NI Employee (retired)

X: Again, I doubt it. I did file the CAR to add that tidbit to the documentation.

McTOM
Member
X. this is exactly the case, and I was hoping that my attachment would make it clear.

 

At least a little tip in the "format string syntax" help page would do, that the "%d" tag functionality is unupgradable since the 1980s, although %f seems to work fine without coercing back to 32-bit variable.

AristosQueue (NI)
NI Employee (retired)

McTOM: That's because %f never did coercion. It has handled floating point values from its beginning.

 

In the problem case, you have wired double to a terminal and told it to format as %d, which means -- and has always meant -- "coerce to int32 and then display".

 

When we add a new data type, we pick how that data type will work when it is formatted by a given format code. What we do NOT do is change how OTHER data types are formatted. So just because Int64 was introduced does not give us the option to change the coercion of double connected to %d without potentially breaking user code. Mutation (by inserting a manual "coerce to i32" to maintain old behavior) isn't viable because the format string terminal can be dynamically computed, so we wouldn't know which terminals to add the coercion bullet to.

X.
Trusted Enthusiast
Trusted Enthusiast

The CAR will need to address the fact that this undocumented behavior is not identical to that of the Number to Decimal String convention which does cast to a 64 bit integer (LabVIEW Help). I personally was not aware of that subtlety (and had not had to worry about it until now), but I can see where it could lead to some tremendous amount of headache in some cases.

 

Screen Shot 2014-07-28 at 9.44.19.png

Screen Shot 2014-07-28 at 9.44.25.png

 

PS: I am not utterly convinced that a "fix" would break havoc in some legacy code (essentially some coder would have to have relied on a float to be cast to I32 but at no cost to I64?), but I can understand that this is a company policy requirement.