Algorithms

[Cory_K]

I've got an idea I would like to throw out there, I'm interested if anyone else has thoughts or comments on this topic.

I think it would be helpful for there to be a board on the forums, maybe under special interest boards, for algorithms.

Sometimes it isn't the LabVIEW side of a project that I get stuck on,

sometimes I get caught up in the math or the conceptual aspect of what I'm trying to program.

Before you just jump into coding, it is always good practice to think about what exactly the end goal is, and the best algorithm to get that job done.

I don't think that such posts would be appropriate for the LabVIEW board because they arent specifically LabVIEW related (...yet  ) 

The NI forums are full of experts in their respective fields who I'm sure could answer questions of this type.

Does anyone else think this type of board would be helpful? 

[altenbach]

I love algorithms. 😄

There are two aspects:

(1) A plain algorthm is not LabVIEW specific and there are plenty of places to find good information. It might be a bit harder if you don't know what you are looking for. (I have this and need to calculate that. Is there an algorithm that does this?).

(2) Once we have found the algorithm, a second order problem is how to most efficiently implement it in LabVIEW, and that would already be appropriate for the current LabVIEW forum.

Even point (1) would be appropriate for the LabVIEW forum if you frame the question in terms of a LabVIEW implementation. We always need to weight the benefit of a new forum with the added scattering of information. If the algorithm forum has little traffic, maybe nobody would ever find it or bother to go there.

If, after exhaustive discussions, we found the absolute best implementation, somebody could write it up and post it as an article in the Developer Zone or some other suitable place. 

Maybe in the far future, somebody will come out with a book called "Numerical Recipes in G". 😄

[Cory_K]

---

altenbach wrote:

I love algorithms. 😄

There are two aspects:

(1) A plain algorthm is not LabVIEW specific and there are plenty of places to find good information. It might be a bit harder if you don't know what you are looking for. (I have this and need to calculate that. Is there an algorithm that does this?).

(2) Once we have found the algorithm, a second order problem is how to most efficiently implement it in LabVIEW, and that would already be appropriate for the current LabVIEW forum.

Even point (1) would be appropriate for the LabVIEW forum if you frame the question in terms of a LabVIEW implementation. We always need to weight the benefit of a new forum with the added scattering of information. If the algorithm forum has little traffic, maybe nobody would ever find it or bother to go there.

If, after exhaustive discussions, we found the absolute best implementation, somebody could write it up and post it as an article in the Developer Zone or some other suitable place. 

Maybe in the far future, somebody will come out with a book called "Numerical Recipes in G". 😄

---

That is what I had figured, but theres always the occasional "this has nothing to do with LabVIEW! Please do not post on this board"
Which is a perfectly legitimate response, but generally once the algorithm is established, it will be implemented with LabVIEW in the near future as you said. 

What I was describing in my original post would be something to assist with aspect (1) as you posted.

Aspect 2 would be perfectly reasonable to post in the LabVIEW boards because it is specifically related to LabVIEW. 

[Ben]

---

altenbach wrote:

I love algorithms. 😄

...

Maybe in the far future, somebody will come out with a book called "Numerical Recipes in G". 😄

---

I may be stuck in a timed loop but when I was a rookie I was told that the LV Advanced Analysis package had all of those included.

Ben

[JackDunaway]

This is a neat suggestion... I have tagged it with forum_improvement_ideas. One type of topic that would get a lot of traffic and good discussions: "Help me un-Rube my code!" (I almost posted a small algorithm this morning seeing if anyone could help me accomplish the same task more efficiently and with fewer primitives. A board dedicated to this purpose would have made me more inclined to follow through.)

[JackDunaway]

OK, unfair to pique your curiosity and not deliver, here's the really simple algorithm: converting back and forth between one-byte ASCII values and the two-nibble Hex characters in ASCII representation. I figured there should be a primitive for this function, but I'm not aware of one (refer to String Display Format Specifiers).

So, who can un-Rube my code?

[smercurio_fc]

---

JackDunaway wrote:

So, who can un-Rube my code?

---

Probably going out on a limb on this, but is this enough of an "un-Rube"?

Message Edited by smercurio_fc on 06-11-2010 03:56 PM

Message Edited by smercurio_fc on 06-11-2010 03:57 PM

[JackDunaway]

Your top solution: polymorphism is our friend! Thanks for the reminder!

Your bottom solution: I'm sure it would beat mine in a benchmark, but the functionality is a little obscured. I'm not quite happy with either your or my solution. BUT ON ANOTHER NOTE.... what's up with the constant folding I have circled from your picture:

[altenbach]

It is folded for the duration of the FOR loop, i.e. with respect to the for loop diagram.

Message Edited by altenbach on 06-11-2010 02:29 PM

[JackDunaway]

---

altenbach wrote:

It is folded for the duration of the FOR loop, i.e. with respect to the for loop diagram.

---

Good indication that I need to learn more about Constant Folding.