I know a lot of calculations, where range variables and vectors are in conflict and where better to retain only the vectors.
If there is a conflict then they are not being used correctly.
I agree they confuse people sometimes (in which case they are not used correctly, and that can lead to problems), but they can also be useful sometimes.
One particular area I'd like it for is fft() and FFT() which could then get the right units for the frequency spacing and the amplitude units in the two cases e.g. for a voltage sequence in time.
The FFT takes only a vector of y values, and as such knows nothing about the x values.
It would be nice if it handled the y units correctly though, as opposed to what it does now, which is to handle them incorrectly (it appears to just pass them through to the result).
Edit: Jet lag is evidently fugging up my brain. Passing the units through to the result is exactly what it should do.
Richard Jackson wrote:
We also need dimensional indexing as well, e.g. if you have a beam, you should be able to get at the result's vector for location r=0.5m, not just have to access at index=20 (or what ever step size was used)What's wrong with the lookup function?
Just my take on things, but the capability is already present in the form of lookup and interpolation functions (I suppose a lookup function could be regarded as a special form of interpolation?).
However, it could possibly be combined with the request for individual array index ranges by incorporating an implicit or explicit independent variable as part of the array data structure.
For example.
If y is vector defined by y:=sin(x), then Mathcad would create a vector of sine values with the generating x-values embedded in it. Normally, this x vector would be invisible to the user, so 'y=' would give just the y-values. Indexing would then be, for example, y_{0.3}. The question of interpolation could be handled in a similar way to the solve blocks, where the user would select from a right-click menu and choose, say, cspline or match. Normal indexing would still be useful and could be addressed by putting 'index' as one of the interpolation options. Multiple arguments would be handled in a similar way, with 'ordinary' multi-dimensional arrays holding the corresponding x,y,z,whatever values. Some functions, such as fft, could store the equivalent transformed independent values rather than the source values.
However, there would clearly be penalties in terms of memory for large arrays and readability - I'm not a big fan of hidden functionality (such as solver or interpolator choice) and might be even more unclear (especially to the author 🙂 ) what's going on.
There might be compromises in terms of new operators for 'association' and 'interpolated indexing' that would allow a more explicit representation.
Stuart
Hi Stuart,
Stuart_Bruff wrote:
Just my take on things, but the capability is already present in the form of lookup and interpolation functions (I suppose a lookup function could be regarded as a special form of interpolation?).
I'd say that the capability is no more present than that of MDA's, that is one can frig a mechanism that approximates what you / I want, but it isn't the real thing 😉
At the moment you would need an ancillary vx vector for each of the vy data vectors.
Stuart_Bruff wrote:
However, it could possibly be combined with the request for individual array index ranges by incorporating an implicit or explicit independent variable as part of the array data structure.
...
However, there would clearly be penalties in terms of memory for large arrays and readability - I'm not a big fan of hidden functionality (such as solver or interpolator choice) and might be even more unclear (especially to the author 🙂 ) what's going on.
The mechanism I would desire would be the association of a dimensioned range variable as the 'indexer'. This would ensure the user index has the right dimensionality (inherent error checking) and would cleanly define the step increment, and CTOL can be used for the 'neareness' off the regular computed integer index.
Note that pure numbers which are not integer would not be allowed as an index, just as at present. It is the fact that the index value has a dimension that immediately makes mathcad use the vector's embedded range definition for computing the vector's counted index location.
It is the presence of the dimension for the vector index that allows the FFT and fft functions to compute a new embedded range for the result vector, e.g. Time => Hz, t=0s,1s;99s => f=0Hz,0.01Hz;0.5Hz (for the all-real case where N samples returns N/2 + 1 samples).
Other functions do other things to the resulting range index, some of which are not representable in this linear step scheme. But most folk are using linear steps most of the time.
Philip
Message was edited by: Philip Oakley, I emphasised the associated //range variable//, which has low storage requirements, even for very large data vectors. The mechanism is also backward compatible.
However, there would clearly be penalties in terms of memory for large arrays and readability - I'm not a big fan of hidden functionality (such as solver or interpolator choice) and might be even more unclear (especially to the author 🙂 ) what's going on.
I agree with this statement. The price is too high just to avoid the rather simple job of keeping a separate x vector. Or an x column in a matrix, or a nested vector with x and y.