Hi,
I have never used locals until now, and would prefer not to.
I can't se a clean way to deal with this word using stack only.
The word have to interpolate x into two pairs of X,Y points.
There are 5 parameters on the stack. From diferent places on the code,
I use this word after extracting the to XY points from linearization
tables.
I don't want to make any pre-calculations since the user can change
values on the tables via Modbus or Front Pannel, while the instrument
is running.
Can anybody sugest a stack way of doing it, or a different aproach?
This is the word coded with locals.

\ Compiled with MPE Forth 6 locals sintax
\ Linear interpolation using locals
\
\ |Y2-Y1|
\ Y = Y2 - |-----| * [X2 - X]
\ |X2-X1|
\

: L.I { Y2 Y1 X2 X1 x -- y }
Y2 Y2 Y1 - X2 x - X2 X1 - */ - ;
\
\

Thanks in advance for any sugestions.

Alberto

From:	Jorge Acereda
Subject:	Re: question on locals vs stack
Date:	Wed, 12 Jan 2005 18:31:43 +0100

On 12 Jan 2005 08:55:08 -0800, alberto pasquale wrote:
> Just as a habit, I prefer words that work on what is on the stack, so
> to test them I don't have to declare a structure, fill it up and then
> inspect the result, I can just type 5 numbers at the ok prompt and see
> the result.

A non-portable crappy wrapper can help with that:

: clean-implementation-using-structs ( a1 a2 n1 -- n2 )
... ;

: dirty-wrapper-using-stack-values ( n1 n2 n3 n4 n5 -- n6 )
>r sp@ dup cell+ cell+ r> clean-implementation-using-structs ;

Greetings,
Jorge Acereda

From:	Ewald Pfau
Subject:	Re: question on locals vs stack
Date:	Wed, 12 Jan 2005 00:21:57 GMT

alberto pasquale wrote:

> I have never used locals until now, and would prefer not to.

Fine. Evaluated by simple steps in sequence, more or less:

> : L.I { Y2 Y1 X2 X1 x -- y }
> Y2 Y2 Y1 - X2 x - X2 X1 - */ - ;

\ ^ ^ ^ ^
\ -1.- -2.- -3.- -4.-

\ 1. >>"Y2 Y2 Y1 -"<<
>R >R >R ( [y2] [y1] )
over swap - ( [y2] [y2-y1] )

\ 3. >>"X2 X1 -"<<
R> R> ( ... [x2] [x1] )
over swap - ( ... [x2] [x2-x1] )

\ 2. >>"X2 x -"<<
swap R> - ( ... [x2-x1] [x2-x] )
swap ( [y2] [y2-y1] [x2-x] [x2-x1] )

\ 4. >>"Y2"<< "..." >>"*/ -"<<
*/ - ;

Now, steps 2. to 3. look as being improvable, when taken as one
double-step:

>R >R >R ( [y2] [y1] )
over swap - ( [y2] [y2-y1] )

\ 2. & 3. >>"X2 x -" "X2 X1 -"<<
R> R> over ( ... [x2] [x1] [x2])
R> - ( ... [x2] [x1] [x2-x] )
rot rot - ( [y2] [y2-y1] [x2-x] [x2-x1] )

*/ - ;

So this one for sure wasn't that hard. Seems to nicely fit into six lines. ;)
For fluent reading, the stack comments might be essential.

From:	Bruce McFarling
Subject:	Re: Question on locals vs stack
Date:	17 Jan 2005 06:38:43 -0800

Anton Ertl wrote:
> We had similar discussions about blocks vs. files, and this has
pretty
> much died down, so maybe the reasons given for not using locals are
> more valid, important, or universal than those given for not using
> files.

They are more universal -- locals interfere with factoring.

However, as this clever fellow Einstein once said,
make things as simple as possible, but not simpler.
There are instances, in particular with some
mathematical expressions, where sequential access
to input values entails duplications that random
access to the input values does not, and so its
a trade-off.

There is always a potential downside to using
locals, but there are times where the trade-off
is in its favour.

Of course, in any implementation without locals you
can always achieve the same effect by writing with
global variables and then writing a wrapper that
localises the variables, but that is getting into
the big forth versus little forth debate which is
another can of worms.

From:	dhoffman at talkamerica.net
Subject:	Re: Question on locals vs stack
Date:	17 Jan 2005 02:14:41 -0800

alberto pasquale wrote:

> Following
> previous threads in CLF, my understanding of what
> people that know allot more about Forth than I do
> said, was [snip] "the CPU design does not
> support them, because they are not needed in
> Forth".

OK. That clears it up entirely. If people here
said that locals are not needed in Forth then
surely that must be the case.

Regards,

-Doug

From:	alberto pasquale
Subject:	Re: Question on locals vs stack
Date:	15 Jan 2005 15:18:15 -0800

