topic Re: expanding linterp() and Origin in Mathcad

expanding linterp() and Origin

wayne — Thu, 03 May 2018 18:42:20 GMT

The linterp() function fails where there are vertical lines, so I have added Linterp() to assign values at vertical lines.I use this often as I describe shapes for wind, soil, variable depth sections etc., Then I can numerically integrate or whatever.However, I always use ORIGIN=1.

Re: expanding linterp() and Origin

MikeArmstrong — Mon, 05 Sep 2011 22:18:32 GMT

Something like the attached?

Mike

Re: expanding linterp() and Origin

wayne — Mon, 05 Sep 2011 22:54:27 GMT

Hi Mike,

Something like that, Thought about that, but when I have a matrix, I cant use last(). So I could select the <1> column because I would always have that column if I had a matrix and not a vector.

Or, If I wanted to be more general and allow a vector or a matrix (because I am lazy) then I could augment the matrix with itslef, then I could do the test also.

But then, what if the matrix is big

So I thought, what abut using "on error" which I think works pretty well, what say you?

PS. normally when I see "error" I start looking for someone to blame, which is hard since I work moslty alone.

Re: expanding linterp() and Origin

wayne — Mon, 05 Sep 2011 23:35:37 GMT

Added to allow for vector or matrix

Re: expanding linterp() and Origin

MikeArmstrong — Tue, 06 Sep 2011 06:54:35 GMT

How about this little mod?

Mike

Re: expanding linterp() and Origin

MikeArmstrong — Tue, 06 Sep 2011 07:00:01 GMT

So I thought, what abut using "on error" which I think works pretty well, what say you?

Yes, I like your function, nice.

PS. normally when I see "error" I start looking for someone to blame, which is hard since I work moslty alone.

Made me laugh

Mike

Re: expanding linterp() and Origin

MikeArmstrong — Tue, 06 Sep 2011 12:13:31 GMT

Simple as you like and it works with Matrices.

Mike

Re: expanding linterp() and Origin

wayne — Tue, 06 Sep 2011 13:49:58 GMT

Mike, how would you handle the following?

But the problem is that the function may be in a referenced file with a different ORIGIN?

The origin for the program is 1

The origin for the matrix is 0

Re: expanding linterp() and Origin

MikeArmstrong — Tue, 06 Sep 2011 14:10:28 GMT

Wayne Reid wrote:
Mike, how would you handle the following?

I think it would be bad practice to have ORIGIN'S locally defined within programs. Is that the case with your work?

I think you'll end up running into issues if it is the case.

Mike

Re: expanding linterp() and Origin

wayne — Tue, 06 Sep 2011 14:35:08 GMT

Mike Armstrong wrote:
Wayne Reid wrote:
Mike, how would you handle the following?
I think it would be bad practice to have ORIGIN'S locally defined within programs. Is that the case with your work?
I think you'll end up running into issues if it is the case.
Mike

I use the same origin in all my work, ORIGIN=1.

But for a function that perhaps could be used by others who do not use the same origin, I am just trying to make idot (or wayne) proof.

The only reason I put origin in the example function is to imitate what whould happen if the function were defined in a separate file and referenced into the working file, and where the origin in each file may not be the same. The inherated value of ORIGIN in the program would be that of the referenced file. I did not acutally try yet, but pretty sure that is the case. I am certain that if ORIGIN was used inside the program, it would be that of the referenced file.

Re: expanding linterp() and Origin

MikeArmstrong — Tue, 06 Sep 2011 14:54:21 GMT

I use the same origin in all my work, ORIGIN=1.
But for a function that perhaps could be used by others who do not use the same origin, I am just trying to make idot (or wayne) proof.
The only reason I put origin in the example function is to imitate what whould happen if the function were defined in a separate file and referenced into the working file, and where the origin in each file may not be the same. The inherated value of ORIGIN in the program would be that of the referenced file. I did not acutally try yet, but pretty sure that is the case. I am certain that if ORIGIN was used inside the program, it would be that of the referenced file.

Your correct. The ORIGIN defined within the reference file takes presidents over the locally defined ORIGIN. As long as ORIGIN is not globally defined.

Mike

Re: expanding linterp() and Origin

wayne — Tue, 06 Sep 2011 15:32:03 GMT

Thanks Mike,

I think the error function method is truly independent of any inherited ORIGIN and will selected the current ORIGIN.

In the method you propose, which I like also, something still needs to be done achieve this independence. If the function is defined in the same file, it will work just fine.

