> This could be done for a lot of primitive conversions.
Yes, you're right. But I guess - it will be better to discuss each conversion separately. For example, if we need to convert Numeric to Boolean, then probably we will need additional primitive like (0,1) to Boolean...
> "if we need to convert Numeric to Boolean, then probably we will need additional primitive like (0,1) to Boolean"
Bad example. That one is called "Not Equal to 0?"
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
> Bad example. That one is called "Not Equal to 0?"
I know. But here is "philosophical" question. Lets me explain. You're correct that "Not Equal to 0" will return proper result. The problem that this is formally not conversion primitive. This is comparison primitive. In additional there are lot of comparison functions which will perform Numeric > Boolean conversion: Equal to 0, Greater than 0, etc. Putting all of them into context menu - not very good idea. So, what we need is the primitive which is "opposite" to Boolean to (0,1). Like "Path to String" is opposite to "String to Path"
My typical usage of Boolean to (0,1) is the following:
When I see this code, then psychologically I think: "well, 1 is not equal to zero, therefore true; is zero equal to zero? No. Therefore false.
In C, for example it looks like
What I prefer is something like that (the logic in 1:0? the same is Not Equal to zero):
Now the logic is clear - I have numeric which is boolean in general. Zero is false. Nonzero is true. That is all.
Like in C written
Some conversion functions are "paired" and which one is "pair" to Boolean to (0,1) - that is the question:
That should be discussed, and this is the reason why I would like to discuss each conversion separately.
Yes, I do think that the Boolean to (0,1) and Not Equal to Zero? are a pair. If you want to get into the nitty gritty, it makes even more sense. First of all, a boolean is stored as a byte. That's right, it takes 8 bits to represent a T/F value. It's that way in every language I've dealt with. Now, by definition, a Boolean is a TRUE if it's value is not 0. Any value other than a 0 is considered TRUE. Again, it's like this in every other language I have used. So it makes perfect sense that they are a pair. Maybe there's something NI could do to help people see this connection?
That said, I fully agree with the idea of showing the Boolena to (0,1) in the right click menu for this broken wire (I did Kudo it).
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
I am not sure I want to kudo this idea, although it certainly has its merits. The reason is that it is a bit rigid. Somebody may want to do something with strings (or Booleans) other than what you are suggesting, and they would not necessarilyt benefit from your suggestion and in fact, have another one instead that they would want to be pushed to the forefront. How would NI look at this? Well, we can't satisfy everybody, so let's not bother...
<shameless plug>
I have suggested in the past to have a more general approach to this "user-prefered contextual menu choice" here. In my view, your request falls into this general idea, in the sense that once you would have selected the "equal to zero?" function (in your Boolean to Integer example), the comparison palette would show up each time you would request the contextual menu for a Boolean. You would still have to browse for that specfic function, but that would be it (and relatively quick).
To me, it would be easier for NI to implement in the sense that they would only have save a (relatively small) database of palette list for each data type.
</shameless plug>
Of course, I suppose that a quick-drop plugin could be written for your purpose too...
> That's right, it takes 8 bits to represent a T/F value.
> It's that way in every language I've dealt with.
You mean it's like that on every *computer* you've dealt with. If you use the FPGA target, it only takes a single bit there. The standard desktop computer is byte addressable, meaning you cannot have a memory address for an individual bit. So the language compilers (LabVIEW, g++, etc) will compile to whatever the minimum size is. There are machines that are word and long addressable, and on those machines a Boolean would take 16 or 32 bits (respectively). Machines could in theory be built bit addressable, but in general, the gains you get from making Boolean storage more effiicient are lost due to the increase of your memory address size or the decrease in the amount of addressable memory.
As for the idea, it's a good idea. I'll add my kudos.
