array index problem in formula node

[normanshi]

dear friend

I'm trying to use formula node to solve a problem because I make this program using c at the begining.

It runs perfectly in turbo c, but somehow it doesn't work in the formula node.

I try to debug my source code, and I find that the formula node seems can't read the true value in

the array.

Here is the code in the formula node.

--------------------------------------------------------------

int32 i,j,k;

for ( i = 0 ; i < sopa; i++ )
{
 j = 1;
 ep[i][0] = pa[i];
 ep[i][1] = np[ep[i][0]][0];
 while ( ep[i][j-1] != exit )
 {
  for ( k = 0 ; k < sonp ; k++ )
    if ( np[ep[i][j-1]][k] != -1 && (pc[ep[i][j-1]][ep[i][j]] + pc[ep[i][j]][exit] >= pc[ep[i][j-1]][np[ep[i][j-1]][k]] + pc[np[ep[i][j-1]][k]][exit] ) && (pc[ep[i][j-1]][np[ep[i][j-1]][k]] == org[ep[i][j-1]][np[ep[i][j-1]][k]] ))
      ep[i][j] = np[ep[i][j-1]][k];
  j++;
 }
}

-----------------------------------------------------------------

This is the part that I think the problem might be.

if ( np[ep[i][j-1]][k] != -1 && (pc[ep[i][j-1]][ep[i][j]] + pc[ep[i][j]][exit] >= pc[ep[i][j-1]][np[ep[i][j-1]][k]] + pc[np[ep[i][j-1]][k]][exit] ) && (pc[ep[i][j-1]][np[ep[i][j-1]][k]] == org[ep[i][j-1]][np[ep[i][j-1]][k]] ))
 ep[i][j] = np[ep[i][j-1]][k];

I state that "np[ep[i][j-1]][k] != -1" but I do get the value -1 in the array "ep".

Could someone tell me why I get -1 in the array?

I hope I can finally do it all by labview not using formula node,but array like "pc[ep[i][j-1]][np[ep[i][j-1]][k]] "

seems very hard to wire in labview. Could someone give me some good advices of doing this?

Thanks for your help

[altenbach]

---

@normanshi wrote:

...

 ep[i][0] = pa[i];                                          (A)
 ep[i][1] = np[ep[i][0]][0];                            (B)
...    if ( np[ep[i][j-1]][k] != -1 && ... )          (C)
      ep[i][j] = np[ep[i][j-1]][k];                       (D)
 -----------------------------------------------------------------

I state that "np[ep[i][j-1]][k] != -1" but I do get the value -1 in the array "ep".

Could someone tell me why I get -1 in the array?

I hope I can finally do it all by labview not using formula node,but array like "pc[ep[i][j-1]][np[ep[i][j-1]][k]] "

seems very hard to wire in labview. Could someone give me some good advices of doing this?

---

There are many possible scenarios to get a -1 in the ep output. For example if the -1 gets already written in step (A) or (B) at a certain index, and that index does not get overwritten in step (D). You are indexing all over the place! Is there some bounds checking on the array contents? What are typical inputs and array sizes?

It does not seem too difficult to translate your code into G. Attached is a quick attempt to do so (LabVIEW 8.0). Be aware that there could be bugs and mistakes, I spent only a short time on this and I could not test with real data and expected results. Still, it should give you some ideas on how it could be done. 😉

Message Edited by altenbach on 08-19-2006 12:58 PM

[normanshi]

---

altenbach 已寫:

---

@normanshi wrote:

...

 ep[i][0] = pa[i];                                          (A)
 ep[i][1] = np[ep[i][0]][0];                            (B)
...    if ( np[ep[i][j-1]][k] != -1 && ... )          (C)
      ep[i][j] = np[ep[i][j-1]][k];                       (D)
 -----------------------------------------------------------------

I state that "np[ep[i][j-1]][k] != -1" but I do get the value -1 in the array "ep".

Could someone tell me why I get -1 in the array?

I hope I can finally do it all by labview not using formula node,but array like "pc[ep[i][j-1]][np[ep[i][j-1]][k]] "

seems very hard to wire in labview. Could someone give me some good advices of doing this?

---

There are many possible scenarios to get a -1 in the ep output. For example if the -1 gets already written in step (A) or (B) at a certain index, and that index does not get overwritten in step (D). You are indexing all over the place! Is there some bounds checking on the array contents? What are typical inputs and array sizes?

I'm sure about that the -1 doesn't get already written in step (A) or (B) because ep[i][0] and ep[i][1] is fine. What really makes me confuse is that sometimes ep array has the value like this.

That means it does overwritten some value in step (D). The -1 should never be written into it because I have already state that np[ep[i][j-1]][k] != -1. Somehow I still get -1,and this is really strange! I'm indexing all over the place becuase I can't figure out a better way to achieve my requirement.