Note: you could also change ORIGIN multiple times in a file, the Matrices would all adjust to the current ORIGIN, but the program would not. (I know this would be a bad idea, but it might be that someone may actually have a good reason in certain situations) (I can't think of one though)

Re: expanding linterp() and Origin

MikeArmstrong — Tue, 06 Sep 2011 20:00:42 GMT

Have a look at the attached Wayne,

The function 'seq' is based on an origin of 0, thus so is Mat, but if ORIGIN is defined as 1 above the origin(Mat) function the answers yields a 1, but the function Mat is based on an origin of zero.

Mike

Re: expanding linterp() and Origin

MikeArmstrong — Tue, 06 Sep 2011 20:09:12 GMT

I've been playing around with it and can't seem to find the answer. All all depends on where the ORIGIN is defined.

Tricky one this Wayne, keep us posted with the route you take.

Mike

Re: expanding linterp() and Origin

wayne — Tue, 06 Sep 2011 21:54:29 GMT

Mike,

It seems that matircies take on the current ORIGIN, regardless of what the ORIGIN was when it was defined. If you change the ORIGIN, the indices change accordingly.

Programs however, seem to retain the inherent ORIGIN under which they were deffined. You can define the ORIGIN inside the program, but the matrices will adjust to the ORIGIN that the program was defined under and do not adjust to re-definition of ORIGIN inside a program.

So I am thinking that if you define a matrix, say M[1 = 0, you can test to see if it has one or two elements, this will tell what the origin of the program is, and therefore the origin for the input matrices.

I think this is the case, see attached.

Re: expanding linterp() and Origin

MikeArmstrong — Wed, 07 Sep 2011 09:47:03 GMT

It seems that matircies take on the current ORIGIN, regardless of what the ORIGIN was when it was defined. If you change the ORIGIN, the indices change accordingly.

I think it depends on how the matrix defined. In the worksheet you posted the ORIGIN of Mat does not change if ORIGIN is defined locally, because the 'seq' function is defined above the first locally defined ORIGIN and takes the worksheet ORIGIN settings.

Mike

Re: expanding linterp() and Origin

wayne — Wed, 07 Sep 2011 16:16:37 GMT

Mike,
I think I understand now, sort of a lot of fuss about nothing.

The indices for Matrices reflect the currently assigned value of ORIGIN, regardless what the ORIGIN was when it was constructed.

Programs inherit the value of ORIGIN that was current when the program was defined.

It actually doesn't matter since the output matrices from the program will take on the value of ORIGIN currently outside the program or where ever the function is called.

The only problem is when you write a program and that uses the value of ORIGIN in the program (i=1..10 for ORIGIN=1 or i=0..10 for ORIGIN =0) and then copy that program into a work sheet with a different origin, then the inherited ORIGIN and the ORIGIN assumed in the program will not agree.

The function I provided that establishes the inherited ORIGIN and then use ranges like ( i=origin..rows(M)-1+origin) I haven't really worried about this, and don't know that I will. Also, in other programs that I have seen, I don't see this addresses either.

Is there bettter way to make the fuction independent of the value of ORIGIN, because what I did is kind of a pain.

Re: expanding linterp() and Origin

MikeArmstrong — Wed, 07 Sep 2011 20:21:58 GMT

Mike,
I think I understand now, sort of a lot of fuss about nothing.

Me too

The indices for Matrices reflect the currently assigned value of ORIGIN, regardless what the ORIGIN was when it was constructed.

Correct

Programs inherit the value of ORIGIN that was current when the program was defined.

Correct

The only problem is when you write a program and that uses the value of ORIGIN in the program (i=1..10 for ORIGIN=1 or i=0..10 for ORIGIN =0) and then copy that program into a work sheet with a different origin, then the inherited ORIGIN and the ORIGIN assumed in the program will not agree.

Yes this could be an issue.

Is there bettter way to make the fuction independent of the value of ORIGIN, because what I did is kind of a pain.

I think I am out of ideas to be honest Wayne. It's a tricky one - Best thing is to do everything to ORIGIN = 0

Mike

Re: expanding linterp() and Origin

wayne — Wed, 07 Sep 2011 22:00:23 GMT

Mike,

You had a type, but we all know you ment we should use ORIGIN = 1.

Thanks,

Wayne

Re: expanding linterp() and Origin

MikeArmstrong — Thu, 08 Sep 2011 06:34:35 GMT

You had a type, but we all know you ment we should use ORIGIN = 1.