True/False constants and other philosophical questions...

[Aristos Queue]

QUOTE (Black Pearl @ May 8 2009, 11:18 AM)

One way to avoid that issue would be to have a required error in/out terminal on the for loops (with shift register behaviour) and an optional terminal 'allowed to execute 0 times'. But that would make such a basic concept a bit too feature-rich for standard users.

It would be too advanced for me too, and I'd like to think I'm pretty far beyond "standard user" status.

I posted earlier that you should just wire the N terminal out of the loop to know how many times it executed. This was corrected by someone else who said that only applies as long as the conditional stop terminal is not wired. I am stunned that no one pointed out this deficiency before now. We had this big public brainstorming over on ni.com to come up with all the use cases and issues with adding a conditional stop to the For Loop and no one mentioned "there's no longer an easy way to find out how many times it executed." That's an amazing blind spot on the part of all of us.

But this works:

http://lavag.org/old_files/monthly_05_2009/post-5877-1241809248.png' target="_blank">

[crelf]

QUOTE (Aristos Queue @ May 8 2009, 03:01 PM)

We had this big public brainstorming over on ni.com...

There's your problem

[gb119]

QUOTE (TobyD @ May 8 2009, 02:17 PM)

You could submit this as an OpenG candidate.

Attached below is an XNode (LV 8.5.1) that implements this for all numeric types and also when the A input is an array. More or less completely untested other than running once on my development machine but I think it'll work. You need my Scripting Tools library installed and if you are not using the one from the LAVACR subversion repository on Google (i.e. you've downloaded from the LAVA Code Repository instead) you'll probably need a mass compile of the XNode code.

There's a little fiddle to workout which type to make the outputs - correctly detecting which input provides the higher order numeric type - I'm ranking U8,U16 and I8, U32 and I16,...,U64 and I32, I64, Single, Double, Extended, Single Complex, Double Complex etc which is not quite right but near enough. Look in GetTerms3.vi for that code (but don't look too hard it's 10 minute spagetti code).

Download File:post-3951-1241816400.zip

Oh yes, XNodes are unsupprted, not necessarily forward compatible, may cause LabVIEW to crash, destruction of the Universe and other bad things.

[jdunham]

QUOTE (Aristos Queue @ May 8 2009, 12:01 PM)

But this works:

But that doesn't work. If the STOP test returns false, the answer is off by one.

Incrementing 'i' is easier.

I knew you couldn't trust the "N" terminal any more (found out the hard way) but I figured that was by design.

QUOTE (Black Pearl @ May 8 2009, 09:18 AM)

To push that point a bit further, I think that for loops of iteration 0 are potential troublemakers. If you don't use a shift register, you might end up with default data instead of the real data (happend once to me with a reference).

I'm shocked that only happened to you once. It's a huge problem and we make sure during code reviews that the error cluster and any refnums ALWAYS go through a shift register unless there is a commented reason. Often I don't take refnums out of for loops because its so unsafe. I just fork the wire before the loop.

QUOTE (Gavin Burnell @ May 8 2009, 02:06 PM)

Attached below is an XNode (

LV

8.5.1) that implements this for all numeric types and also when the A input is an array.

Part of me wants to say hooray! and part of me wants to cry. The latter part is the part that tries to defend LabVIEW as a 'real' programming language. Thanks for submitting!

[Charles Chickering]

QUOTE (jdunham @ May 7 2009, 03:46 PM)

