Fitting VIs with mandatory X should assume simple ramp if X is left unwired

[altenbach]

Most fitting VIs have a mandatory input for X that is required to be the same sizes as the Y input. If left unwired, an error results, even though the x input is not designated a a required input for some reason.

Many times we want to fit a plain 1D array where the X value for each Y is simply the corresponding array index. In this case, the data and best fit arrays can be graphed on a waveform graph and we can ignore x entirely. This is now much cleaner and simpler than to construct the data for a multiplot xy graph.

Here is an example of a polynomial fit to a sine function, showing what we currently need to do. This idea would eliminate the need for the small FOR loop and associated wires:

 

My Idea is that most fitting VIs should assume a simple ramp if X is unwired.

(Applies to all fit function that have an X input and generate an error if it is left unwired: linear fit, polynominal fit, etc. )

Exceptions:

Fitting VIs that currently don't have a mandatory x input, e.g. "Nonlinear Fit" don't need to change, because it is up to the model to make assumptions about x. We already have full flexibility.

[X.]

Agreed that in most cases, equispaced X values are used and having to provide the full ramp is A BITredundant. However they are not in MOST cases just the Y array indices (0,1,...) but instead, as in waveforms, are characterized by an offset and a delta. So to be a tad more general than what you are suggesting, you could have an option of just providing that (offset and delta).

However, I personally don't mind providing a ramp, considering that there is a convenient VI that simplifies doing that (and has now an option to space the values logarithmically).

My 2 cts.

[GregSands]

The answer to X-)'s 2c is that the fitting functions should also be polymorphic to accept waveforms.  And for good measure, why not have the fitting functions able to accept any data format that can be plotted on an XY graph (e.g. complex numbers, or cluster arrays)?

But I also agree that using indices is a logical default in the absence of other information.

Side-note: sometimes it seems LabVIEW has too many ways to store the same data, and functions either support only a subset of formats, or are duplicated in different locations with different code and algorithms.

[X.]

I'll chip in a few more cts: what about an array of SDV of the abscissae in addition to that for the ordinates? Most of the time, it would be empty, but for us experimentalists, that is something of practical use (e.g. this Matlab routine for linear fits). It actually calls for a corresponding error bar graph object with error bars on both coordinates, but that's another topic...

My few more cents.

PS: this being said, a waveform input would make perfect sense.

[altenbach]

I guess this idea has not received much love in the last 10+ years, but since we now have malleable Vis, we probably could make our own with the following behavior:.

• works as before if x and y arrays are given
• can take a waveform and extract the x-ramp based on x0,dx. Outputs a waveform as best fit.
• can take a complex array and assume X=RE and y=IM. Outputs a complex array as best fit.
• (not sure about dynamic data support. we already have some express fitting VIs for that)