Jerry Avins wrote:
>
> I'm glad to be one of those who could help. Can you tell me, for my
own
> curiosity, what thermocouple type you usually use?
>
> Jerry
> --
> Engineering is the art of making what you want from things you can
get.
>
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF

Jerry,
Most of the code I have written to support TCs have been on general
purpose data acquisition multiplexers and recorders, so we supported a
large range of TCs and RTDs, (including GE 10 ohm Cu, embedded in GE
generators) and it is a user selection on a per-point bases. That was
all assembly code.
On the analyzer I'm working now in Forth, there is an S TC used as a
feed-back to control a burner at 1100 deg C.
Thanks again for your suggestions.
Regards,

Alberto

From:	Lady Chatterly
Subject:	Re: Question on locals vs stack
Date:	Mon, 17 Jan 2005 9:27:42 GMT

In article <1105831095.952840.146860@z14g2000cwz.googlegroups.com>
alberto pasquale wrote:
>
>Jerry,
>Most of the code I have written to support TCs have been on general
>purpose data acquisition multiplexers and recorders, so we supported a
>large range of TCs and RTDs, (including GE 10 ohm Cu, embedded in GE
>generators) and it is a user selection on a per-point bases. That was
>all assembly code.
>On the analyzer I'm working now in Forth, there is an S TC used as a
>feed-back to control a burner at 1100 deg C.
>Thanks again for your suggestions.
>Regards,

Clarke.

>Alberto

Gilberto

--
Lady Chatterly

"I was watching Lady Chatterly's webcam last night and she certainly
doesn't look like a bot to me. I'd provide the URL if I thought any
socmen were attracted to adult women." -- Peter J. Ross

From:	alberto pasquale
Subject:	Re: Question on locals vs stack
Date:	15 Jan 2005 15:30:34 -0800

dhoffman@talkamerica.net wrote:
> ....
> Let's assume for a moment that your original
> algorithm 1) was already optimized and correct and
> so forth. Given that, *what* was your objection
> to using locals? *That* is sticking to the
> original issue that you posted when you started
> this thread.
>
> I, like you, seek to be enlightened about such things
> Forth-related.
>
> Regards,
>
> -Doug

Doug,
Sometimes the answer is a different way to solve a problem, sometimes
is a different way to look at the problem, so all the answers, I think,
were sticking to the original issue.
As to my wanting to get rid of locals in my code, locals are new to me;
they did not exist on most of the Forth implementations that I used in
the past. Implementation of locals can be good on processors that
memory-map the stack to support stack frames, but not that good on
stack processors where only TOS (and NOS) sometimes are visible.
Following previous threads in CLF, my understanding of what people that
know allot more about Forth than I do said, was that it is not that
"locals are no good, because the CPU design does not support them "
but the other way around, "the CPU design does not support them,
because they are not needed in Forth". As a general design principle
I like designs that leave out anything that it is not necessary, for
economy and reliability. I don't always know how to do it, but that
is why I follow CLF, to try to learn from other people's ideas.
Regards,

Alberto

From:	Alex McDonald
Subject:	Re: Linearizing a thermocouple. Was "question on locals vs stack"
Date:	12 Jan 2005 10:04:04 -0800

Jerry Avins wrote:
> accurately to the nearest half degree C or quarter degree F.
>

More like 1/8 deg C, given 1.8 deg F per 1 deg C.
--
Regards
Alex McDonald

From:	Jerry Avins
Subject:	Re: Linearizing a thermocouple. Was "question on locals vs stack"
Date:	Wed, 12 Jan 2005 13:22:58 -0500

Alex McDonald wrote:

> Jerry Avins wrote:
>
>>accurately to the nearest half degree C or quarter degree F.
>>
>
>
> More like 1/8 deg C, given 1.8 deg F per 1 deg C.

I had that backwards: half degree F, quarter degree C. The error never
exceeds quarter degree F in that the nearest half degree is reported.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

From:	alberto pasquale
Subject:	Re: Linearizing a thermocouple. Was "question on locals vs stack"
Date:	12 Jan 2005 11:21:12 -0800

