Subject:
|
FW: belated question from Mindfest
|
Newsgroups:
|
lugnet.robotics.rcx.pbforth
|
Date:
|
Tue, 2 Nov 1999 19:02:03 GMT
|
Viewed:
|
1456 times
|
| |
|
|
-----Original Message-----
From: Ralph Hempel [mailto:rhempel@bmts.com]
Sent: Monday, November 01, 1999 7:58 PM
To: munafo@gcctech.com
Subject: RE: belated question from Mindfest
> It was good talking to you at Mindfest. As you saw, I threw in my
> comments about the numeric library debate on LUGNET about 2 weeks after
> it was current, and I came in on the side of the applications programmer
> (rather than systems programmer) viewpoint.
Nice to meet you too. I'm not sure if anyone really appreciates
what you are trying to do. Making a trainable 'bot is really in the
realm of spraypainters and welders and such. Thank goodness you're not
teaching it where the obstacles are - yet!
> Nevertheless, at Mindfest I heard you emphasize the virtues of
> programming without variables and without any numerics beyond a basic
> 16-bit integer, and wanted to ask about doing my current project in
> pbFORTH. I almost had a chance to ask you on Sunday while you were
> setting up the maze robot but someone else started asking questions
> about the maze and I decided to save it for later.
More on variables shortly...
> My current project has a "data collection mode" and "behavior playback
> mode". In collection mode, it is accumulating statistics on five inputs
> (3 sensors and two motors) and their correlation to each other and to
> certain derived functions, using a total of about 15 variables. In
> playback mode, it continually reads the 3 inputs and regenerates the
> motor speed values as outputs using a model that treats the statistics
> as parameters in a set of equations.
Ok so far...
> Although this could be done entirely with the stack, I can't really see
> the point because every word in my program would end up looking
> something like this:
>
> : ACCUM_M1 ( f0 r0 f4 r4 f1 r1 f5 r5 f3 r3 f7 r7 l0 l9 lv lm t1 t2 t3 t4
> t5 t6 -- f0 r0 f4 r4 f1 r1 f5 r5 f3 r3 f7 r7 l0 l9 lv lm t1 t2 t3 t4 t5
> t6 ) // accumulates current reading into M1 totals
> INPUT_1 EX_MOTOR 4 NDUP + 4 NEXCH DROP
> 22 NDUP + 22 NEXCH DROP
> // more of the same to accumulate rotation and weighted correlations
> // (I forget how to write comments in FORTH)
> ;
Comments are either \ to the end of the line, or between ( ) chars - not nesting
Yeah, those words WOULD be ugly!
> As you can see I'm keeping all th "variables" on the stack, and using
> hypothetical words NDUP (that takes a parameter such as 22 and copies
> the 22nd cell on the stack) and NEXCH (that exchanges the top cell with
> the Nth cell). Such code would have hundreds of constants (like 22) that
> correspond to the precise location of each of the variables on the stack
> at that point in the code, and whenever you need to add more variables
> or temp storage space you would have to carefully recompute the proper
> values of all these constants.
Most Forth programmers avoid going more than 3 or four items deep
in the stack. That's because of a rule that says you can only ever keep 4 to
7 items in your head at once!
> So it seems a more standard implementation with variables is in order.
> But you seem to have quite a bit of experience avoiding the use of
> non-stack storage so I wanted to hear what you had to say.
From your earlier post on the issue of range on 32 bit numbers, I think
you will have a number of functions that accumulate statistics of
a couple of variables. You would probably have words which work something like
this (I may have to supply the double precision as an add-on):
2VARIABLE SUM_X
2VARIABLE SUM_Y
2VARIABLE SUM_X2
2VARIABLE SUM_Y2
2VARIABLE SUM_XY
etc
: SUM_VAR ( value var -- )
>R S->D 2+! ;
The +! word adds and stores all at once - 2+! is for doubles. S->D converts
a single to a double...
: SUM_VAR2 ( value var -- )
>R S->D 2DUP 2* R> 2+! ;
: SUM_VARVAR ( value value var -- )
>R >R S->D R> S->D 2* r> 2+! ;
and you'd use them like so...
5 4 DUP SUM_X SUM_VAR
DUP SUM_X2 SUM_VAR2
OVER SUM_Y SUM_VAR
OVER SUM_Y2 SUM_VAR2
SUM_XY SUM_VARVAR
Or something like that...
Hope this helps. Do you mind if I post your original and this to the pbForth
group?
Cheers,
Ralph Hempel - P.Eng
------------------------------------------------------
A picture is worth a thousand words, but very few
sets of a thousand words can be adequately described
by a picture...
------------------------------------------------------
Reply to: rhempel at bmts dot com
------------------------------------------------------
|
|
1 Message in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
