how to create a numerical error propagation program

[svair23]

trying to create a numerical error propagation program

[Jeremy Braden]

For those who do not know, Numerical error progafation program
I have not seen anything like this in LabVIEW. If you figure it out, consider posting the code.

[Zvezdana S.]

Hi,
Can you explain a bit more what a numerical error propagation program is?
The only other mention of propagation program on this forum I was able to find is:
COM Interface Error Propagation from C++ to LV
Zvezdana S.

[isotherm]

I have been using error propagation for many years in MATLAB.  This is done so the error propagations are done almost simultaneously with the main calculation.   There is a bit of background for this that I can't discuss here.

I have developed a way to do this for experimental measurements and calculations in LabVIEW.  I think my approach is new and uses a new data type.  I have proposed to LabVIEW that they consider supporting my efforts and building this capability into LabVIEW and assign a new data with a new wire color.  Instead, they have not pursued this and any code I have will not be made widely available.  I am sure many people using LabVIEW for experimental measurements would WANT this as a standard tool.  How can a software package, that claims to be the superior experimental tool, not have this capability?

Maybe if a large enough group thinks it is important, it may be eventually built into LabVIEW as part of a true product upgrade.  I am interested in doing this.

[Stephen_S.]

Hi isotherm,

As you said, we have your product suggestion on file, and the R&D department is looking into implementing this idea or not. I do not know at this point if or when your idea will be implemented, but if others are interested in the same thing, it cannot hurt for additional users to suggest it at the product suggestion center.

You are free to post code for this if you think others will find it useful.

Regards,

Stephen S.

[isotherm]

The response 'we have your suggestion on file' is typical.  Let's look at the history, although it may be brief here.  I suggested this almost a year ago.  Others in this thread, although they may have a different purpose, asked about this capability 5 years ago. 

At the same time, LabVIEW adopts 'upgrades' every six months that, from my perspective, seem more as a mechanism to force users to the new products.  Many of the upgrades take LabVIEW in new directions and can be interesting at a more advanced level, but in the instruction of undergraduate engineering students, this has little purpose.  I don't want upgrades that cause me to change the LabVIEW lesson plans I have developed even though the changes are mostly superficial things like labels and where objects are located on menus.  A frustrating thing is that lab manuals are developed and printed (on paper) ahead of a course with directions for the 'old' version and then an upgrade happens that might create differences in the software, making the lab manual's directions 'wrong.'  With constant hardware, what we do in the laboratory does not change much and the software has to do a basic job of consistenty supporting the DAQ hardware's functions.  If the changes in LabVIEW versions become too great, our curriculum will switch over completely to MATLAB and use a fixed basis of hardware drivers.  In MATLAB, with its matrix formats, the error analysis is relatively easy to do and the plotting capabilities are superior.

The paradox for me is that I want upgrades, but upgrades that add capability to the LabVIEW without changing the functions that already work.  One of the desired upgrades is a new datatype for error analysis using duals, with a new wire color to respect the processing mathematics and provide support for error analysis.  Here I mean error as component of 'uncertainty' and 'error analysis' including the two main topics of 'error sources' and 'error propagation'.  These are important subjects in the undergraduate engineering curriculum and many research publications require the reporting of uncertainty.  Upgrading from v7 to v8.2, we saw that the 'LabVIEW people' thought it important enough to make the error datatype (execution errors) its own wire color and datatype as a distinct cluster (this 'dark yellow' appears as more an olive color) to replace the error stream's pink color of mixed datatype clusters.  From a user's perspective, error analysis of the measurement is important and should have its own datatype and wire color too.

Yes, there are ways in LabVIEW 8.2. (and probably later versions) to develop a new wire color and datatype but there is significant overhead using projects and classes.  The questions for me, as an instructor of lab courses, are how much of this needs to be taught to the students and will the learning of LabVIEW to perform DAQ become too complicated if projects and classes must be understood?  Digging down into the VI, sub-VI and function hierarchy levels, there has to be a balance struck between 'need-to-know' and 'don't go there'.  The projects and classes go up in level, placing VI's in a larger structure but we still must ask if this is 'need-to-know.'  If LabVIEW pursues this proposal of a new datatype and wire color for duals, this error analysis method would be placed on the current level of LabVIEW and we would not need to address different levels or ask if it is 'need-to-know.'  It becomes more functional and serves the user in providing simultaneous error calculations and a basis for uncertainty reporting.

[Pie56694]

Hi Isotherm,

There is a product suggestion, "Create an error propagation VI or set of VIs" that was created on 09/17/2005.  This is one suggestion amongabout 30,000 active product suggestions.  One of the metrics upon which a suggestion's priority is established is the number of similarsuggestions.  There are currently 0 similar suggestions.  If you feel your suggestion is not represented by this document, please let me know andI'll do my best to tack it down.

One technique I've seen used is to provide students with supporting files, functions, models or prototypes that are required to accomplish the task, but whose implementation is unimportant to the overall learning objective.  I've also seen labs assignments written cumulatively.  For example, the first lab may be to implement the error propagation library.  Subsequent labs could then use this functionality.  Another suggestion is a combination of the two ideas.  Students could be required to implement the "missing piece" in the overall error propagation library.  This provides a balance between the time required to implement the feature and the understanding required to achieve the larger learning objective.  Thanks for your feedback.

[CMal]

isotherm,

Can you explain more about the specifics of how you would like to use an "error propogation" datatype?  For example, what types of functions would use this datatype as an input or output?  Exactly what data would be contained on such a wire?  I'm asking this because I find this idea very interesting, but I'm not sure I totally understand what your suggestion would involve.

Chris M 

[isotherm]

I have been asked to provide more detail about the error propagation concept (from my perspective this means using duals).  

A dual is a number format that expresses a number as two parts: a center and an error. 

A center is definite number generated by measurement or calculation and is the primary thing being reported.  It is quantitative and by the nature of precision (either DAQ or numerical), is a rational number even though it is expressed in decimals.  

The error is also a definite number but is derived from two types of mathematics: one is the source of error, the other is the propagation of error.  The calculation of error source typically involves the quantization error or defined precision for the numeric scale.  However, the actual mathematics should be algebraic and not depend on any assumptions about the size of the error (ultimately no calculus is used).  In the calculation of duals, the center and error may not be independent.

All numbers are duals.  Exact numbers are those that have zero error.  At the same time, we can express that the number 0 (center=0) has a non-zero error and 0.00 is different than 0.000.  This also means that the computational steps, including addition, subtraction, etc., must have two tracks for calculating duals.  This is why a new datatype and wire color (built into LabVIEW) would be beneficial.  All existing functions could have new versions automatically selectable from the polymorphic list.  For example, addition is already a built-in polymorphic and could have version for duals.  However, there are new functions that are needed to do the math properly, for example inverse addition is not subtraction because the error must be calculated correctly.   There could be some defined defaults if a user does not specify enough to establish the dual.

Bottom line:

The numbers being reported or graphed have uncertainty reported and graphed too.  

If these methods are established for measurements, the approach can be applied to numeric error propagation and mathematics in general.  It would be nice if all software (MATLAB, LabVIEW, Excel,...) provided this as a built-in feature rather than requiring each user to develop the tools.  I have already developed some prototype tools and I am in the process of laying the mathematical foundation.