Jerry Avins wrote:
> alberto pasquale wrote:
>
> > Thanks all for taking the time to reply and for the good
sugestions.
> > Some comments,
> > The x/y pairs are not always stored in the same form, for
thermocouple
> > linearization, they are tables, sometimes I need to interpolate a
> > voltage to get a temperature and other times (cold junction comp) I
> > need to interpolate a temperature to get a voltage.
> > On other cases, the x/y pairs are calibration variables that are
> > independently calculated and periodically changed by auto
calibration
> > routines.
> > For that reason, I wanted to leave the decision of where the x/y
pairs
> > came from outside the linear interpolation word.
> > Just as a habit, I prefer words that work on what is on the stack,
so
> > to test them I don't have to declare a structure, fill it up and
then
> > inspect the result, I can just type 5 numbers at the ok prompt and
see
> > the result.
> > As to "pre-calculating the gradient" or slope of the line, since
I'm
> > using integer arithmetic, I prefer to leave this unresolved and
> > multiply by a fraction using */ as late in the calculation as
possible.
> > Thanks again all for commenting, where I work I'm the only person
using
> > Forth so I don get the benefits of pear reviews.
> >
> > Alberto
>
> Alberto,
>
> Most thermocouples are linear enough to need only mild correction,
> easily done. http://users.erols.com/jyavins/typek.htm is an article,
> including Forth code, about linearizing a type-K thermocouple*. The
> method, in 16-bit integer, converts zero to 50 millivolts to degrees
> (coefficients are given for C and F) accurately to the nearest half
> degree C or quarter degree F.
>
> Not shown is a different routine, using the same method but different
> coefficients, that converts from degrees to millivolts. Since the
range
> is covered by a table of eight entries, the need for two tables is
not a
> burden.
>
> I hope that you find the approach useful.
>
> Jerry
> __________________________________________
> * Ice-point compensation is not included.
> --
> Engineering is the art of making what you want from things you can
get.
>
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF

Thanks Jerry
I will study it.
What I have done in the past is creating tables to use linear
interpolation.
I coded a program using UR Forth on a PC that implemented the
polynomials as described by the ITS-90.
The program took as an input the maximum herror desired and keep
extending de end-points of each the segments until the interpolation in
the medle error was grater.
This aproach let me generate the smallest tables based on the accuracy
required by the application.
For the Ice-point compensation I take the temperature at the cold
junction, (usually measured with a thermistir or a digital sensor) and
do a revers look-up and interpolation into the TC table to obtain
microvolts and then add them to the TC reading.
On other aplications of reading linear sensors, I use the linear
interpolation not as a linearization tool, but just as a conversion to
a two point calibration line.
I use the same routine scaling 4 to 20 mA outputs, when the 4 mA is not
zero i.e. 4 to 20 mA equals n1 to n2 engineering units.
Because I use linear interpolation on several differen scenarios, is
that I wanted a word that does not work on a specific structure but
rather on 5 elements on the stack. =20

Regards,

Alberto

From:	Jerry Avins
Subject:	Re: Linearizing a thermocouple. Was "question on locals vs stack"
Date:	Wed, 12 Jan 2005 16:41:28 -0500

alberto pasquale wrote:

> Jerry Avins wrote:
>
>>alberto pasquale wrote:
>>
>>
>>>Thanks all for taking the time to reply and for the good
>
> sugestions.
>
>>>Some comments,
>>>The x/y pairs are not always stored in the same form, for
>
> thermocouple
>
>>>linearization, they are tables, sometimes I need to interpolate a
>>>voltage to get a temperature and other times (cold junction comp) I
>>>need to interpolate a temperature to get a voltage.
>>>On other cases, the x/y pairs are calibration variables that are
>>>independently calculated and periodically changed by auto
>
> calibration
>
>>>routines.
>>>For that reason, I wanted to leave the decision of where the x/y
>
> pairs
>
>>>came from outside the linear interpolation word.
>>>Just as a habit, I prefer words that work on what is on the stack,
>
> so
>
>>>to test them I don't have to declare a structure, fill it up and
>
> then
>
>>>inspect the result, I can just type 5 numbers at the ok prompt and
>
> see
>
>>>the result.
>>>As to "pre-calculating the gradient" or slope of the line, since
>
> I'm
>
>>>using integer arithmetic, I prefer to leave this unresolved and
>>>multiply by a fraction using */ as late in the calculation as
>
> possible.
>
>>>Thanks again all for commenting, where I work I'm the only person
>
> using
>
>>>Forth so I don get the benefits of pear reviews.
>>>
>>>Alberto
>>
>>Alberto,
>>
>>Most thermocouples are linear enough to need only mild correction,
>>easily done. http://users.erols.com/jyavins/typek.htm is an article,
>>including Forth code, about linearizing a type-K thermocouple*. The
>>method, in 16-bit integer, converts zero to 50 millivolts to degrees
>>(coefficients are given for C and F) accurately to the nearest half
>>degree C or quarter degree F.
>>
>>Not shown is a different routine, using the same method but different
>>coefficients, that converts from degrees to millivolts. Since the
>
> range
>
>>is covered by a table of eight entries, the need for two tables is
>
> not a
>
>>burden.
>>
>>I hope that you find the approach useful.
>>
>>Jerry
>>__________________________________________
>>* Ice-point compensation is not included.
>>--
>>Engineering is the art of making what you want from things you can
>
> get.
>
> ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
>
> Thanks Jerry
> I will study it.
> What I have done in the past is creating tables to use linear
> interpolation.
> I coded a program using UR Forth on a PC that implemented the
> polynomials as described by the ITS-90.
> The program took as an input the maximum herror desired and keep
> extending de end-points of each the segments until the interpolation in
> the medle error was grater.
> This aproach let me generate the smallest tables based on the accuracy
> required by the application.

