How to creat a numerical error propagation program

Question

trying to create a numerical error propagation program

Answer 1

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.