LabVIEW Idea Exchange

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

Index array with index valid indicator

Status: Declined

Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.

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

equavalent index check2.png

 

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:

index with check.png

15 Comments
Intaris
Proven Zealot

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
Active Participant

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)
NI Employee (retired)

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
Active Participant

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

JimChretz
Active Participant

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
Proven Zealot

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

AristosQueue (NI)
NI Employee (retired)

> 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
Member

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)
NI Employee (retired)

> 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
Knight of NI

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.


"Should be" isn't "Is" -Jay