LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Linear Fit Weight Input Modifying Control Input - Impossible? Bug?

I was having some strange data array issues with a program I was debugging and ended up distilling the issue to this.  When "Linear Fit" is called twice it modifies the weight input array passed to it.  Sounds crazy; but its true.  I've been able reproduce this with a simple vi that I've attached.

 

The terrible thing is that if the weight array input is a control; its values will be modifed after calling Linear Fit.  And if you've branched that wire and used its values for some other part of your program; the values on that wire will also change.

 

I'm using LV 8.5.1

 

I'd appreciate it if someone could verify this is happening on their machine.  I'm too delirious from beating my head against the wall after tracking this down.

 

Milan

 

Download All
0 Kudos
Message 1 of 12
(3,563 Views)

Milan,

 

I can confirm that I see the same thing you reported.  The help for Linear Fit does say "If Weight is unwired, this VI sets all elements of Weight to 1."

 

However, I would not interpret that this should change the values wired into the VI.

 

Internally the VI calls a DLL so who knows what is going on there. 

 

Lynn 

0 Kudos
Message 2 of 12
(3,557 Views)

Lynn,

 

Thank you for taking the time to verify this.

 

I feel this is a serious bug; as it breaks LabVIEW's flow paradigm.  In my circumstance; the array passed to the linear fit weight input was also being used in other calculations that went awry.  And only after many hours of tedious debugging and checking the "impossible" was I able to track it down to this.  I also dug into the linear fit enough to be stopped by a dll call.  I hope someone from NI is willing to chime in with a solution; otherwise I'll have to write my own linear fit routine for the time being.

 

0 Kudos
Message 3 of 12
(3,545 Views)

insane$object wrote:

I hope someone from NI is willing to chime in with a solution; otherwise I'll have to write my own linear fit routine for the time being.

 


 According to my simple tests, the problem occurs only if ALL weights are zero. As soon as at least one weight is nonzero, things work correcty.

 

Since 100% zero weights won't give you any useful results anyway, maybe you could place the fit inside a case and skip it if all weights are zero.

Message Edited by altenbach on 12-15-2008 12:15 PM
0 Kudos
Message 4 of 12
(3,538 Views)
I added a note to the monthly bug thread.
0 Kudos
Message 5 of 12
(3,533 Views)

Altenbach,

 

Thanks for your suggested workaround.  I suspected that the issue presents itself if all of the weights are zero; as this is how the issue became apparent to me.  I thought about the case structure execption; but now I've lost faith in using this function; since I was able to verify that an input to this function had the capability of modifiying its input; almost like a hidden local variable.  I'm able to reproduce this with all zero weight inputs; but since I can't see the source code; I can't chance it.   It scares me that somewhere in this function exists a case statement that modifies an input structure.   How will it behave with NaN inputs? 0's and NaN's, infs? etc.  These are all cases that are possible; and their permutations can be tested with a regimented unit test of this functio which I'm not willing to do.

 

I've written a quick & dirty basic least squares weighted fit vi (attached for those with similar woes).  I'm sure its slower then NI's dll version; but it should not modify any input parameters.

0 Kudos
Message 6 of 12
(3,509 Views)

You can also patch the problem by inserting an "always copy" primitive right before the linear fit. See attached.

 

 

 

Message Edited by altenbach on 12-15-2008 01:52 PM
Download All
0 Kudos
Message 7 of 12
(3,505 Views)

Interestingly, even the first iteration succeeds, even though all weights are zero.

 

Thus the help is incomplete and should be modified as follows:

 

"Weight is the array of weights for the observations (X, Y). Weight must be the same size as Y. If Weight is unwired or all weights are zero, this VI sets all elements of Weight to 1."

0 Kudos
Message 8 of 12
(3,501 Views)

altenbach wrote:

Thus the help is incomplete and should be modified as follows:

 

"Weight is the array of weights for the observations (X, Y). Weight must be the same size as Y. If Weight is unwired or all weights are zero, this VI sets all elements of Weight to 1."

 


I'm sorry, but I must respectfully disagree. I don't believe in LabVIEW you'll find an input to a function that modifies the input and feeds back that modification throughout the code as it sees fit.  I agree that if the input is unwired; then internally it can set these values to whatever it likes.  That would be like the divide function modifing the divisor if it is equal to zero; and saying; nope; better make that a one instead.

 

BTW: I like your "always copy" solution.  Nice workaround.  I'll use this if my alernate routine is too slow.

 

0 Kudos
Message 9 of 12
(3,488 Views)

insane$object wrote:

I'm sorry, but I must respectfully disagree. I


Sorry, I wasn't clear. I fully agree that we have a bug here. I am talking about something else. 🙂

 

My suggestion to improve the help text was just to show the behavior of what happens at the first iteration. Apparently the fit succeeds even though all weights are zero. Same as if the weights arreay is empty (as already described in the help).

0 Kudos
Message 10 of 12
(3,484 Views)