Expression node should allow resizing for more inputs to unclutter code diagrams - for more readable and concise diagrams

[jj2]

Expression node should allow addtional inputs by allowing resizing so it can take addtional inputs with predefined input variable names 

Current : single input named x

Proposed: default: single input named x

option to resize to show u,v,w,x,y,z as inputs

 

[jj2]

[X.]

Considering that the Formula Node is doing the job just fine, I would not hold my breath if I were you.

There are some minimum node size constraints to keep the content of the Formula Node legible, but past 3 inputs, it can be probably more compact than your suggested modification of the Expression Node.

But surely you must have had a killer example in mind?

[jj2]

The formula node is fine but too many clicks to do simple math and avoid cluttering the diagram wtih simple math operator vi's. . The idea is to quickly add math operations on more than one input by using predefined variable names etc. For more involved functionality, Formala node as is is approprate.There is no killer example just keep the diagram readable and to add  simple math functionality in the code with as few clicks as possible.

[fabric]

Here's a possibility: What if the expression node could take a cluster input and then simply index the cluster elements as x, x2, x3, etc...

Cluster input and scalar output would be pretty useful for quick math!

[AristosQueue (NI)]

Speaking for R&D:

the idea is totally viable but, X is right, given the existence of other nodes, this seems unlikely to get attention without significant community demand.

Personal opinion follows, not representing R&D...

It still mystifies me that people use the Expression node. I get the Formula box -- that's for long pieces of math that you've copied from somewhere that you don't want to translate into G. Same goes for the MathScript node. But the Expression node? You're stuck with a text representation of math that requires you to get parentheses right or remember the order of operations rules. It's impossible to debug inside that equation if you get it wrong. Overall, for any use case of the Expression node, I'd much rather write out the G code where dataflow determines the order of operations and where I can probe the interim values. Heck, I might even get some parallelism out of it that doesn't happen with the compiled text.

I do not fault those who like the Expression node -- they have a different worldview than I. But under my worldview, I'm just surprised that the node-by-node math code doesn't win out all the time.

[X.]

@AQ: for things like x/2 or x^(1/3), the Expression Node has the advantage of being compact and legible. I use it in those circumstances. As far as debugging the Formula Node, I must admit I have no clue as how you could do that...

[AristosQueue (NI)]

> legible

This is where I ran into difficulties with my math courses. I'm good at math -- not top flight, but I stayed in the saddle through upper division courses and still dabble from time to time. But I've never found anything about most mathematics notation remotely legible, especially when it is forced into a single unformatted string necessary for text programming. Even in the simple case that you highlight there, I can read and understand the graphical notation much easier.

I'm slightly dyslexic. That may bias my evaluation a bit. 🙂

[Darin.K]

My mind wants to read the second expression as (1/3)^x2 instead of x2^(1/3).  In the middle of a chain of math it is not legible at all.   I just smack my head a little everytime I have to use that function, why it is not y^x is beyond me....

[AristosQueue (NI)]

I agree with Darin that flipping the terminals could improve it as long as there were a bit of iconography change as well. I believe it is the current order because you write "x^y" when you write it as a string and on all operations, the left text input is the top graphical input and the right text input is the bottom graphical input. That makes it consistent with all the nodes. But if you did something like this, I think it might be better:

Doesn't match style of most other nodes, but, for me, it would clarify usage.

[X.]

@AQ: I can definitely see how your choice would allow debugging the result of 1/3 separately from the whole x^(1/3) operation.

I am now convinced...not.

Edit: for the record, x ˆ(1/3) in an Expression Node would result in a broken VI, as the correct syntax is x**(1/3).