Linear interpolation can use fewer points -- about half -- by moving the
end points of the straight segments off the true curve. Any such scheme
needs to accommodate arbitrary locations for the endpoints. My scheme of
quadratic interpolation uses 8 segments of equal size. The top three
bits determine the segment, hence the interpolation coefficients, and
the bottom 9 bits are plugged into the resulting parabola. For a
thermocouple, exact end- and midpoints can't be improved upon, but for
wilder curves, one can optimize by selecting the internal match point,
the terminal slopes (to keep derivatives from showing jumps) or any of
several other desirata.

> For the Ice-point compensation I take the temperature at the cold
> junction, (usually measured with a thermistir or a digital sensor) and
> do a revers look-up and interpolation into the TC table to obtain
> microvolts and then add them to the TC reading.
> On other aplications of reading linear sensors, I use the linear
> interpolation not as a linearization tool, but just as a conversion to
> a two point calibration line.
> I use the same routine scaling 4 to 20 mA outputs, when the 4 mA is not
> zero i.e. 4 to 20 mA equals n1 to n2 engineering units.
> Because I use linear interpolation on several differen scenarios, is
> that I wanted a word that does not work on a specific structure but
> rather on 5 elements on the stack.

It's a good word to have. So is my INTERPOLATE, which can be pointed to
any table of quadratic interpolation coefficients that uses a 3/9 split
on the output of a 12-bit ADC.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

From:	Elizabeth D. Rather
Subject:	Re: question on locals vs stack
Date:	Tue, 11 Jan 2005 16:34:58 -0800

"alberto pasquale" wrote in message
news:1105483999.309429.293350@c13g2000cwb.googlegroups.com...
> Hi,
> I have never used locals until now, and would prefer not to.
> I can't se a clean way to deal with this word using stack only.
> The word have to interpolate x into two pairs of X,Y points.
> There are 5 parameters on the stack. From diferent places on the code,
> I use this word after extracting the to XY points from linearization
> tables.
> I don't want to make any pre-calculations since the user can change
> values on the tables via Modbus or Front Pannel, while the instrument
> is running.
> Can anybody sugest a stack way of doing it, or a different aproach?
> This is the word coded with locals.
>

Sorry, I don't have time to think about the code in detail, but our approach
when working with vectors like this is to have vector operators, e.g. V+,
V-, V*/ (which multiplies a vector by a ratio of scalars), etc., whatever
your application needs. That way you're thinking about them as pairs,
rather than as individual stack items. The operators themselves are usually
written in code for speed. We have done both 2-vector and 3-vector
operators at various times.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

From:	dhoffman at talkamerica.net
Subject:	Re: Question on locals vs stack
Date:	15 Jan 2005 13:42:57 -0800

alberto pasquale wrote:

> but I also like the opportunity to learn thru the
> exchange of ideas. Just because you can solve a
> problem, does not mean that that was the best solution.
> People here tuck time to replay and Ewald showed me a
> way to solve the problem using the return stack,

Right. Ewold directly addressed your original
question:

"I have never used locals until now, and would prefer
not to. I can't se a clean way to deal with this word
using stack only."

1)
: L.I { Y2 Y1 X2 X1 x -- y }
Y2 Y2 Y1 - X2 x - X2 X1 - */ - ;

Ewold provided (I think) the following:

2)
>R >R >R ( [y2] [y1] )
over swap - ( [y2] [y2-y1] )

\ 2. & 3. >>"X2 x -" "X2 X1 -"<<
R> R> over ( ... [x2] [x1] [x2])
R> - ( ... [x2] [x1] [x2-x] )
rot rot - ( [y2] [y2-y1] [x2-x] [x2-x1] )

*/ - ;

Now. IMHO 2) is an abomination compared to 1).
I simply cannot agree that there is something
intrinsically "better" about 2) than 1). Why are
wild gymnastics on the return and normal stacks
considered "good" but using locals as in 1) is
"bad"? What am I missing?

> Elizabeth pointed me in the direction of writing
> primitives to work with x,y pairs, so they would look
> like one entity on the stack, reducing the stack
> parameters from 5 to 3,

OK. Elizabeth addressed your question. Though I never
saw a solution. But you already had a solution. Right?

> and Jerry, showed me a way of
> linearizing thermocouples, allot
> better that the one I have been
> using for years!

I think that is just great and my hat is off to Jerry
for providing you that information. Surely we will
all agree that a better algorithm and/or a more sound
physics-based approach is always better. *But*, this
has absolutely *nothing* to do with your original
question. You didn't ask about the mathematical
correctness of your algorithm.

Let's assume for a moment that your original
algorithm 1) was already optimized and correct and
so forth. Given that, *what* was your objection
to using locals? *That* is sticking to the
original issue that you posted when you started
this thread.

