LabVIEW Idea Exchange

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

Booleans should coerce to 0,1 when mixed with numeric operations

Status: New

This is an extension of Darin's excellent idea and touches on my earlier comment there.

 

I suggest that it should be allowed to mix booleans with numeric operations, in which case the boolean would be "coerced" (for lack of a better word) to 0,1, where FALSE=0 and TRUE=1. This would dramatically simplify certain code fragments without loss in clarity. For example to count the number of TRUEs on a boolean array, we could simply use an "add array elements".

 

(A possible extension would be to also allow mixing of error wires and numerics in the same way, in which case the error would coerce to 0,1 (0=No Error, 1=Error))

 

Here's how it could look like (left). Equivalent legacy code is shown on the right. Counting the number of TRUEs in a boolean array is an often needed function and this idea would eliminate two primitives. This is only a very small sampling of the possible applications.

 

 

Idea Summary: When a boolean (or possibly error wire) is wired to a function that accepts numerics, it should be automatically coerced to 0 or 1 of the dominant datatype connected to the other inputs. If there is no other input, e.g. in the case of "add array elements", it should be coreced to I32.

10 Comments
Manzolli
Active Participant

The only one I'm sure that it will be a real gain is the 3rd (3 functions by 1). The first two can be dona by the Select function (1 function + constant or function (Increment) by 1). The last one will be less compute intensive with an And Array Elements followed by a Boolean to (0, 1) (2 functions by 1):

 

2013-10-17 comentário sobre a sugestão do Altenbach.jpg

André Manzolli

Mechanical Engineer
Certified LabVIEW Developer - CLD
LabVIEW Champion
Curitiba - PR - Brazil
altenbach
Knight of NI

> The last one will be less compute intensive

 

That is a statement nobody can make, because we really have no idea what the LabVIEW compiler does under the hood. It might even generate identical code for the various diagram versions. 😉

Darin.K
Trusted Enthusiast

I am torn, this is about half of a step farther than I am inclined to go.  It is better than the status quo, especially the default I32 which we all agree on, but I think I would be happier leaving the coercion but skipping the to 0,1.  I find the conversion node a bit of extra documentation.  Banker's rounding forces me to round 0.5 Kudos to 0 Kudos, but on the other hand flattery will get you somewhere sometimes....

Manzolli
Active Participant

No body can make? Sure some people can, you know some!



Boolean is a simpler data thaan Integer (I32and an “And” function is much simpler than a “Multiply” of Integers, at least in theory. Agree that the way the data is stored and functions are implemented can make the real world completely different from the theoretical situation.



Bottom line: in a small vectors doesn't matter, in a big one can be an issue.

André Manzolli

Mechanical Engineer
Certified LabVIEW Developer - CLD
LabVIEW Champion
Curitiba - PR - Brazil
JÞB
Knight of NI

Kudos, but there is a potential way to shoot ourselves in the foot here.  Take the case of String to byte array Typecast to array of boolean (any byte to bool typecast would be equivallent but, String to bool array is one I've used in the wild)  Where do the other 7 bits get masked?  in the Cast (new cast method) or in the coersion?


"Should be" isn't "Is" -Jay
altenbach
Knight of NI

Yes, of course the booleans will be clean. The implicit "Boolean to 0,1" aready handles this correctly, so there is nothing new to invent. There is no casting involved anywhere.

altenbach
Knight of NI

Implementing this idea would also magically solve this old one. Just saying. 😄

AristosQueue (NI)
NI Employee (retired)

What follows is my personal opinion as a LV user. I am not speaking for R&D here.

 

I really hate this idea. Oppose it deep within my soul. This is *exactly* the sort of weakening of the type system that for me at least would massively increase miswiring. I do not want this nonsense. This sort of language decision cannot be left as an options setting -- it's fundamental, so this isn't even something I can support as an option for you. I don't care that you think this code is readable. It would be a substantial burden on my programming if LabVIEW allowed this kind of violation. I supported the error wire connecting to various logical operations, but R&D did not make the error cluster generally coercible to all Boolean terminals, and I thought this was an excellent decision. I don't see any similar limited use case for Bools mixing with numerics.

altenbach
Knight of NI

>  Oppose it deep within my soul.

 

The current workarounds would be much less painful if R&D would finally implement an output configuration for the "boolean to 0,1" function (or at least default it to I32!). It would make a great difference for the "add array elements" part, because the current I16 output easily overflows with todays big data, creating problems that might be much harder to troubleshoot. 😄

 

Yes, we definitly should get a coercion dot to warn the user that the operation involves extra steps.

 

How do other programming languages handle this? I would definitely be opposed to pure boolean usages such as TRUE+TRUE=2 or similar. Maybe you are right overall.. That's why we have ideas and discussion of ideas. 😉

AristosQueue (NI)
NI Employee (retired)

My opinion: If something else is the bug, NI should fix that, not introduce janky coercions as workarounds.