Jump to content

Reinatialize the arry


Recommended Posts

QUOTE(Michael_Aivaliotis @ Mar 7 2007, 02:04 AM)

In general, using the reinitialize to default node is considered bad form.

How much bad is using reinitialize to default node?

I just felt sometime it's hard to do things just because it may not be the best way to do. And how much differences would it make to use not the finest and most efficient way?

It's like my husband told me that garage door opener has life cycles (how many times can we open it)? It kind of puts some psycho on me that I somtimes open only half way of the garage door for saving the life cycle. :D

Irene

Link to comment

QUOTE(Irene_he @ Mar 7 2007, 11:09 AM)

How much bad is using reinitialize to default node?

I think using ReInit to Default is completely the correct solution for a user interface component. Using it for changing values of variables that are actually part of your program is really bad form (it means you're using variables that can be accessed outside the dataflow and all the problems therein that have been discussed to death elsewhere). As a UI component, it's very useful for a "reset to inital state", such as a Clear button for some output, or a Reset To Defaults button on an Options dialog.

My opinion.

Link to comment

QUOTE(Aristos Queue @ Mar 8 2007, 04:25 AM)

I think using ReInit to Default is completely the correct solution for a user interface component. Using it for changing values of variables that are actually part of your program is really bad form... My opinion.

I share your opinion :thumbup:

Link to comment

QUOTE(Aristos Queue @ Mar 7 2007, 01:25 PM)

I think using ReInit to Default is completely the correct solution for a user interface component. Using it for changing values of variables that are actually part of your program is really bad form (it means you're using variables that can be accessed outside the dataflow and all the problems therein that have been discussed to death elsewhere). As a UI component, it's very useful for a "reset to inital state", such as a Clear button for some output, or a Reset To Defaults button on an Options dialog.

My opinion.

I know losing data flow is a bad thing for programming style, that I understand. Always pull data out from a wire (a very thick wire), not from middle of nowhere :) I was thinking if the property node has some inefficiency by itself.

Irene

Link to comment

Some very simple benchmarking (for-loop with 50000 iterations, on my old T41 laptop):

1) Reset array with invoke note: 30000 ms

2) Reset array by assigning empty array constant: 44 ms

Unless I am missing something, it seems to be around 700 times slower to use the invoke note.

-Mikkel :)

Edit: It seems to be related to repainting. The invoke note method repaints the indicator, while the assignment does not. If I enable 'Synchronous Display' for the indicator and modify the array contents every iteration before resetting it, the array constant method takes more or less the same as the invoke note method.

Link to comment
QUOTE(Aristos Queue @ Mar 7 2007, 10:25 AM)
I think using ReInit to Default is completely the correct solution for a user interface component. ... As a UI component, it's very useful for a "reset to inital state", such as a Clear button for some output, or a Reset To Defaults button on an Options dialog.
Ok, re-init to default. Putting the performance issues aside (which are also important), can you tell me what the "default" is? That's a pretty blind approach considering that anyone can right-click on the front panel and define their own "default". While writing apps for years, I've learned to always be explicit when setting values to avoid ambiguity and hair pulling.
Link to comment

QUOTE(Michael_Aivaliotis @ Mar 8 2007, 07:58 AM)

Ok, re-init to default. Putting the performance issues aside (which are also important), can you tell me what the "default" is? That's a pretty blind approach considering that anyone can right-click on the front panel and define their own "default". While writing apps for years, I've learned to always be explicit when setting values to avoid ambiguity and hair pulling.

Sure, being explicit is a good idea, but there's nothing wrong with defaults either - as long as you know what they are. User's right-lciking on FP items under and exe doesn't allow them to set a defualt for the next time the app is run, so I'm not sure what the problem is. As Aristos pointed out, setting FP items ot default programmatically is great for UI components, but that's about it. Next you'll be telling me that the "use default" option on the output tunnel of a structure is bad form... :P

Link to comment

QUOTE(crelf @ Mar 7 2007, 06:24 PM)

Next you'll be telling me that the "use default" option on the output tunnel of a structure is bad form... :P

I'll beat Michael to the punch...

At JKI, we have a general policy to avoid default values on output tunnels of structures. They are just bugs waiting to happen, much like the default frames of case structures.

Link to comment

QUOTE(Jim Kring @ Mar 8 2007, 12:36 PM)

At JKI, we have a general policy to avoid default values on output tunnels of structures. They are just bugs waiting to happen, much like the default frames of case structures.

You bit more quickly than I expected :D