Thanks, I knew about that. But what I really want is this... (And I've already suggested it to NI, but you never hear back about that kind of thing).

http://lavag.org/old_files/monthly_05_2009/post-1764-1241729121.png' target="_blank">

This construction comes up all the time if you use picture controls, or you do GUI arrangements, any kind of 2D coordinate stuff, or histogram bins, or limit testing... I know it sounds like feature bloat, but having a native function for this would lead to much cleaner diagrams.

Agreed, and mixing this with in range and coerce would really clean up a lot of my stuff.

Charles

[ragglefrock]

I'd personally like to point out that most algorithms I write with For Loops execute very naturally and beautifully if the For Loop executes zero times. For instance, if I am concatenating a formatted string for every item in an incoming array, and the array is empty, then the string will come out empty if I initialize the formatted string with an empty string going into a shift register. This is exactly what I want.

I just hear everyone talking about this as a limitation, when it in fact very naturally adapts to well-designed algorithms. Yes, you have to use shift registers to maintain values passed through, but once you learn this, it's not hard to do.

[Rolf Kalbermatter]

QUOTE (asbo @ May 8 2009, 09:28 AM)

Which is why I often wish LabVIEW had some convention of NULL implemented ...

Well C hasn't either. NULL is simply a preprocessor define that is numerically not distinguishable to 0. Modern C compilers allow some type definition with pointer constants that allows at least a compiler warning if you try to assign NULL to an integer or 0 to a pointer but that is really all.

Rolf Kalbermatter

[Darren]

QUOTE (Aristos Queue @ May 8 2009, 02:01 PM)

That's an amazing blind spot on the part of all of us.

I don't consider it a blind spot. My http://forums.ni.com/ni/board/message?board.id=170&thread.id=380412' target="_blank">favorite feature of LabVIEW 8.5 was the For Loop with Break. I've probably used it hundreds, if not thousands, of times in code I've written in the past 2 years. And the few times I've needed the index of the For Loop when it stopped, I just used the iteration count within the loop. If I ever needed to know how many times the loop ran, I would just drop an increment in the loop and wire it to the iteration count. I never would have considered it a shortcoming of the For Loop that I had to do this.

-D

[Black Pearl]

QUOTE (Darren @ May 11 2009, 09:41 PM)

I don't consider it a blind spot. My http://forums.ni.com/ni/board/message?board.id=170&thread.id=380412' target="_blank">favorite feature of LabVIEW 8.5 was the For Loop with Break. I've probably used it hundreds, if not thousands, of times in code I've written in the past 2 years. And the few times I've needed the index of the For Loop when it stopped, I just used the iteration count within the loop. If I ever needed to know how many times the loop ran, I would just drop an increment in the loop and wire it to the iteration count. I never would have considered it a shortcoming of the For Loop that I had to do this.

-D

Ah, yes, that works perfectly. 0 iterations, defaults to 0. 1 iteration is 0+1=1.

Felix

[crelf]

QUOTE (Black Pearl @ May 11 2009, 03:57 PM)

0 iterations, defaults to 0. 1 iteration is 0+1=1.

Sounds perfectly logical to me...

[Mark Yedinak]

I would never have considered using the N parameter to give me the number of iterations executed. I would always use the I value.

As for the break I am glad they have added it. It made searching arrays easier than using while loops. When using while loops you would have to check for both the stop condition and the size of the loop. With the break in the for loop I no longer have to worry about the array size. I do see how this feature could be abused though.

[ned]

QUOTE (jdunham @ May 7 2009, 02:04 PM)

I wish that when replacing Multiply (for example) with Compound Arithmetic, then the multiply option would automatically be chosen.

Yes - and on a related note, I wish that when going the other direction, replacing a two-input compound arithmetic block with a simple boolean operation, the replace menu would come up with the Boolean palette instead of the Numeric palette when the function has boolean inputs.

[jdunham]

QUOTE (Aristos Queue @ May 7 2009, 12:16 PM)

Because most people want double type for the numeric. But it is really nice on the BD constant to drop it and then, if you need floating point, to type in a value using a decimal point and the constant will automatically change to double type. If it dropped as double by default, if you typed 3, we wouldn't be able to assume that meant you wanted an integer.

We'd probably do the same thing on the FP except that most people never type into the thing that drops onto the FP... they just leave the value as zero (and you wouldn't want it coercing to a new type everytime you typed a value into it while you were debugging!).

This has been bugging me lately and I finally put my finger on it. The autoconversion is neat, but really, 100% of the time, I know exactly whether I want a float or an integer, and it would be so much easier to have both on the FP and BD palettes rather than trying to trick LV into giving me the right choice. I'm not saying that you have to put all the possible numeric types on the palette, but putting all the most commonly used ones on (both of them!) would have been awesome. Trying to hide that stuff and be clever about automatic conversions is not that valuable to me.

I think LV suffers from a bit too much of this in a 'don't scare the newbie' philosophy. Maybe it needs to be that way, but it would be great if there were more ways to get past that and end up with advanced palettes with more useful stuff for the advanced users.

While we're waxing philosophical, why do the time formats always default to AM/PM? Who finds that useful?

[LAVA 1.0 Content]

QUOTE (jdunham @ May 14 2009, 01:20 AM)

While we're waxing philosophical, why do the time formats always default to AM/PM? Who finds that useful?

They don't, it is just that your computer is set to that idiocy representation.

Ton

[Gary Rubin]

QUOTE (jdunham @ May 13 2009, 07:20 PM)

I think LV suffers from a bit too much of this in a 'don't scare the newbie' philosophy. Maybe it needs to be that way, but it would be great if there were more ways to get past that and end up with advanced palettes with more useful stuff for the advanced users.

I would agree with that assessment. I recently spent 2 days banging my head against a DAQmx project. My biggest frustration was the lack of clear documentation for low-level control. If you want to do something "normal", DAQmx and LV make it very easy to be up and running quickly. If you want to do something a little less "normal", you're pretty much on your own...

[crelf]

QUOTE (jdunham @ May 13 2009, 07:20 PM)

The autoconversion is neat, but really, 100% of the time, I know exactly whether I want a float or an integer, and it would be so much easier to have both on the FP and BD palettes rather than trying to trick LV into giving me the right choice. I'm not saying that you have to put all the possible numeric types on the palette, but putting all the most commonly used ones on (both of them!) would have been awesome. Trying to hide that stuff and be clever about automatic conversions is not that valuable to me.

I don't think that it's hidden - you just need to right click on it and select representation. You can rest assured that if a few more constants were added to the palette then they wouldn't be the ones you want anyway, and you'd still need to select the representation. I thought it was a waste of time when NI added the TRUE Boolean to the palette because people were too lazy to click the FALSE one to change it's state. Meh - maybe that one is an intuativeness issue...

