expanding linterp() and Origin

[wayne]

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. My programs, such as this one, are constructed in reference files and the matrices in the argument list are created in the main file.

As Valery has noted, general programs should be independent of the ORIGIN.

But, in general, the origin for the program and the matrices in the argument list may be different. I can include ORIGIN in the argument list easy enough, but I would rather not. So I need to be able to determine the origin of the input matrices inside the program. But, I don't see any functions that I can use directly. I could append something (a string perhaps) and find its indices an thus determine the origin, but is there a simple and direct way to do this?

[MikeArmstrong]

Something like the attached?

Mike

[wayne]

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.

[wayne]

Added to allow for vector or matrix

[MikeArmstrong]

How about this little mod?

Mike

[MikeArmstrong]

Simple as you like and it works with Matrices.

Mike

[wayne]

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

[MikeArmstrong]

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

[wayne]

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.

[MikeArmstrong]

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

[wayne]

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)

[MikeArmstrong]

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

[MikeArmstrong]

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

[wayne]

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.

[MikeArmstrong]

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

[wayne]

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.

[MikeArmstrong]

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

[wayne]

Mike,

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

Thanks,

Wayne

[MikeArmstrong]

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

[MikeArmstrong]

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