topic Re: Possible bug (LV2011) with Silver type Real Matrix in LabVIEW

Possible bug (LV2011) with Silver type Real Matrix

BertMcMahan — Wed, 11 Apr 2012 23:30:01 GMT

It appears that the control/indicator for a Real Matrix is different in the Silver pallete than on the Modern or Classic palletes. I don't know enough about Matrix data type to be able to figure out this issue, but in the attached VI you should be able to see the problem- when wiring a matrix into the Silver version Real Matrix indicator, you get a coercion dot. If you right click and do Create Constant, you will get a different type of wire. It looks similar to the 2-D array wire type, but it isn't- it appears to be something different altogether.

This is an issue when trying to multiply matrices, as the Multiply command isn't recognizing the Silver matrix as a Matrix data type- it doesn't multiply the matrices poperly. Note in the example VI I posted that the Multiply command does NOT properly multiply Silver matrices.

Re: Possible bug (LV2011) with Silver type Real Matrix

RavensFan — Thu, 12 Apr 2012 02:24:45 GMT

I see what you mean about the coercion dot. It appears the silver matrix is a 2-D array of numeric (double) while the others are 2-D arrays of real matrix element (double).

If you use an "Array to Matrix" on the array wires that are coming from the silver controls, it seems to do the matrix math properly.

Re: Possible bug (LV2011) with Silver type Real Matrix

BertMcMahan — Thu, 12 Apr 2012 16:35:34 GMT

That should work. I simply changed over to using all Modern matrices, as none of the matrix VI's I'm using have any UI components, but it did take me a while to track down why none of them worked 🙂 I'd still like to see this fixed, as it's not obvious that the multiplication doesn't work the way it's expected to. As you said, the Silver matrices aren't actually matrices (as Labview defines them) but also aren't true arrays, so noticing the correct data type is a bit tricky!

Re: Possible bug (LV2011) with Silver type Real Matrix

X. — Fri, 25 Jan 2013 18:38:41 GMT

Still a bug in LV 2012f3.

Is anybody listening at NI?

Re: Possible bug (LV2011) with Silver type Real Matrix

X. — Wed, 28 May 2025 12:58:50 GMT

However, note that, according to the Help:

Note Coercion dots appear on VIs and functions when the VI or function converts data to or from a matrix or 2D array. This kind of data conversion does not affect performance because LabVIEW stores matrices the same way it stores 2D arrays.

Re: Possible bug (LV2011) with Silver type Real Matrix

BertMcMahan — Fri, 25 Jan 2013 19:26:50 GMT

The issue here isn't related to storage and performance. The performance issues (I believe) come from converting data from one type to another that is stored differently on the system. If I remember correctly, a coercion dot means that a copy of the data is made, so for instance an integer getting converted to a double means that there are now two copies of that variable. When running data-intensive programs, that doubling of each data point can result in a lot of memory consumption (this is my understanding, at least).

The problem here is that math on arrays is totally different from math on matrices. When multiplying an array, it is done element-by-element, but with a matrix, it should be done using proper matrix multiplication. If the data type is incorrect, you won't get memory problems, but you will get bogus math results from the multiplication operation.

Re: Possible bug (LV2011) with Silver type Real Matrix

Doug-W — Mon, 28 Jan 2013 22:18:40 GMT

The issue here is the math primitives are not being correctly overloaded for Silver Matrix controls. As someone else mentioned earlier, the math primitives treat the Silver Matrix datatype as a 2D array, and will compute values element wise, instead of as matrices. NI is aware of the issue and it is being worked on. As a temporary workaround, please use the Modern Matrix controls. You may track the CAR# 377021.

Re: Possible bug (LV2011) with Silver type Real Matrix

Jeff-P — Wed, 28 May 2025 12:59:31 GMT

CAR 377021 discussed in this thread has been fixed in LabVIEW 2013. For a more complete list of bugs fixed in LabVIEW 2013, check the LabVIEW 2013 Bug Fixes. You can download an evaluation copy of LabVIEW 2013 at www.ni.com/trylabview/ or if you have an earlier version of LabVIEW installed and an active SSP subscription, you will be able to download the latest version of LabVIEW through NI Update Service.

Jeff Peacock

Product Support Engineer | LabVIEW R&D | National Instruments