I, like you, seek to be enlightened about such things
Forth-related.

Regards,

-Doug

From:	Charles Melice
Subject:	Re: Question on locals vs stack
Date:	Mon, 17 Jan 2005 11:21:21 +0100

a écrit dans le message de news:
1105825377.242705.141630@f14g2000cwb.googlegroups.com...
>
> alberto pasquale wrote:
>
>> but I also like the opportunity to learn thru the
>> exchange of ideas. Just because you can solve a
>> problem, does not mean that that was the best solution.
>> People here tuck time to replay and Ewald showed me a
>> way to solve the problem using the return stack,
>
> Right. Ewold directly addressed your original
> question:
>
> "I have never used locals until now, and would prefer
> not to. I can't se a clean way to deal with this word
> using stack only."
>
> 1)
> : L.I { Y2 Y1 X2 X1 x -- y }
> Y2 Y2 Y1 - X2 x - X2 X1 - */ - ;
>
>
> Ewold provided (I think) the following:
>
> 2)
> >R >R >R ( [y2] [y1] )
> over swap - ( [y2] [y2-y1] )
>
> \ 2. & 3. >>"X2 x -" "X2 X1 -"<<
> R> R> over ( ... [x2] [x1] [x2])
> R> - ( ... [x2] [x1] [x2-x] )
> rot rot - ( [y2] [y2-y1] [x2-x] [x2-x1] )
>
> */ - ;
>
> Now. IMHO 2) is an abomination compared to 1).
> I simply cannot agree that there is something
> intrinsically "better" about 2) than 1). Why are
> wild gymnastics on the return and normal stacks
> considered "good" but using locals as in 1) is
> "bad"? What am I missing?

Doug,

Like you, I think it's always better to promote
the more readable version when possible. I prefer
the locals solution.

So, why to prefer the non local version ?

I think the main reason is that each time locals
is used, this demonstrate that another language
should be better to resolve the same problem.

Locals usage is opposed with the original Forth design,
at the esthetic and also at the efficacity level.

So, to be didactic in this newsgroup, it's probably
better to promote any solution that don't use locals.

Trying to not use locals open out a second nature, the
Forth approach, that optimize the fluidity in the stack
usage.

To obtain parameters fluidity in a readable solution, we
need to think at the dynamic level of the program.

That spirit is absent in the others programming languages I know.

Charles

>
>
>> Elizabeth pointed me in the direction of writing
>> primitives to work with x,y pairs, so they would look
>> like one entity on the stack, reducing the stack
>> parameters from 5 to 3,
>
> OK. Elizabeth addressed your question. Though I never
> saw a solution. But you already had a solution. Right?
>
>
>> and Jerry, showed me a way of
>> linearizing thermocouples, allot
>> better that the one I have been
>> using for years!
>
> I think that is just great and my hat is off to Jerry
> for providing you that information. Surely we will
> all agree that a better algorithm and/or a more sound
> physics-based approach is always better. *But*, this
> has absolutely *nothing* to do with your original
> question. You didn't ask about the mathematical
> correctness of your algorithm.
>
>
> Let's assume for a moment that your original
> algorithm 1) was already optimized and correct and
> so forth. Given that, *what* was your objection
> to using locals? *That* is sticking to the
> original issue that you posted when you started
> this thread.
>
> I, like you, seek to be enlightened about such things
> Forth-related.
>
> Regards,
>
> -Doug
>

From:	Anton Ertl
Subject:	Re: Question on locals vs stack
Date:	Mon, 17 Jan 2005 10:40:30 GMT

"Charles Melice" writes:
>Like you, I think it's always better to promote
>the more readable version when possible. I prefer
>the locals solution.
>
>So, why to prefer the non local version ?
>
>I think the main reason is that each time locals
>is used, this demonstrate that another language
>should be better to resolve the same problem.

Since Forth has locals, why should the use of locals demonstrate that?

However, I guess that the dogma started that way: Once upon a time,
Forth systems did not have locals; many Forth programmers did not miss
them, and gave various reasons why they were useless or even harmful;
these reasons are generally valid, but the dogmatic character of the
discussion surrounding the topic has some sour-grapes feeling. And
the dogmatic character of this discussion has persisted to some
degree, even though we now can reach the grapes:-).

We had similar discussions about blocks vs. files, and this has pretty
much died down, so maybe the reasons given for not using locals are
more valid, important, or universal than those given for not using
files. OTOH, maybe the reason for this is that we don't get many
questions along the lines of "Help! I don't know how to do that with
blocks; should I use files?"

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.complang.tuwien.ac.at/forth/ansforth/forth200x.html

From:	alberto pasquale
Subject:	Re: Question on locals vs stack
Date:	14 Jan 2005 18:04:35 -0800