QUOTE (Gary Rubin @ May 14 2009, 08:11 AM)

I recently spent 2 days banging my head against a DAQmx project. My biggest frustration was the lack of clear documentation for low-level control. If you want to do something "normal", DAQmx and

LV

make it

very

easy to be up and running quickly. If you want to do something a little less "normal", you're pretty much on your own...

IMHO I don't agree, and that's because "the documentation" includes everything on ni.com and LAVA or the LabVIEW wiki these days. Sure, you mightn't find what you need in the documentation that ships with LabVIEW, but you'd be hard-pressed to come up with an implementation that someone on ni.com (NI staff or otherwise) or LAVA that has either already done what you are trying to do, or at least can point you in the right direction. Whether you like it or not, support is shifting from vendor-supplied to community-supplied (and that goes for so much more than just software, or even IT stuff).

[jdunham]

QUOTE (crelf @ May 20 2009, 03:10 PM)

I don't think that it's hidden - you just need to right click on it and select representation. You can rest assured that if a few more constants were added to the palette then they wouldn't be the ones you want anyway, and you'd still need to select the representation.

I'm not resting assured. My code overwhelmingly uses I32s and DBLs. Often I use Create Constant, but when the type has not yet been determined, then I go from the palette. It would be much better for me to have DBL and I32 available separately on the palette for both FP controls and BD constants. I suspect nothing will change, but you can't convince me the status quo is 'better'.

[Darren]

QUOTE (jdunham @ May 21 2009, 12:00 AM)

I'm not resting assured. My code overwhelmingly uses I32s and DBLs. Often I use Create Constant, but when the type has not yet been determined, then I go from the palette. It would be much better for me to have DBL and I32 available separately on the palette for both FP controls and BD constants. I suspect nothing will change, but you can't convince me the status quo is 'better'.

I have a Quick Drop shortcut of 'nc' for Numeric Constant...I use it all the time to drop an I32 constant. I could see it being useful for a DBL constant to be on the palettes, simply so I could have a 'dc' shortcut to drop the DBL constants when I need them. I'll look into what it might take to get a DBL constant added to the palettes sometime in the future (the work would be trivial, it's just a matter of convincing the right people). For now, though, you could add your own DBL constant merge VI to the user.lib palettes, and use Quick Drop to have quick access to it.

-D

[Cat]

QUOTE (crelf @ May 20 2009, 06:10 PM)

You can rest assured that if a few more constants were added to the palette then they wouldn't be the ones you want anyway, and you'd still need to select the representation.

I have to agree. I use SGLs a lot more than DBLs (SGL save space with the large data sets I always seem to be working with -- I don't bother to use DBL unless there's a precision issue) and I32s a LOT more than either. So I'd be much happier if the FP numeric was I32.

You can't please all the people all the time...

[Black Pearl]

Why not place it on the palette yourself if you really like it? You can customize the standard palettes, if you rename/delete the ReadOnly.txt (don't remeber the exact name).

Felix

[Cat]

QUOTE (Black Pearl @ May 21 2009, 07:58 AM)

Why not place it on the palette yourself if you really like it?

I should look into that. The problem is (I assume) I'd have to redo it every time I move or upgrade LV. But, since I already have to mess around with the menu configuration every time I upgrade or install on a new computer (no 3-D controls for me! They were cute looking for about a week) I could deal with it all at the same time.

[Black Pearl]

QUOTE (Cat @ May 21 2009, 02:16 PM)

I should look into that. The problem is (I assume) I'd have to redo it every time I move or upgrade LV. But, since I already have to mess around with the menu configuration every time I upgrade or install on a new computer (no 3-D controls for me! They were cute looking for about a week) I could deal with it all at the same time.

I haven't looked into that, but it might be as easy as replace the mnu files each time. The VIPM should be able to do this. But you could also code that process with LV on your own. This is actually pretty advisable, because it documents all the steps to do.

Felix

[hooovahh]

Yeah you can problematically change the mnu files natively in 8.6, I think it's in the app control palette. But every version of LabVIEW (that I've used anyway) allows you to customize the palette by going to Tools >> Advanced >> Edit Palette set. Then the new palette you make will be saved in the LabVIEW Apps folder.

[crelf]

QUOTE (Cat @ May 21 2009, 08:16 AM)

I should look into that. The problem is (I assume) I'd have to redo it every time I move or upgrade LV. But, since I already have to mess around with the menu configuration every time I upgrade or install on a new computer (no 3-D controls for me! They were cute looking for about a week) I could deal with it all at the same time.

QUOTE (Black Pearl @ May 21 2009, 08:25 AM)

I haven't looked into that, but it might be as easy as replace the mnu files each time. The VIPM should be able to do this.

That's a really good idea! You could create a really simple package that creates a palette of all your common constants :thumbup:

[Cat]

QUOTE (hooovahh @ May 21 2009, 10:32 AM)

But every version of LabVIEW (that I've used anyway) allows you to customize the palette by going to Tools >> Advanced >> Edit Palette set. Then the new palette you make will be saved in the LabVIEW Apps folder.

Doh! I forgot I knew how to do that. Thanks!