array index problem in formula node

[normanshi]

I also had the same feeling of what you said. Sometimes using formula node is just simply easy to understand and achieve. I could do it in c just in a few minutes ,but when doing in labview it really takes me some time. Actually, I spent about a one hour to tranfer the code into G code, and I spent even more time to find out the problem. However,since we are using labview, I still willing to try to do it all by labview. This is also an interesting challenge! By doing this, I think I understand labview more. At least,I really learned a lot today. I have to say that you're right about the imaging part! I really hope that labview can be easier to index complicated arraies in the future. I almost finished my project today. Thank you all~!!

[altenbach]

Kevin,

Interesting comment. Since the original problem appears solved I see no harm going a bit offtopic and discuss your point.

The same thought briefly occurred to me yesterday when I looked at the codes. 😉

I am not a C porgrammer and I actually had a hard time making sense of the text code. I would have preferred to see a formatted mathematical formula instead.  My VI is a literal translation of the C code. It is possible that the diagram could be dramatically simplified and streamlined.

Apparently, this thing operates on a 5x5 array and I have the nagging suspicion that maybe there a single VI buried deep in the linear algebra palette that does the entire thing in one swoop. 😉 I would love to know more about the application and what it's purpose is.

[Kevin_Price]

---

I am not a C programmer and I actually had a hard time making sense of the text code. I would have preferred to see a formatted mathematical formula instead.  My VI is a literal translation of the C code. It is possible that the diagram could be dramatically simplified and streamlined.

---

To be fair, I haven't even tried to make sense of the text code in and of itself.  I'd agree that the algorithmic intent of the text code isn't particularly easy to decipher.  My comment is more nearly like saying that text code sometimes bears a much more striking resemblence to the kind of standard math notation that's often used to express algorithms. 

I wasn't viewing the problem as, "here's a bunch of code, tell me what it does."  I viewed it as one where the algorithm and intended function is already known, but there's a problem somewhere in the implementation.  When errors come up, you need to compare the implementation (either text code or "G" code) with the theoretical algorithm (probably expressed in some significant part with mathematical notation) and find where the translation error(s) occurred.  That's the scenario where I'd much rather work with the text code.

Other places I like to use formula nodes are:

1. When several numerical values get combined in several different ways.  The pure "G" approach leads to many crossed wires which I find to be an obstacle to clarity.  A formula node lets me bring in 5 uncrossed wires as input parameters and send out 7 uncrossed wires as calculated outputs. 

2. Case structures nested several layers deep.  3 layers deep is iffy, but at 4+ layers, I almost always prefer a formula node for the conditional logic, using indentation conventions for the various layers.  (Admittedly, 4+ layers of dependent conditional logic is often a symptom of a poor design.)

-Kevin P.