dhoffman@talkamerica.net wrote:
> alberto pasquale wrote:
>
> > Just as a habit, I prefer words that work on what is on the stack,
> > so to test them I don't have to declare a structure, fill it up and
> > then inspect the result, I can just type 5 numbers at the ok prompt
> and
> > see the result.
>
>
> > Because I use linear interpolation on several differen scenarios,
is
> > that I wanted a word that does not work on a specific structure but
> > rather on 5 elements on the stack.
>
> Alberto,
>
> You have already solved the problem, quickly and cleanly IMHO, using
> locals. I then have to ask, why not just stop there and get on with
> life? Write more programs. Anything. I'm not following your
wanting
> to get rid of your, already working and very readable, definition
that
> happens to use locals.
>
> Another advantage to your 'locals' definition is that at any time you
> could completely change the order of the stack input but you would
not
> need to change your definition at all. Life is good.
>
> Regards,
>
> -Doug

Doug,
I keep writing software, is my job :); at some point, I have to put on
the instruments that I code, the best I can do, they have to go out and
work, but I also like the opportunity to learn thru the exchange of
ideas. Just because you can solve a problem, does not mean that that
was the best solution. People here tuck time to replay and Ewald showed
me a way to solve the problem using the return stack, Elizabeth pointed
me in the direction of writing primitives to work with x,y pairs, so
they would look like one entity on the stack, reducing the stack
parameters from 5 to 3, and Jerry, showed me a way of linearizing
thermocouples, allot better that the one I have been using for years!
And all that, just to help... what more can you ask for? :)
regards,

Alberto

From:	Jerry Avins
Subject:	Re: Question on locals vs stack
Date:	Sat, 15 Jan 2005 00:19:05 -0500

alberto pasquale wrote:

> ... Ewald showed
> me a way to solve the problem using the return stack, Elizabeth pointed
> me in the direction of writing primitives to work with x,y pairs, so
> they would look like one entity on the stack, reducing the stack
> parameters from 5 to 3, and Jerry, showed me a way of linearizing
> thermocouples, allot better that the one I have been using for years!

...

I'm glad to be one of those who could help. Can you tell me, for my own
curiosity, what thermocouple type you usually use?

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

From:	Stephen Pelc
Subject:	Re: question on locals vs stack
Date:	Wed, 12 Jan 2005 11:11:17 GMT

On 11 Jan 2005 14:53:19 -0800, "alberto pasquale"
wrote:

>I don't want to make any pre-calculations since the user can change
>values on the tables via Modbus or Front Pannel, while the instrument
>is running.
>Can anybody sugest a stack way of doing it, or a different aproach?
>This is the word coded with locals.
>
>\ Compiled with MPE Forth 6 locals sintax
>\ Linear interpolation using locals
>\
>\ |Y2-Y1|
>\ Y = Y2 - |-----| * [X2 - X]
>\ |X2-X1|
>\
>
>: L.I { Y2 Y1 X2 X1 x -- y }
>Y2 Y2 Y1 - X2 x - X2 X1 - */ - ;

If the X/Y pairs are stored in a table as adjacent cells,
why not pass a pointer to each X/Y pair? If the two pairs
are adjacent in the table then you only need to pass one
pointer rather than two.

: L.I \ p1 p2 x -- y
... ;

or

: L.I \ pp x -- y
... ;

Stephen

--
Stephen Pelc, stephenXXX@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

From:	dhoffman at talkamerica.net
Subject:	Re: Question on locals vs stack
Date:	17 Jan 2005 15:44:34 -0800

Anton Ertl wrote:

> We had similar discussions about blocks vs.
> files, and this has pretty much died down, so
> maybe the reasons given for not using locals
> are more valid, important, or universal than
> those given for not using files. OTOH, maybe
> the reason for this is that we don't get many
> questions along the lines of "Help! I don't
> know how to do that with blocks; should I use
> files?"

In this case wouldn't the better analogy be:
"Help! I already did this with files but I
don't want to use files, I would rather use
blocks; problem is I don't know how to do it
with blocks."?

Regards,

-Doug

From:	alberto pasquale
Subject:	Re: question on locals vs stack
Date:	12 Jan 2005 08:55:08 -0800

Thanks all for taking the time to reply and for the good sugestions.
Some comments,
The x/y pairs are not always stored in the same form, for thermocouple
linearization, they are tables, sometimes I need to interpolate a
voltage to get a temperature and other times (cold junction comp) I
need to interpolate a temperature to get a voltage.
On other cases, the x/y pairs are calibration variables that are
independently calculated and periodically changed by auto calibration
routines.
For that reason, I wanted to leave the decision of where the x/y pairs
came from outside the linear interpolation word.
Just as a habit, I prefer words that work on what is on the stack, so
to test them I don't have to declare a structure, fill it up and then
inspect the result, I can just type 5 numbers at the ok prompt and see
the result.
As to "pre-calculating the gradient" or slope of the line, since I'm
using integer arithmetic, I prefer to leave this unresolved and
multiply by a fraction using */ as late in the calculation as possible.
Thanks again all for commenting, where I work I'm the only person using
Forth so I don get the benefits of pear reviews.

