MathScript to LabVIEW left and right matrix division help please

[AaronKZ]

I have a requirement to change inherited MathScript modules to LabVIEW.  Matrix division is not a new issue, but I have had trouble finding the right solution.  Unfortunately, the 'inverted multiply' solution fails a condition check inside of much more complicated functions of my application. 

Simplified example: Attached: includes condition checks similar to the failures I'm seeing for all the different LabVIEW replacements I've tried

Simplified ask:  I need a LabVIEW equivalent for mrdivide

Simplified summary:

a/b   NOT EXACTLY EQUAL TO   a*inv(b)

a/b   NOT EXACTLY EQUAL TO   LabVIEW solution for (b'\a')'

Thanks!

Aaron

[BertMcMahan]

Some info for you:

1- Divide does NOT use matrix math, so it won't work directly: https://www.ni.com/docs/en-US/bundle/labview/page/using-matrices.html

2- See potential help from this thread: https://forums.ni.com/t5/LabVIEW/Matrix-Left-Divide-in-LabView/td-p/216475

(I don't do much matrix math so this might just be a way to get started and understand some more info about LV matrix division. I also don't have MathScript installed so I can't run your example directly. I will note however, that LV_e(0,0) < -3 returned False on my system when I deleted the Mathscript stuff.)

[AaronKZ]

Unfortunately, I've seen all these links before, and still cannot get a LabVIEW equivalent out to the machine epsilon decimal place resolution for MathScript's c=a/b; or MathScript's c=(b'\a')';

Thanks,

Aaron

[BertMcMahan]

Bummer. Well at any rate, I ran your VI unmodified on LV 2020, 64-bit and got different values than your original post.

Maybe something to do with 32-bit vs 64-bit?

Do you have an active service contract with NI? If so I'd suggest asking them. This does seem strange indeed.

[altenbach]

---

@AaronKZ wrote:

Unfortunately, I've seen all these links before, and still cannot get a LabVIEW equivalent out to the machine epsilon decimal place resolution for MathScript's c=a/b; or MathScript's c=(b'\a')';

---

Not really sure what you are expecting, but these differences are well within the limitations of DBL floating point math. Can you explain your definition of "decimal place resolution"? Machine epsilon has nothing to do with anything to the right of the decimal point, but with the total number of reliable decimal digits as derived from the size of the mantissa (52 bits). You are well within the ~15 decimal digits promised for DBL. Still since these operations are complicated, you expect to get slightly worse due to accumulation of errors. The tiny differences you see can easily be explained by subtle changes in execution order.

If you get a condition error for the the full problem, maybe your matrices are quite ill conditioned, meaning that all bets are off. Can you attach a simple VI that contains the data that is giving you problems?

(And please use reasonable names for VIs. "Untitled 2.vi" is NOT a reasonable name. So many users do the same silly thing and my browser had to automatically rename yours to "Untitled 2 (8).vi", meaning it is difficult to find in the future because it no longer has the same name as shown in the post! If this happens with subVIs, chances are that the toplevel loads with something that has no relation to the problem!)

[AaronKZ]

Current system working correctly 100% of the time.

requirement = replace mathscript with LabVIEW

if a = matrix, and b = matrix:

Current system working correctly:

Part of the MathScript calculations use a/b, with a resulting cell value = 1.00000000000000311

condition check:

1.00000000000000311 > 1 = TRUE

I need to replace MathScript with a LabVIEW solution (required):

Previous attempt showed my LabVIEW solution = 0.99999999999999873

condition check:

0.99999999999999873 > 1 = FALSE

Different iterations and different state space model scenarios yield very similar, but slightly different values for this small part of the calculations.  So, sometimes the LabVIEW equivalent works, and sometimes it doesn’t.

The Gmath left divide provides the closest equivalent solution so far (uses SVD), so I’m hoping it will be good enough, otherwise we will attempt some strategic rounding.  We are also working on finding alternative formulation to yield good modeling.

NI R&D is looking into it, but so far it appears that there is no exact LabVIEW match (under the hood calculation) for the MathScript a/b.