I, also, agree that, as a general policy, default tunnels aren't the best practise, but I certainly don't have a complete aversion to them. I don't have a huge problem with default frames in case structures either, as long as they are used properly - for example, in a string-based state machine (yes, there are occasions when they are a good idea - not many, but they do exist) I like to include a "Syntax Error" dialog to the user for testing. IMHO just about every function on the BD can be abused if the programmer doesn't know what they're doing, so there isn't much I think is off limits (things do exist that I won't do, but default values and default cases aren't two of them). I know that several people will disagree with me on this, and I didn't like the default tunnels when they were introduced, but I've grown to overcome my fear of new things to embrace them when it's appropriate. OOP is another great (more esoteric) example: a wonderful tool when used properly, a complete mess in the hands of those who don't know how, or sometimes more importantly, when to use it.

Link to comment

QUOTE(crelf @ Mar 7 2007, 07:42 PM)

You bit more quickly than I expected :D

I, also, agree that, as a general policy, default tunnels aren't the best practise, but I certainly don't have a complete aversion to them. I don't have a huge problem with default frames in case structures either, as long as they are used properly - for example, in a string-based state machine (yes, there are occasions when they are a good idea - not many, but they do exist) I like to include a "Syntax Error" dialog to the user for testing. IMHO just about every function on the BD can be abused if the programmer doesn't know what they're doing, so there isn't much I think is off limits (things do exist that I won't do, but default values and default cases aren't two of them). I know that several people will disagree with me on this, and I didn't like the default tunnels when they were introduced, but I've grown to overcome my fear of new things to embrace them when it's appropriate. OOP is another great (more esoteric) example: a wonderful tool when used properly, a complete mess in the hands of those who don't know how, or sometimes more importantly, when to use it.

A string-typed Case Structure must have a default frame, so the only sensible thing to do is to make it a run-time error, since the compiler can't possibly catch this. So you win that argument... by default ;)

Link to comment

I love that we can spin a whole discussion out of "set to default".

QUOTE

there's nothing wrong with defaults either - as long as you know what they are

Well, again, that's my point. Do I have to check every front panel Item to prove to myself that it has the right value?

QUOTE

User's right-lciking on FP items under and exe doesn't allow them to set a defualt for the next time the app is run, so I'm not sure what the problem is

I wasn't referring to end users. I was referring to other programmers. They are more dangerous. End users should always be forgiven when it comes to software. It's programmers that know better, but decide deliberately to behave badly.

QUOTE

Next you'll be telling me that the "use default" option on the output tunnel of a structure is bad form...

I'm 50/50 on that one. One thing I like about it is that no-one can override what the default is by right-clicking on it or anything. The default is defined by LabVIEW and stays that way... until NI decides to "fix it".

Link to comment

QUOTE(Michael_Aivaliotis @ Mar 8 2007, 03:30 PM)

Yeah - we're skating awfully close to being OT, but I'm lovin' it!

QUOTE(Michael_Aivaliotis @ Mar 8 2007, 03:30 PM)

Well, again, that's my point. Do I have to check every front panel Item to prove to myself that it has the right value?

I do agree - my frame of reference was different: I was thinking end user, not other programmer.

QUOTE(Michael_Aivaliotis @ Mar 8 2007, 03:30 PM)

Yes - that's true. Although I do remember an end user mashing the keyboard with his hands trying to make my software fail (I mean like repeatedly pressing 20 keys at once in a quasi-random pattern) - when I asked him what-the-hell he was doing, he said he was testing my software cause a user might do this. I explained to him that, after some system training we give to all users, I don't expect my end users to act like gorillas.

QUOTE(Michael_Aivaliotis @ Mar 8 2007, 03:30 PM)

I'm 50/50 on that one. One thing I like about it is that no-one can override what the default is by right-clicking on it or anything. The default is defined by LabVIEW and stays that way... until NI decides to "fix it".

I must admit that it took me a looong time to come around to using them - in principle I didn't like them when they came out, but I figured, after a while, they're just like any other function in LabVIEW - powerful when used properly, dagerous when not.

QUOTE(Jim Kring @ Mar 8 2007, 02:16 PM)

A string-typed Case Structure
must
have a default frame, so the only sensible thing to do is to make it a run-time error, since the compiler can't possibly catch this. So you win that argument... by default
;)

*sigh* very punny Jim :D All case structures (except for enums, where there must be one case for each enum value possible, and on case only) must have cases to cover the entire input range of the selector, so one needs to be carfeul with all of them. There may not be an explicit "default" case (eg: an integer selector could have "...1", "2...5", "6...") but it's really the same thing, and needs appropriate error trappping, if appropriate.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.