cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Mathcad without range variables

ValeryOchkov
24-Ruby II

Mathcad without range variables

Programming without GOTO statements - it is possible (a discussion of 30 years ago).

Mathcad without range variables - is it possible?

14 REPLIES 14
MikeArmstrong
5-Regular Member
(To:ValeryOchkov)

Why get rid of them and not just ignor them?

Mike

PhilipOakley
5-Regular Member
(To:MikeArmstrong)

Matlab manages without them, but that doesn't make it right.

We need horses for courses.

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)

Philip

MikeArmstrong
5-Regular Member
(To:PhilipOakley)

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)

Yes, this does need to be implemented. Have you requested this before?

Mike

PhilipOakley
5-Regular Member
(To:MikeArmstrong)

Mike Armstrong 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)

Yes, this does need to be implemented. Have you requested this before?

Mike

Yes, I've suggested it on the old collaboratory. 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.

One of the FFTs is for noise density (e.g. Volts per root Hz), and the other is for spot frequency amplitudes(volts). The time axis also becomes a frequency axis.

The discussion at the time also focused on the 'nearest' problem that match and comparisons have, along with choices about what sort of interpolation should be allowed if the index doesn't point to a particular sample of the vector.

Philip

Message was edited by: Philip Oakley. PS there is a simple way to decide if the index must be an integer or is a 'float', and that is the presence of dimensions, whether those are SI dimensions or off-system ones [Currency being an obvious off-SI-system dimension]

MikeArmstrong
5-Regular Member
(To:PhilipOakley)

The discussion at the time also focused on the 'nearest' problem that match and comparisons have, along with choices about what sort of interpolation should be allowed if the index doesn't point to a particular sample of the vector.

Have you got Mathcad 15? There is a feature which will allow the Match function to return the closet match, if an exact match is not found.

Message was edited by: Philip Oakley. PS there is a simple way to decide if the index must be an integer or is a 'float', and that is the presence of dimensions, whether those are SI dimensions or off-system ones [Currency being an obvious off-SI-system dimension]

I love the way Mathcad handles units, but you have defiantly found a flaw which should be addressed. I also think we should have a function UnitOf() which will keep track of the unit the way it is defined at sheet level, not convert it to SI units.

Mike

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.

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?

StuartBruff
23-Emerald II
(To:RichardJ)

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, y0.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

PhilipOakley
5-Regular Member
(To:StuartBruff)

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.

RichardJ
19-Tanzanite
(To:StuartBruff)

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.

Valery Ochkov wrote:

Programming without GOTO statements - it is possible (a discussion of 30 years ago).

Mathcad without range variables - is it possible?

More specific question.

Can we remove range variables from any (each) calculation?
I do not ask why.
I ask, can.
I know a lot of calculations, where range variables and vectors are in conflict and where better to retain only the vectors.

MikeArmstrong
5-Regular Member
(To:ValeryOchkov)

I know a lot of calculations, where range variables and vectors are in conflict and where better to retain only the vectors.

I fully agree with this and try and keep away from running calculations with range variables.

Mike

I am not sure what you are getting at,

But I (like Mike) use range variables to construct vectors, like x[i, so Phillps comment about moment at point on a beam, is never a function of a range variable, only of x. Actually, to keep straight for myself, when I want a vector of x values, I use xx[i, so I can use both M(x) and MM(xx) or MM[i=M(xx[i) so I don't screw one or the other up.

Is this what you are talking about?

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.

Announcements
Check out the latest
Mathcad Tip
"PTC Mathcad 15 / Prime 1-6 Update."