Index array with index valid indicator

[AbandoningCausality]

I imagine the index array function already has to do a range check. The compile code probably looks a little more like this:

Since it's already doing the check, it might be nice to optionally return the result of that check so we can be sure our data is not defaulted. Maybe the icon could look like this:

[Intaris]

This would be a nice addition but needs any overhead which may be created needs to be carefully weighed up.

It's relatively easy to implement this in a custom VI, but as usual, I too would prefer for the behaviour to be suppoorted natively.

[CMal]

If this were implemented, I would definitely want it to be off by default on all existing and new Index Array nodes.  There might be some cases where I would turn it on, but I would hate to take the performance hit in the other 99% of the Index Array nodes in my code.

[AristosQueue (NI)]

CMal: If the terminal is unwired on any primitive, the code generator generally eliminates the code that leads to that primitive. It would do the same in this case if we added a second output terminal for every index accessed. I don't think performance is a concern with this idea.

[CMal]

AQ: Good to know.  In that case, I like this dea.

[JimChretz]

I'm not kudoing even though it looks cool, but I think it would be a crutch that encourage bad programming habits.

If you need this, you or a coworker probably made a mistake upstream in your code.

[Intaris]

Would error in and out be better than a boolean out?

[AristosQueue (NI)]

> If you need this, you or a coworker probably made a mistake upstream in your code.

Every function you write that has an index passed in as a parameter has to do the bounds comparison anyway... doesn't it make sense to just make it a part of the node?

[AbandoningCausality]

It's not a crutch. There's a performance penalty to sanitizing your inputs upstream. Limited resource targets like FPGA might benefit the most. Also, if it keeps a newcomer off the forums asking about an issue caused by default data, it saves us all time. For that reason, I like the optional error out idea as it could be more verbose. Of course an error in is always a can of worms on primitives

[AristosQueue (NI)]

> Would error in and out be better than a boolean out?

No. Absolutely not.

No error out because generating an error cluster is EXPENSIVE. It's got to get the call chain. Its allocation is substantially larger than normal. There are plenty of scenarios where you are accessing the array and you can handle it locally without it being escalated as an error to some caller.

No error in because in general, this does need to behave like a function, and encouraging its serialization in the name of error handling is very bad.

I like LV's concept of error handling for errors on major functions (file not found, string formatting, etc). But I don't like it for small fast functions where the error handling outweighs the weight of the function itself \ -- like the Add primitive when you wire certain data types. Those need to be just Boolean connections that the user can escalate as errors if desired.

This need for speed is one reason that NaN is a part of the IEEE floating-point spec instead of returning errors for invalid operations.

[JÞB]

For me, I'm thinking of a worst-case scenario with nD Bool arrays expanded to several elements where indicies may not necessarily be sequential.  Which dimention is out of range for each output?  and how do you visually tell that the xth element out is not accidentally misswired to the out of range output? Doulbling the maximum right-hand side node density scares me.  That density is tight enough already.