Alberto

From:	Jerry Avins
Subject:	Linearizing a thermocouple. Was "question on locals vs stack"
Date:	Wed, 12 Jan 2005 12:37:31 -0500

alberto pasquale wrote:

> Thanks all for taking the time to reply and for the good sugestions.
> Some comments,
> The x/y pairs are not always stored in the same form, for thermocouple
> linearization, they are tables, sometimes I need to interpolate a
> voltage to get a temperature and other times (cold junction comp) I
> need to interpolate a temperature to get a voltage.
> On other cases, the x/y pairs are calibration variables that are
> independently calculated and periodically changed by auto calibration
> routines.
> For that reason, I wanted to leave the decision of where the x/y pairs
> came from outside the linear interpolation word.
> Just as a habit, I prefer words that work on what is on the stack, so
> to test them I don't have to declare a structure, fill it up and then
> inspect the result, I can just type 5 numbers at the ok prompt and see
> the result.
> As to "pre-calculating the gradient" or slope of the line, since I'm
> using integer arithmetic, I prefer to leave this unresolved and
> multiply by a fraction using */ as late in the calculation as possible.
> Thanks again all for commenting, where I work I'm the only person using
> Forth so I don get the benefits of pear reviews.
>
> Alberto

Alberto,

Most thermocouples are linear enough to need only mild correction,
easily done. http://users.erols.com/jyavins/typek.htm is an article,
including Forth code, about linearizing a type-K thermocouple*. The
method, in 16-bit integer, converts zero to 50 millivolts to degrees
(coefficients are given for C and F) accurately to the nearest half
degree C or quarter degree F.

Not shown is a different routine, using the same method but different
coefficients, that converts from degrees to millivolts. Since the range
is covered by a table of eight entries, the need for two tables is not a
burden.

I hope that you find the approach useful.

Jerry
__________________________________________
* Ice-point compensation is not included.
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

From:	Anton Ertl
Subject:	Re: question on locals vs stack
Date:	Wed, 12 Jan 2005 08:43:28 GMT

"alberto pasquale" writes:
>\ Linear interpolation using locals
>\
>\ |Y2-Y1|
>\ Y = Y2 - |-----| * [X2 - X]
>\ |X2-X1|

I see four subtractions here, resulting in loss of significant digits
when X1~X2 (X1 and X2 are almost the same), Y1~Y2, X2~X, or if Y2~the
rest. The X1~X2 case is especially bad, since it is then magnified by
the division; and given the purpose of the code, it is quite likely
that X1~X2. It is probably possible to transform this (and/or the
surrounding application) into a numerically more stable form. This
should be done before thinking about stack vs. locals.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.complang.tuwien.ac.at/forth/ansforth/forth200x.html

From:	andrew29 at littlepinkcloud.invalid
Subject:	Re: question on locals vs stack
Date:	Wed, 12 Jan 2005 10:25:55 -0000

Anton Ertl wrote:
> "alberto pasquale" writes:
>>\ Linear interpolation using locals
>>\
>>\ |Y2-Y1|
>>\ Y = Y2 - |-----| * [X2 - X]
>>\ |X2-X1|

> I see four subtractions here, resulting in loss of significant digits
> when X1~X2 (X1 and X2 are almost the same),

Sice this is interpolation in a table, we can perhaps hope that this
is not the case!

> Y1~Y2, X2~X, or if Y2~the rest. The X1~X2 case is especially bad,
> since it is then magnified by the division; and given the purpose of
> the code, it is quite likely that X1~X2. It is probably possible to
> transform this (and/or the surrounding application) into a
> numerically more stable form. This should be done before thinking
> about stack vs. locals.

Indeed. Rewriting this into slightly more intelligible (for me)
notation:

a <= x <= b, interpolate f(x)

f(b) - f(a)
grad = -----------
b - a

f(x) = f(b) - grad * (b - x)

This suggests a better scheme: perhaps the gradient could be
calculated at higher precision and stored, removing this inline
division and improving performance at some cost in memory.

Calculating or storing the gradient separately improves the Forth
considerably:

: interpolate ( f: grad fb b x - f) f- frot f* f- ;

The logic that calls interpolate will either calculate or fetch the
gradient.

Anyway, this whole thing can be rewritten:

x - a
f(x) = f(a) + ----- * (f(b) - f(a))
b - a

(b - x) * f(a) + (x - a) * f (b)
= --------------------------------
b - a

If the interval in the table is constant, b - a doesn't need to be
recalculated, and the subtractions are mostly harmless. (;-)