I think I should briefly tell you what I'm trying to do. In this program,I input some values which means the distance from one point to another. Then I use floyd's all pairs shortest-path algorithm to find all the shortest distance. Finally I want to find out the "shortest path". I mean like from point 4 to point 0,the shortest path might be like 4 -> 2 -> 1 -> 0, and what the formula node part do is trying to find out this "shortest path". Maybe you can give me some better advice of doing this, I have been thinking a better way to do it for about two months. I think I'm really not good at this.

I try to do it all by labview ,but again I get a strange problem. This time the ep[i][j-1] doesn't get the correct value. In the first time i=0 j-1=0 ep[i][j-1] = 1,but the second time i = 0 j-1 = 1 ep[i][j-1] = 0. This makes the "ep[i][j-1]!=exit" get the incorrect boolean value. The ep[i][j-1] should be 2,not 0. I try to use highlight to find if I make any mistake, but I can't one.This is the input and I put the labview program in attached file (temp4.vi).

Could you help me find out why this happened?

Thanks for your help altenbach!

由 normanshi 在 08-19-2006 10:06 PM 上編輯的訊息

[altenbach]

Sorry, I cannot debug your VI. Too many local variables, stacked sequences, and hidden code..

A few things are definitely wrong compared to my code example (I am talking about outer sequence frame=4, inner:sequence frame=2)

1. The ep array and the j must be wired across in the "other" case frame, else they reset whenever that case executes and loose all values.

Message Edited by altenbach on 08-19-2006 11:50 PM

[normanshi]

---

altenbach 已寫:

Sorry, I cannot debug your VI. Too many local variables, stacked sequences, and hidden code..

A few things are definitely wrong compared to my code example (I am talking about outer sequence frame=4, inner:sequence frame=2)

1. The ep array and the j must be wired across in the "other" case frame, else they reset whenever that case executes and loose all values.

Message Edited by altenbach on 08-19-2006 11:50 PM

---

You're almost right! Thanks for your advice. I have already found the problem and fixed it. I can't use shift register in this vi because it doesn't change the value in the array immediately. My program need to know any change of the value in the array or it might get the wrong result. After changing the shift register into local variable I almost fix most of the problem. I also found that some values of the index are -1,I  didn't notice that before. I make some little change about my program and it works just as fine as it does in turbo c. When I change the code in the formula node,it works,too. I really appreciate your help. Thanks a lot!

[altenbach]

---

@normanshi wrote:

I can't use shift register in this vi because it doesn't change the value in the array immediately. My program need to know any change of the value in the array or it might get the wrong result. After changing the shift register into local variable I almost fix most of the problem.

---

I am glad things are working :D.

Still, you should rethink your use of local variables. Your statement above does not make a lot of sense. Indicators have their own data copy, which only gets updated whenever they receive data. The shift register always contains the current data in one safe location, protected from race conditions by strict dataflow. Reading and writing local variables always causes extra data copies in memory and thus cause performance problems, especially if large arrays are involved. There is absolutely no need to constantly update (hidden!) front panel indicators, nobody will see them anyway. Then there is the case of race conditions. If you would read the locals elsewhere in paralell code via locals, the data is almost worthless because there is no way to tell at what stage the loop is and you might get stale or partially complete data that is virtually useless.
IF you need to update a FP indicator with values during loop execution, be prepared to take a performance hit. But in this case you would simply place the indicator inside the loop, wired to the data from the shift register.

For a performance comparison, have a look at my old demo here:

http://forums.ni.com/ni/board/message?board.id=170&message.id=153611#M153611

[normanshi]

I will try to find out why shift register doesn't work. I know this is strange because shift register usually works and has better performce. This part of my program is so complicated that I still can't figure out why it is not working in this place. What  is FP indicator? Field point?

Thanks for your advices and demo altenbach!

[altenbach]

---

@normanshi wrote:

What  is FP indicator?

---

Front Panel Indicator... 😉

[normanshi]

Ha... I see. By the way I finally know why the shift register doesn't work. It was just because I forget to wire the line the case structure and just like what you said it reset all the values in the array. Thanks for your help again. I really learn a lot this time.

[Kevin_Price]

CAUTION!  The following post is a tangent that doesn't address any previouisly-raised questions.  Skip if you don't like tangents.

I like LabVIEW, I really do.  But I think this is a good example of a case where a text-based formula node is much, much easier to understand and maintain than graphical "G" code.

Just imagine having the algorithm described in some text book with normal math notation of subscripts for the various array indices.  Now imagine trying to verify that the correct algorithm has been implemented.  For me, it's at least 10x harder to scan the LabVIEW "G" code, and it would probably be many times worse without altenbach's text-code-like comments.

-Kevin P.