View >> Gigantic Coercion Dots (now with a variety of colors)

[AristosQueue (NI)]

We have (collectively) complained about coercion dots many times on various LV forums -- they are nearly invisible and there are three different kinds, which require different levels of concern. The problem is that there are very few pixels within a terminal and there's no space for any pattern to differentiate the three kinds of coercion (and changing colors is a problem for reasons discussed here in the Idea Exchange).

Another LV developer had an idea that I liked: add an option to view giant coercion dots. We have avoided this because coercion dots bigger than the terminal would interfere with wiring. However, many developers have a policy of eliminating all coercion dots on their diagrams. For those who have such a policy, they could eliminate the coercion dots as they work, and thus might not see any problem from such large dots. Large dots would solve lots of other usability problems that coercion dots have today.

This option could be something in Tools>>Options, but I'd rather it be something in the View or Edit menus so it can be quickly toggled on or off with a shortcut key.

These graphics are "programmer art" -- I just made the three dots look different. Please sumit alternate images for the three dot types if you have better style suggestions. I did make the three dots differ in both pattern and color so that we avoid problems with colorblindness. The type-only was a solid dot, the widening coercion is a bulls eye, and the narrowing coercion is a single ring. Any redesign should definitely take colorblindess into account.

[AristosQueue (NI)]

> of course nobody in his right mind uses these patterns.

Nobody in their *left* mind uses these patterns. My right brain thinks they're kind of pretty, in a Jackson Pollock sort of fashion.

[Marc Blumentritt]

I like this idea very much and think it is a must be for the next version. I do not care, if the dots are on wire or on symbol. I think, "good" (grey) coercion dots do not need to be bigger, since they just indicating something, which will be removed in machine code without any effect on execution time/memory.

The "bad" (blue and red) dots can be made as big as possible, since I want to remove them in code - preferably by not needing them at all, since I'm planning my data types thoroughly or by using coercion bullets.

I also like the idea of a (unified) tool for finding coercion dots (and I do not mean the VI Analyzer), but this is another idea in itself.

Regards

Marc

[altenbach]

>> (This opens another can of worms, probably to be discussed elsewhere:

>> Why are there no coercion dots in this code! Shouldn't there be?)

> Aristos Queue replied:

> No, there shouldn't be. The node operates on the values without coercing them first.

> The lack of coercion dots indicates that the assembly code generated by this node is

> actually able to do its work without coercion

I don't think this is fully correct. For example forming a complex CDB from two U64 inputs would be "narrowing", because the mantissa of the DBL is potentially insufficient to contain the full information.

> Nobody in their *left* mind uses these patterns. My right brain thinks they're kind of pretty, in a Jackson Pollock sort of fashion.

They remind me much more of Piet Mondrian. 😄

[AristosQueue (NI)]

> I don't think this is fully correct. For example forming a complex CDB

> from two U64 inputs would be "narrowing", because the mantissa of the

> DBL is potentially insufficient to contain the full information.

A coercion dot indicates that the value of the input is modified before the node begins execution. The lack of a coercion dot indicates that the node is operating on the value without a preemptive coercion. Although this may mean that some form of coercion is being done under the hood, the node is aware of the original data type and original value of the input and so can do its work minimizing the amount of lost precision, whereas a coercion dot indicates that the node is operating without any knowledge of the original -- the value is already coerced by the time the node begins working. It is the difference between a node saying, "I know how to work with int64s" as opposed to "I need these to be doubles before I can even start working". It is possible that the end result might actually be the same, but the node is claiming it can do better -- for at least some values of the inputs -- than the general coercion mechanism.

You'd have to talk with the author of that particular node for further details. I have no idea who that would be.

[Ray.R]

Between Aristos & Altenbach, this will be a great idea  🙂

Kudos to both of you (well, Aristos will have to share)