In answer to the original poster's question, you're doing it the wrong
way. The Right Way (TM) isn't to pass all the values on the stack,
but to pass an object into the word. The object is a pointer to a
structure that has operators which return vales.

Andrew.

From:	rickman
Subject:	Re: question on locals vs stack
Date:	Wed, 12 Jan 2005 13:02:16 -0500

Do you guys not know how linear interpolation is used? There is no
significant loss of accuracy in the calculations. It is used to reduce
the size of a table by allowing a smaller number of entries to be
stored. The entries that are removed can then be estimated with
reasonable accuracy by this simple interpolation. The only loss of
accuracy is due to the difference between the actual function and the
linear interpolation.

Don't confuse the loss of significant digits with the loss of accuracy.

andrew29@littlepinkcloud.invalid wrote:

> Anton Ertl wrote:
>
>>"alberto pasquale" writes:
>>
>>>\ Linear interpolation using locals
>>>\
>>>\ |Y2-Y1|
>>>\ Y = Y2 - |-----| * [X2 - X]
>>>\ |X2-X1|
>
>
>>I see four subtractions here, resulting in loss of significant digits
>>when X1~X2 (X1 and X2 are almost the same),
>
>
> Sice this is interpolation in a table, we can perhaps hope that this
> is not the case!
>
>
>>Y1~Y2, X2~X, or if Y2~the rest. The X1~X2 case is especially bad,
>>since it is then magnified by the division; and given the purpose of
>>the code, it is quite likely that X1~X2. It is probably possible to
>>transform this (and/or the surrounding application) into a
>>numerically more stable form. This should be done before thinking
>>about stack vs. locals.
>
>
> Indeed. Rewriting this into slightly more intelligible (for me)
> notation:
>
> a <= x <= b, interpolate f(x)
>
> f(b) - f(a)
> grad = -----------
> b - a
>
> f(x) = f(b) - grad * (b - x)
>
> This suggests a better scheme: perhaps the gradient could be
> calculated at higher precision and stored, removing this inline
> division and improving performance at some cost in memory.
>
> Calculating or storing the gradient separately improves the Forth
> considerably:
>
> : interpolate ( f: grad fb b x - f) f- frot f* f- ;
>
> The logic that calls interpolate will either calculate or fetch the
> gradient.
>
> Anyway, this whole thing can be rewritten:
>
> x - a
> f(x) = f(a) + ----- * (f(b) - f(a))
> b - a
>
> (b - x) * f(a) + (x - a) * f (b)
> = --------------------------------
> b - a
>
> If the interval in the table is constant, b - a doesn't need to be
> recalculated, and the subtractions are mostly harmless. (;-)
>
> In answer to the original poster's question, you're doing it the wrong
> way. The Right Way (TM) isn't to pass all the values on the stack,
> but to pass an object into the word. The object is a pointer to a
> structure that has operators which return vales.
>
> Andrew.

--

Rick Collins

rick.collins@XYarius.com

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design http://www.arius.com
4 King Ave. 301-682-7772 Voice
Frederick, MD 21701-3110 GNU tools for the ARM http://www.gnuarm.com

From:	dhoffman at talkamerica.net
Subject:	Re: question on locals vs stack
Date:	11 Jan 2005 22:29:22 -0800

alberto pasquale wrote:

[snip]
> Can anybody sugest a stack way of doing it, or a different aproach?
> This is the word coded with locals.
>
> \ |Y2-Y1|
> \ Y = Y2 - |-----| * [X2 - X]
> \ |X2-X1|
> \
>
> : L.I { Y2 Y1 X2 X1 x -- y }
> Y2 Y2 Y1 - X2 x - X2 X1 - */ - ;

Alberto,

Your problem and presented solution is an excellent case *for* using
locals in Forth. Ewald's stack-only solution just reinforces the
notion of using locals when needed. I know that this is a hotly
debated issue, but I prefer your more readable solution that also more
easily and cleanly gets the job done.
Thank you.

-Doug (user of locals)

From:	dhoffman at talkamerica.net
Subject:	Question on locals vs stack
Date:	13 Jan 2005 15:16:45 -0800

alberto pasquale wrote:

> Just as a habit, I prefer words that work on what is on the stack,
> so to test them I don't have to declare a structure, fill it up and
> then inspect the result, I can just type 5 numbers at the ok prompt
and
> see the result.

> Because I use linear interpolation on several differen scenarios, is
> that I wanted a word that does not work on a specific structure but
> rather on 5 elements on the stack.

Alberto,

You have already solved the problem, quickly and cleanly IMHO, using
locals. I then have to ask, why not just stop there and get on with
life? Write more programs. Anything. I'm not following your wanting
to get rid of your, already working and very readable, definition that
happens to use locals.

Another advantage to your 'locals' definition is that at any time you
could completely change the order of the stack input but you would not
need to change your definition at all. Life is good.

Regards,

-Doug