I have a copy of Nathaniel Grossman's article in FIG (Sept/Oct 1984)
discussing continued fractions, but his program was for 16-bit
Forth-83, and generated 16-bit results. I am in the process of
upgrading this to 32-bit ANS-Forth to generate 32-bit results. Has
anybody done this already?

In article <c9076eea-96f2-4384-8dcc-1e096bbe3c46@j14g2000yqm.googlegroups.com>,
Hugh Aguilar  <hugoaguilar@rosycrew.com> wrote:
>I have a copy of Nathaniel Grossman's article in FIG (Sept/Oct 1984)
>discussing continued fractions, but his program was for 16-bit
>Forth-83, and generated 16-bit results. I am in the process of
>upgrading this to 32-bit ANS-Forth to generate 32-bit results. Has
>anybody done this already?

I doubt that there is much to porting that code except for
an occasional 2 + replaced by CELL+ (if even that).
I have been doing a lot recently with continued fractions.

Below are a few of the definitions I have been using.
I discovered that it is useful to have two pairs of
numbers on the stack here, \\ takes 5 arguments!
Probably Grossman was not so daring.

A typical usage is:

\ Note single precision numbers, the comma's are to keep track.
2,000,000,000,000 SQRT 1,000,000 .CF
1 2 2 2 2 2 2 2 2 2 OK
\ Continued fraction of sqrt 2.

\ Calculate back to square root approximation
\\: 1 \\ 2 \\ 2 \\ 2 \\ 2 \\ 2 \\
\ Two convergents of SQRT(2) , i.e. 4 numbers

The code
"
WANT PRIME?
WANT GCD
WANT SQRT
: SQ DUP * ;

\ convergent
: CONV   CREATE 2 CELLS ALLOT DOES> 2@ ;

\ Leave START value for convergents.
: \\:   0 1 1 0 ;

\ For CONV1 CONV2 incorporate N (cf term), return CONV2 CONV3
: \\   >R 2SWAP 2OVER R@ * SWAP R> * SWAP  D+ ;

\ Convergents for sqrt(3)
: test  \\: 1 \\ 10 0 DO 1 \\ 2 \\ OVER . &/ EMIT OVER . CR LOOP ;

\ Print N
: ## 0 <# #S #> TYPE ;

\ Print a fraction D N
: frac   2DUP GCD >R  R@ / SPACE ## &/ EMIT R> / ## SPACE ;

\ For A B print its continued fraction and the GCD.
: .CF SWAP BEGIN OVER /MOD . DUP WHILE SWAP REPEAT DROP &| EMIT . ;
"

Applicable library screens:

"
( SQRT x^x                               ) \ AvdH A8nov09
\ For N return FLOOR of the square root of n.
: SQRT  DUP >R 10 RSHIFT 1024 MAX  \ Minimize iterations.
   BEGIN R@ OVER / OVER + 1 RSHIFT  2DUP > WHILE
    SWAP DROP REPEAT   DROP RDROP ;
VARIABLE m ( Modulo number)
\ Multiply A and B modulo ``m'' , return product of a and b.
: *MOD   M* m @ SM/REM DROP ;
\ A step of Russian peasant, for A B and C: return A B en C.
: reduce_1-  1- >R >R    R@ *MOD   R> R> ;
\ A step of Russian peasant, for A B and C: return A B en C.
: reduce_2/   2/ SWAP   DUP *MOD   SWAP ;
\ Calculate B^C mod MOD by Russian peasant method. Return IT.
: x^x    m @ >R m !   1 ROT ROT
   BEGIN   DUP 1 AND IF   reduce_1-   THEN reduce_2/
      DUP 0= UNTIL   2DROP   R> m ! ;
( PRIME? FACTOR GCD                        ) \ AvdH A9feb06
\ For N and HINT return FACTOR >= hint, maybe n.
: FACTOR   BEGIN   2DUP /MOD SWAP
    0= IF DROP SWAP DROP EXIT THEN
    OVER < IF DROP EXIT THEN
2 + AGAIN ;

\ For N return: "It IS prime" ( Cases 0 1 return FALSE)
: PRIME?
  DUP 4 < IF 1 > EXIT THEN     \ 0 1 2 3
  DUP 1 AND 0= IF DROP 0 EXIT THEN  \ Even non-prime.
  DUP 3 FACTOR = ;

\ For M N , return their GCD.
: GCD   BEGIN OVER MOD DUP WHILE SWAP REPEAT DROP ;

"

The code above works irrespective of cell size,
but of course the number range is limited on 16 bits.

Note: 0 SQRT crashes.

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On Nov 17, 6:54=A0am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> I doubt that there is much to porting that code except for
> an occasional 2 + replaced by CELL+ (if even that).
> I have been doing a lot recently with continued fractions.

For reasons unknown, ANS-Forth doesn't support multiplication and
division of double-precision integers. That is the problem.

Op Tue, 17 Nov 2009 16:35:43 -0800 (PST) schreef Hugh Aguilar:

> On Nov 17, 6:54�am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
> wrote:
>> I doubt that there is much to porting that code except for
>> an occasional 2 + replaced by CELL+ (if even that).
>> I have been doing a lot recently with continued fractions.
> 
> For reasons unknown, ANS-Forth doesn't support multiplication and
> division of double-precision integers. That is the problem.

It's not a fault of standarisation.
Double precision multiply is quite simple, with PICK and, alas, ROLL:

: D*    ( d1 d2 -- d3 )
        over 4 pick um* 5 roll 3 roll * + 2swap * + ;

And when going to a wider cellwidth, double precision is much less
needed.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html

On Nov 17, 6:33=A0pm, Coos Haak <chfo...@hccnet.nl> wrote:
> > For reasons unknown, ANS-Forth doesn't support multiplication and
> > division of double-precision integers. That is the problem.
>
> It's not a fault of standarisation.
> Double precision multiply is quite simple, with PICK and, alas, ROLL:
>
> : D* =A0 =A0( d1 d2 -- d3 )
> =A0 =A0 =A0 =A0 over 4 pick um* 5 roll 3 roll * + 2swap * + ;
>
> And when going to a wider cellwidth, double precision is much less
> needed.

Good job on the D* --- now lets see D/ :-)

Op Tue, 17 Nov 2009 17:43:34 -0800 (PST) schreef Hugh Aguilar:

> On Nov 17, 6:33�pm, Coos Haak <chfo...@hccnet.nl> wrote:
>>> For reasons unknown, ANS-Forth doesn't support multiplication and
>>> division of double-precision integers. That is the problem.
>>
>> It's not a fault of standarisation.
>> Double precision multiply is quite simple, with PICK and, alas, ROLL:
>>
>>: D* � �( d1 d2 -- d3 )
>> � � � � over 4 pick um* 5 roll 3 roll * + 2swap * + ;
>>
>> And when going to a wider cellwidth, double precision is much less
>> needed.
> 
> Good job on the D* --- now lets see D/ :-)

This D* can be found in Forth Dimensions year 4.

: dm/mod        ( q d1 -- d2 d3 )
        2>r dup 2r> rot over xor >r 2>r qabs 2r@ dabs dum/mod
        2swap 2r> nip 0<
        if      dnegate
        then
        2swap r> 0<
        if      dnegate
        then
        rdrop rdrop
    ;

: d/mod         ( d1 d2 -- d3 d4 )
        2>r d>q 2r> dm/mod
    ;

: d/            ( d1 d2 -- d3 )
	d/mod 2nip
    ;

This is a symmetric signed division.
The prefix 'q' is my designation of quadruple precision.
I wrote DUM/MOD and QABS in assembler.
This code is very old, for my ZX Spectrum. Rarely used since.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html

On Nov 17, 6:56=A0pm, Coos Haak <chfo...@hccnet.nl> wrote:
> This is a symmetric signed division.
> The prefix 'q' is my designation of quadruple precision.
> I wrote DUM/MOD and QABS in assembler.
> This code is very old, for my ZX Spectrum. Rarely used since.

The problem is that I need DUM/MOD ( uq ud -- udRem udQuot )

This is something that really needs to be written in assembly
language. This was true in the days of Z80 programming on the Timex
computer, and it is true today on the big 32-bit processors. I'm in
the process of writing DUM/MOD in Forth, but the result is going to be
horribly slow execution speed. For continued fractions, speed isn't
much of an issue because the purpose is to find ratios that will be
used as literals in */, which means that the DUM/MOD is being
performed at compile-time. Unfortunately, for my own purposes, speed
is an issue because DUM/MOD wiil be performed at run-time. Also
unfortunately, I have to write this in ANS-Forth because I want my
program to be portable and I can't take recourse in assembly language.

Forth is actually better than C in regard to single-precision
arithmetic because we can use mixed-precision functions to avoid
overflow of intermediate values. These functions are the same speed as
single-precision functions, so there is no cost in doing this --- as
compared to C where all the arithmetic has to be done in double-
precision just to avoid a few overflows, which is much slower.
Unfortunately, ANS-Forth didn't take the next obvious step and provide
mixed-precision functions for double words to overflow into quadruple
words.

The popularity of Forth plummeted around 1994, and 1994 was the year
that the ANS-Forth standard came out. Coincidence? I don't think so.
If a little bit more thinking had been done when ANS-Forth was
designed, Forth might have become an important language. Instead,
Forth became a bad joke. When I apply for work as a GCC programmer, I
don't make any mention of my Forth experience because this is
generally seen as a negative rather than a positive. The problem with
excising Forth from my resume however, is that it results in a gap of
about two years that I have no explanation for.

In article <7a2ad305-964c-415d-a145-4b7a3794d979@a21g2000yqc.googlegroups.com>,
Hugh Aguilar  <hugoaguilar@rosycrew.com> wrote:
>On Nov 17, 6:54=A0am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
>wrote:
>> I doubt that there is much to porting that code except for
>> an occasional 2 + replaced by CELL+ (if even that).
>> I have been doing a lot recently with continued fractions.
>
>For reasons unknown, ANS-Forth doesn't support multiplication and
>division of double-precision integers. That is the problem.

Maybe ANS-Forth thought it didn't make sense to force me to
implement a 128 bit by 128 multiplication on a 64 bit Forth.

I can see your porting problem now. But your double precision
integers have half the precision of single precision integers
on my lina64. Turning double precision into single is much
easier than the other way around, if that is any consolation.

Groetjes Albert
>


--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On Nov 17, 8:46 pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> Maybe ANS-Forth thought it didn't make sense to force me to
> implement a 128 bit by 128 multiplication on a 64 bit Forth.

Multiplication is trivial on almost all processors, as hardware
multiply is quite common. Even the 8051 has hardware multiply. Note
that a low-precision hardware-multiply can be used to implement a
higher-precision multiplication. We are talking about DUM/MOD anyway
--- that's division, not multiplication.

Division is non-trivial because a low-precision hardware-division
can't be used to implement a higher-precision division. If you don't
have a big enough hardware-division, then you just have to implement
the function using the bit-at-a-time method. This isn't trivial, but
it isn't impossible either. If the programmer knows how the algorithm
works, he can implement any size of division with equal ease.

Compiler writers are supposed to be smarter than common programmers,
so it makes more sense to stick them with the job of implementing DUM/
MOD, rather than leave it up to the programmer. Most programmers who
discover that DUM/MOD is missing from Forth are just going to say: "To
hell with Forth, I'll just switch to GCC and declare all of my
variables as long ints."

What is utterly ridiculous is that, in the year 2009, I'm writing an
integer division function in Forth because I want my program to be
portable. Even unemployed programmers such as myself have better
things to do with our time than this. That is the kind of thing that
programmers did in the bad-old days of the ZX Spectrum (I'm actually
old enough to know what that is, btw).

This is Grossman's article: http://www.forth.org/fd/FD-V06N3.pdf

Hugh Aguilar <hugoaguilar@rosycrew.com> wrote:
> Division is non-trivial because a low-precision hardware-division
> can't be used to implement a higher-precision division.

Sure it can.  It's in Knuth, Vol 2, Section 4.3.1, Algorithm D.

Andrew.

Hugh Aguilar wrote:
> On Nov 17, 8:46 pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
> wrote:
> > Maybe ANS-Forth thought it didn't make sense to force me to
> > implement a 128 bit by 128 multiplication on a 64 bit Forth.
>
> Multiplication is trivial on almost all processors, as hardware
> multiply is quite common. Even the 8051 has hardware multiply. Note
> that a low-precision hardware-multiply can be used to implement a
> higher-precision multiplication. We are talking about DUM/MOD anyway
> --- that's division, not multiplication.
>
> Division is non-trivial because a low-precision hardware-division
> can't be used to implement a higher-precision division. If you don't
> have a big enough hardware-division, then you just have to implement
> the function using the bit-at-a-time method. This isn't trivial, but
> it isn't impossible either. If the programmer knows how the algorithm
> works, he can implement any size of division with equal ease.

If you've got cheap multiplication, addition and subtraction, why not
just use them to generate the reciprocal and multiply by that? The
standard iteration for that is

x(n+1) = x(n) * (2 - a * x(n)) to converge on 1/a

It doubles the number of significant figures if the seed is close
enough for good convergence, so you would only need one pass if you
used low-precision division to get the seed; alternatively, you can
get it from a look up table or by looping through doing halving/
doubling until you get into a target magnitude range (and then you
make the seed the appropriate power of 2, with the appropriate sign).

This also works for matrices and similar things, if the seed is close
enough - but remember to keep the multiplications the right way round,
as they aren't commutative then. It's also trickier to get a seed
(though I know a trick for that involving homotopies). P.M.Lawrence.

> The popularity of Forth plummeted around 1994, and 1994 was the year
> that the ANS-Forth standard came out. Coincidence? I don't think so.

The move from 16-bit to 32-bit in the PC world would have hit Forth
applications harder than it did C applications, since in C the
application kind of specifies the VM it wants to run on. That happened
about the time Windows 95 came out.

-Brad

In article <75abaa46-78f9-416e-8901-d491460812f0@b15g2000yqd.googlegroups.com>,
Hugh Aguilar  <hugoaguilar@rosycrew.com> wrote:
>On Nov 17, 6:56=A0pm, Coos Haak <chfo...@hccnet.nl> wrote:
>> This is a symmetric signed division.
>> The prefix 'q' is my designation of quadruple precision.
>> I wrote DUM/MOD and QABS in assembler.
>> This code is very old, for my ZX Spectrum. Rarely used since.
>
>The problem is that I need DUM/MOD ( uq ud -- udRem udQuot )

Only if you haven't switched to a 32 bit Forth.
Do you work on a 16 bit Forth?

<SNIP >

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

In article <8f1c8432-78b1-4e11-83f6-9b9d3b819ca4@a31g2000yqn.googlegroups.com>,
Hugh Aguilar  <hugoaguilar@rosycrew.com> wrote:
>On Nov 17, 8:46 pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
>wrote:
>> Maybe ANS-Forth thought it didn't make sense to force me to
>> implement a 128 bit by 128 multiplication on a 64 bit Forth.
>
>Multiplication is trivial on almost all processors, as hardware
>multiply is quite common. Even the 8051 has hardware multiply. Note
>that a low-precision hardware-multiply can be used to implement a
>higher-precision multiplication. We are talking about DUM/MOD anyway
>--- that's division, not multiplication.

That is not my point. My point is that 256 is a precision that is
rarely needed. If you need 256 bit, you're likely to need unlimited
precision. Double precision in 32 bits is luxury, in 64 bits it is
exhilarating, and beyond that it is number theory.

<SNIP>

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On Nov 18, 6:03=A0am, "P.M.Lawrence" <pml540...@gmail.com> wrote:
> If you've got cheap multiplication, addition and subtraction, why not
> just use them to generate the reciprocal and multiply by that? The
> standard iteration for that is
>
> x(n+1) =3D x(n) * (2 - a * x(n)) to converge on 1/a

For any integer > 1, the reciprocal rounds off to zero --- as they say
in the mathematics department: "oops!"

Your method is actually a pretty cool way to do floating-point
division on processors that lack an appropriate sized integer division
for the significand, but it doesn't bring us any closer to DUM/MOD.
I'm still faced with the bit-at-a-time method written in Forth.

On Nov 18, 3:02=A0am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
> > Division is non-trivial because a low-precision hardware-division
> > can't be used to implement a higher-precision division.
>
> Sure it can. =A0It's in Knuth, Vol 2, Section 4.3.1, Algorithm D.
>
> Andrew.

I don't have Knuth's books --- can you describe the algorithm?

Hugh Aguilar <hugoaguilar@rosycrew.com> wrote:
> On Nov 18, 3:02?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
> > Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
> > > Division is non-trivial because a low-precision
> > > hardware-division can't be used to implement a higher-precision
> > > division.
> >
> > Sure it can. ?It's in Knuth, Vol 2, Section 4.3.1, Algorithm D.

> I don't have Knuth's books --- can you describe the algorithm?

I could, but it's a fair bit of work and I'd probably make a mistake
somewhere.

There's a (rather long-winded) article at
http://sputsoft.com/2009/08/implementing-multiple-precision-arithmetic-part-2/
"Algorithm L" most of the way down the page looks very like Knuth's
Algorithm D.  It's basically long division by computer, and the only
tricky part is estimating qhat, the quotient digit.

Andrew.

According to Hugh Aguilar  <hugoaguilar@rosycrew.com>:
> I don't have Knuth's books --- can you describe the algorithm?

The "one bit at a time" algorithm is just a special case of the
"manual division" that kids learn at school. Basically:

Let b be the "base". The dividend and divisor will be expressed as
numbers in that base:

   dividend:  u = \sum u_i*b^i
   divisor:   v = \sum v_i*b^i

Kids use b = 10. When talking about individual bits, we use b = 2.
Later on, we will use b = 2^32 (assuming that the hardware offers a
division opcode able to divide a 64-bit unsigned integer by a 32-bit
unsigned integer -- the "div" opcode on i386 processors).

At each step, we have what remains of the dividend (let's call that w),
and we "shift" the divisor so that the shifted divisor is no greater
than w, but cannot be shifted any further. In other words, we use n such
that v*b^n <= w < v*b^(n+1). Then we "guess" the next digit d, which is
floor(w/(v*b^n)). Then we subtract d*v*b^n from w; at next step, we will
use n-1, and so on, until n = 0 is reached (at which point what remains
of the dividend is lower than the divisor, and constitutes the
"remainder").

The crucial part here is the "guessing" of the digit. With b = 2, this
is awfully easy: a digit in base 2 is either 0 or 1, so all you have to
do is to compare the shifted divisor with w: this is done with a
subtraction; if there is no carry, then the result is positive, the
digit is 1, and the result of the subtraction is your new w; otherwise,
the digit is 0, and w is kept unchanged for the next step.

We all know that in b = 10, the guessing is a bit trickier. We look at
the top two digits of the dividend and the top digit of the divisor,
and occasionally we get it wrong, and have to "guess again".

With b = 2^32, the "guess again" process goes thus:

-- First, we initially arrange for the top digit of the divisor to be
"big", i.e. no less than b/2. This is done by left shifting the divisor
by z bits (z <= 31); the dividend is also left-shifted by z bits. Since
both dividend and divisor are multiplied by 2^z, the quotient is
unchanged, but we will have to right-shift the remainder by z bits, at
the end. This is done once for the whole division.

-- At every step, we now have:

   w = (wh*b + wl)*b^m + ws     (the current remainder)
   x = xh*b^m + xs              (the shifted divisor)

with the following properties:

   0 <= wh < b
   0 <= wl < b
   0 <= ws < b^m
   b/2 <= xh < b
   0 <= xs < b^m
   w < x*b

We want to compute the digit d which is the quotient of w by x. By
construction, we will have 0 <= d < b (that's a digit). We compute
an intermediate value y:

   if xh = wh, then y = b-1
   otherwise, y = floor((wh*b+wl)/xh)

The computation of y is where we use the unsigned 64-bit-by-32-bit
opcode which the hardware provides. This computation never fails
(we always get a value of y between 0 and b-1, inclusive).

It can be shown (try it !) that, under all those conditions, we
necessarily have: y-2 <= d <= y. That is, y is not a bad guess of d.
To make things easier:

   if y = 0 then d = 0 (and that's proven, not a mere guess)
   if y = 1 then guess d = 1
   otherwise, guess d = y-1

then subtract x*d from w and compare the result with both 0 and x
(comparison with 0 is done by looking at the carry after the
subtraction; comparison with x can be performed "inline" during the
subtraction). If subtraction result is negative, then we overestimated
d, and the actual digit is (necessarily) d-1. If subtraction result
is no less than x, then we underestimated d and the actual digit is
(necessarily) d+1. Otherwise, we got the right d. In case of bad
estimation, a further subtraction or addition of x yields the
correct remainder.


There you have it: the hardware 64-by-32 division opcode helps you
compute a division on bigger numbers. The algorithm, as explained above,
is quadratic in the size (in 32-bit words) of the operands, while the
number of elementary divisions (the "div" opcode) is only linear.

This algorithm can be further enhanced by a divided-and-conquer
approach. If the divisor has size N words, then use base "b^(N/2)".
Thus, the "guess" step will use an euclidian division of a N-word value
by an N/2-word value, and a multiplication of a N-word value by and
N/2-word value. Use the algorithm recursively for the division. With
this approach (which is not as easily implemented as the previous), you
can get a division which is asymptotically almost as efficient as
multiplication (only a factor log(N)). With sub-quadratic multiplication
algorithms (e.g. Karatsuba or FFT), this helps quite a lot for big
numbers. This is probably not worth the effort for current hardware and
numbers of moderate size (e.g. 1024-bit integers). Quite neat, though.


	--Thomas Pornin

Hugh Aguilar wrote:
> On Nov 18, 6:03=A0am, "P.M.Lawrence" <pml540...@gmail.com> wrote:
> > If you've got cheap multiplication, addition and subtraction, why not
> > just use them to generate the reciprocal and multiply by that? The
> > standard iteration for that is
> >
> > x(n+1) =3D x(n) * (2 - a * x(n)) to converge on 1/a
>
> For any integer > 1, the reciprocal rounds off to zero --- as they say
> in the mathematics department: "oops!"

Sorry, I should have spelled out that you can scale your numbers,
giving a fixed point representation, and get it to work that way. I
thought you were blocked by not having a division but that you knew a
way to go from that to what you wanted. P.M.Lawrence.

>
> Your method is actually a pretty cool way to do floating-point
> division on processors that lack an appropriate sized integer division
> for the significand, but it doesn't bring us any closer to DUM/MOD.
> I'm still faced with the bit-at-a-time method written in Forth.

In article <MfKdne9GH8mqoJjWnZ2dnUVZ8lKdnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Hugh Aguilar <hugoaguilar@rosycrew.com> wrote:
>> On Nov 18, 3:02?am, Andrew Haley <andre...@littlepinkcloud.invalid>
>> wrote:
>> > Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
>> > > Division is non-trivial because a low-precision
>> > > hardware-division can't be used to implement a higher-precision
>> > > division.
>> >
>> > Sure it can. ?It's in Knuth, Vol 2, Section 4.3.1, Algorithm D.
>
>> I don't have Knuth's books --- can you describe the algorithm?
>
>I could, but it's a fair bit of work and I'd probably make a mistake
>somewhere.
>
>There's a (rather long-winded) article at
>http://sputsoft.com/2009/08/implementing-multiple-precision-arithmetic-part-2/
>"Algorithm L" most of the way down the page looks very like Knuth's
>Algorithm D.  It's basically long division by computer, and the only
>tricky part is estimating qhat, the quotient digit.

Algo D is available in Forth, i.a. via the link below.

It is in the bignum package of tforth/ iforth. We (mhx, me and others)
needed it for a demonstration of tForth parallel processing of
factoring large numbers. I myself debugged algorithm D (after mhx kind
of gave up). It is not pretty. This demonstration can be downloaded
via the link below: transputer.html.
Unfortunately the original demo is lost, this version is sprinkled
with iforthisms: REVISION PRIVATE .HELP :ABOUT , non-standard comment
symbols (* /* DOC ,  # for decimal and (what irritates me most) the
use of =: for CONSTANT.
The use of VALUE like objects is instrumental to this package,
but it is programmed by hand, and doesn't hamper portability too
much.

I seem to remember that mhx has information about bignums on his
website, also that nowadays he favours interfacing to packages written
in C.

It is probably true that a bignum package should be written
in either assembler or for a highly optimising compiler.
The value of Forth in documenting the algorithm is null,
a version of algorithm D in assembler is probably more
understandable than the Forth version.

>
>Andrew.

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On Nov 19, 9:11=A0am, "P.M.Lawrence" <pml540...@gmail.com> wrote:
> > > x(n+1) =3D x(n) * (2 - a * x(n)) to converge on 1/a
>
> > For any integer > 1, the reciprocal rounds off to zero --- as they say
> > in the mathematics department: "oops!"
>
> Sorry, I should have spelled out that you can scale your numbers,
> giving a fixed point representation, and get it to work that way. I
> thought you were blocked by not having a division but that you knew a
> way to go from that to what you wanted. P.M.Lawrence.

If you scale up your doubles, they will be quadruples. That makes the
approximation more complicated than just doing the division. I
shouldn't have scoffed at your suggestion though, as that was rude ---
when I saw it I just assumed that you had somehow not noticed that we
are dealing with integers, as that approximation is primarily used in
floating-point arithmetic.

On the subject of floating-point, the most practical solution to the
continued-fraction problem is just to do the whole thing in floating-
point. Theoretically, this isn't portable because the FP might by
IEEE-754 single-precision, in which the significand is smaller than a
double integer. As a practical matter however, this is almost never
going to happen (FICL being an exception).

The problem is the ANS-Forth standard. Really, how obvious was the
need for double-precision arithmetic? This could have been an
extension to the language similar to floating-point. Compiler-writers
working on small microprocessors could decline to implement it if they
didn't want to.

I am frustrated with the ANS-Forth standard because I believe that the
bad design of the standard is the #1 reason for the failure of Forth
to become an important language. Forth was doing pretty well in the
1980s, but we needed a standard. What we got was Forth-83, and then
ANS-Forth-94, both of which were badly designed. With some more
thoughtful leadership we could have succeeded.

Hugh Aguilar wrote:
> On Nov 19, 9:11=A0am, "P.M.Lawrence" <pml540...@gmail.com> wrote:
> > > > x(n+1) =3D x(n) * (2 - a * x(n)) to converge on 1/a
> >
> > > For any integer > 1, the reciprocal rounds off to zero --- as they sa=
y
> > > in the mathematics department: "oops!"
> >
> > Sorry, I should have spelled out that you can scale your numbers,
> > giving a fixed point representation, and get it to work that way. I
> > thought you were blocked by not having a division but that you knew a
> > way to go from that to what you wanted. P.M.Lawrence.
>
> If you scale up your doubles, they will be quadruples. That makes the
> approximation more complicated than just doing the division.

Maybe we're still not talking about the same thing. What you describe
sounds to me like going from two storage units for double precision to
four storage units for quadruple precision. I was thinking of treating
some N as 1 so that addition and subtraction remain the same, but you
have to divide each product by N before, during or after multiplying
to maintain consistency - which is cheap if N is a power of 2 so you
can use a shift to do it.

I haven't checked if it would work, but my thinking is that you can go
from fixed point division to rounded down division by right shifting
to lose bits then left shifting to get back to the correct scale (or
just masking the rightmost bits, if you can do that). Then you can get
to DMOD from there. But it might be more trouble than it's worth
overall... P.M.Lawrence.

Hugh Aguilar wrote:
....
> The problem is the ANS-Forth standard. Really, how obvious was the
> need for double-precision arithmetic? This could have been an
> extension to the language similar to floating-point. Compiler-writers
> working on small microprocessors could decline to implement it if they
> didn't want to.
> 
> I am frustrated with the ANS-Forth standard because I believe that the
> bad design of the standard is the #1 reason for the failure of Forth
> to become an important language. Forth was doing pretty well in the
> 1980s, but we needed a standard. What we got was Forth-83, and then
> ANS-Forth-94, both of which were badly designed. With some more
> thoughtful leadership we could have succeeded.

There are D+, D-, M*, M/, and M*/ (and the unsigned operators).  These 
were adequate in a very wide variety of projects over a 30 year period, 
many of which were extremely computation-intensive and running on slow 
16-bit processors.

Forth's design is pragmatic: it has functions that have been needed and 
that have proven their usefulness *in Forth*, not necessarily those that 
have been required in other languages.  Generally speaking, Forth has 
the most flexible set of *integer* arithmetic operators of any language. 
  In particular, M*/ was one of Chuck's most brilliant innovations.  I'm 
sure if Chuck were trying to do your continued fractions that is what he 
would rely on.  Yes, that sometimes requires thinking differently, like 
many other things in Forth.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

In article <c84cba75-9523-4dc0-bf01-fe38ef4a2e3b@a31g2000yqn.googlegroups.com>,
Hugh Aguilar  <hugoaguilar@rosycrew.com> wrote:
>
>On the subject of floating-point, the most practical solution to the
>continued-fraction problem is just to do the whole thing in floating-
>point. Theoretically, this isn't portable because the FP might by
>IEEE-754 single-precision, in which the significand is smaller than a
>double integer. As a practical matter however, this is almost never
>going to happen (FICL being an exception).

Continued fractions are supposedly an alternative to floating point.
It is rare to need a larger than 16 bit number in a cf presentation.
An example would be the square root of a 32 bit prime number.

>
>The problem is the ANS-Forth standard. Really, how obvious was the
>need for double-precision arithmetic? This could have been an
>extension to the language similar to floating-point. Compiler-writers
>working on small microprocessors could decline to implement it if they
>didn't want to.

Take iforth. Marcel Hendrix didn't like missing out on operators.
So D* D/ D< D<= D>= you name it, are all available.
The ANS-Forth standard didn't prevent him from doing anything
and you could use his Forth.

>
>I am frustrated with the ANS-Forth standard because I believe that the
>bad design of the standard is the #1 reason for the failure of Forth
>to become an important language. Forth was doing pretty well in the
>1980s, but we needed a standard. What we got was Forth-83, and then
>ANS-Forth-94, both of which were badly designed. With some more
>thoughtful leadership we could have succeeded.

Well, no. Try to understand Python, then you get an idea why
some languages are becoming important at large and others don't.
Forth is relatively successful I think, and there is not a
single cause for it not being more successful.
Not having ANS-Forth-94 certainly wouldn't have helped.

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On Nov 17, 10:07=A0pm, Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
> On Nov 17, 6:56=A0pm, Coos Haak <chfo...@hccnet.nl> wrote:
>
[blablabla :) past is prologue

> The popularity of Forth plummeted around 1994, and 1994 was the year
> that the ANS-Forth standard came out. Coincidence? I don't think so.
> If a little bit more thinking had been done when ANS-Forth was
> designed, Forth might have become an important language. Instead,
> Forth became a bad joke. When I apply for work as a GCC programmer, I
> don't make any mention of my Forth experience because this is
> generally seen as a negative rather than a positive. The problem with
> excising Forth from my resume however, is that it results in a gap of
> about two years that I have no explanation for.

Hi folks; regarding Forth and its general lack of acceptance a-la
perl, python and the whole scriptable language tree, Forth's problem
can be immediately traced to the lack of what I call the scaffolding
-- that is, all the rest of the support code that is needed to make it
viable as a scripting language.  In this time of multi-gigabyte
memories, triple-digit gigabyte disks, the discussion about Forth
still about cpu cycles, memory conservation, and other such minutia
that is IMHO totally irrelevent given the abilities of the machines
that are quite low-end!!!

Please, move past these subjects and let's develope Forth into its
proper position -- up front leading instead of at the back bringing up
the rear.

Forth is unused and unknown by the general public because we the
devotee's of it haven't done anything with it to make it competitive
with Perl, Python, Ruby and the other scriptable languages. And they
can all be compiled (I think) to true binaries.

I hope you accept this in the spirit in which it is intended.

idknow <idknow@gmail.com> wrote:

> Forth is unused and unknown by the general public because we the
> devotee's of it haven't done anything with it to make it competitive
> with Perl, Python, Ruby and the other scriptable languages.

But they're *designed* for that job.  Forth is a multi-level general
purpose programming language, particularly strong in the area of
embedded applications.  You could certainly build a good language for
this application area on top of Forth, and it might well gain some
advantages from that, but it would be Language X, not Forth.

> And they can all be compiled (I think) to true binaries.

I don't understand what you mean by this.

Andrew.

Andrew Haley wrote:
> But they're *designed* for that job.  Forth is a multi-level general
> purpose programming language, particularly strong in the area of
> embedded applications.  You could certainly build a good language for
> this application area on top of Forth, and it might well gain some
> advantages from that, but it would be Language X, not Forth.

Well, maybe it would (like JavaScript compiled using Forth in Firefox 3.5), 
but not necessarily so.  Take e.g. MINOS: This contains a lot of 
"scaffolding" to allow OO style GUI programming.  Now, that wasn't what he 
asked for (he asked for scripting languages), but if I was interested in 
such scripting language scaffolding, I could do that as well.  You want 
associative arrays?  You want easy to write down regexps?  You want to 
generate HTML?  All not really difficult, all can be an extension to Forth 
like my OOF and the MINOS class library is an extension to Forth.

I usually have problems designing a scripting language because I have 
problems with that programming mindset.  I occasionally use awk+sed+bash for 
some simple scripting language tasks, but when I reach the limits of those 
tools (which are low), I rethink the problem and come to the conclusion that 
all this regexp+associative array stuff wasn't at all appropriate, and end 
up writing it in Forth using a completely different paradigm.

Example: We had a gds2txt and txt2gds C program to manipulate GDSII files 
(layout for chips).  The processing of this txt format was done by some 
scripts as above.  At one point in time I decided to dump the C program (it 
was unmaintainable, it even didn't compile with GCC on a Linux box), and 
rewrite it in Forth (it became small and maintainable, and much more 
powerful, it even can convert GDS to Postscript, and it can do manipulations 
right on the data).  After doing so, I ditched the scripts that manipulated 
the txt stream, and wrote them right on top of the Forth program that now 
directly manipulates GDS on binary level.

It is much faster, it is much more flexible, and it is a lot easier to use 
than the language-zoo scripts+C program before.  Note that "much faster" is 
not really the point here.  I don't care that if it takes 10 seconds or 10 
milliseconds to create a ROM pattern, though I find any reaction of a 
computer that's not instant "sluggish" (I do care a lot if it takes one 
hour, as it did with our first approach, using the scripting language of the 
layout editor).  I care that it now takes some minutes instead of hours to 
write a new ROM pattern generator for another ROM geometry - it goes down 
that much because a lot of conversions don't have to happen anymore, and 
some manual steps can be automated by having a way more powerful tool.

>> And they can all be compiled (I think) to true binaries.
> 
> I don't understand what you mean by this.

He probably means they can be compiled to ELF executables or so.  I haven't 
tried, but you can compile (some Forth systems) to ELF or PE executables, 
and save most to some binary representation (whether that's gforth's or 
bigforth's .fi format or something else).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

Bernd Paysan wrote:
> He probably means they can be compiled to ELF executables or so.  I
> haven't tried,

I wanted to say here "I haven't tried with Perl/Python/Ruby"

> but you can compile (some Forth systems) to ELF or PE
> executables, and save most to some binary representation (whether that's
> gforth's or bigforth's .fi format or something else).
> 

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

Op Fri, 20 Nov 2009 06:44:22 -0800 (PST) schreef idknow:

> On Nov 17, 10:07�pm, Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
>> On Nov 17, 6:56�pm, Coos Haak <chfo...@hccnet.nl> wrote:
>>
> [blablabla :) past is prologue
> 
>> The popularity of Forth plummeted around 1994, and 1994 was the year
>> that the ANS-Forth standard came out. Coincidence? I don't think so.
>> If a little bit more thinking had been done when ANS-Forth was
>> designed, Forth might have become an important language. Instead,
>> Forth became a bad joke. When I apply for work as a GCC programmer, I
>> don't make any mention of my Forth experience because this is
>> generally seen as a negative rather than a positive. The problem with
>> excising Forth from my resume however, is that it results in a gap of
>> about two years that I have no explanation for.
> 
> Hi folks; regarding Forth and its general lack of acceptance a-la
> perl, python and the whole scriptable language tree, Forth's problem
> can be immediately traced to the lack of what I call the scaffolding
> -- that is, all the rest of the support code that is needed to make it
> viable as a scripting language.  In this time of multi-gigabyte
> memories, triple-digit gigabyte disks, the discussion about Forth
> still about cpu cycles, memory conservation, and other such minutia
> that is IMHO totally irrelevent given the abilities of the machines
> that are quite low-end!!!
> 
> Please, move past these subjects and let's develope Forth into its
> proper position -- up front leading instead of at the back bringing up
> the rear.
> 
> Forth is unused and unknown by the general public because we the
> devotee's of it haven't done anything with it to make it competitive
> with Perl, Python, Ruby and the other scriptable languages. And they
> can all be compiled (I think) to true binaries.
> 
> I hope you accept this in the spirit in which it is intended.

I didn't write anything of the above. Please quote properly.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html

idknow wrote:
....
> Hi folks; regarding Forth and its general lack of acceptance a-la
> perl, python and the whole scriptable language tree, Forth's problem
> can be immediately traced to the lack of what I call the scaffolding
> -- that is, all the rest of the support code that is needed to make it
> viable as a scripting language.  In this time of multi-gigabyte
> memories, triple-digit gigabyte disks, the discussion about Forth
> still about cpu cycles, memory conservation, and other such minutia
> that is IMHO totally irrelevent given the abilities of the machines
> that are quite low-end!!!
> 
> Please, move past these subjects and let's develope Forth into its
> proper position -- up front leading instead of at the back bringing up
> the rear.
> 
> Forth is unused and unknown by the general public because we the
> devotee's of it haven't done anything with it to make it competitive
> with Perl, Python, Ruby and the other scriptable languages. And they
> can all be compiled (I think) to true binaries.
> 
> I hope you accept this in the spirit in which it is intended.

The major reason Forth hasn't been accepted is lack of marketing, either 
in the form of adoption by major companies or organizations or papers in 
various publications, meetings, etc.  The vast majority of programmers 
out there haven't considered Forth and rejected it for some reason 
(although some have heard -- and passed on -- rumors about 
unreadability, etc.), they simply never heard of it.

As for "cpu cycles, memory conservation, and other such minutia" these 
issues remain vitally important in the area of embedded systems, which 
is vast and thriving, and where folks developing products are desperate 
to wring maximum functionality and performance out of the cheapest 
possible hardware.  That is the main area where Forth excels.

And modern versions of Forth certainly compile binaries.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

Elizabeth D Rather schrieb:

> The major reason Forth hasn't been accepted is lack of marketing, either
> in the form of adoption by major companies or organizations or papers in
> various publications, meetings, etc.  The vast majority of programmers
> out there haven't considered Forth and rejected it for some reason
> (although some have heard -- and passed on -- rumors about
> unreadability, etc.), they simply never heard of it.

In that case we have to ask "why".
What do other languages have, that Forth has not?

My impression is, that for many popular uses where other languages offer
capabilities, Forth offers just possibilities.

This is perhaps due to the primary target the laguages were developed
for. I understand that Forth was first designed to control hardware.
That is still it's main playground (OpenBoot) in terms of installations.

Perl, for example, was designed to process (textual) reports.
That is still it's main feature but it's also the reason why it is so
widespread because this capability has uses in many areas.

As far as scripting for applications is concerned, in my personal
experience Forth is rejected because of two reasons:

1. "We don't need all that!"
 - instead of integrating Forth an then implementing the
applicationspecific functions in Forth, a rudimentary scripting is
implemented directly.

2. "It's not safe!"
 - the 'run of the mill' Forth is not crash proof.
At least that is what people who decide things know about Forth.

In more than 25 years I was just once able to sneak in a Forth like
scripting facility. And that only because I didn't tell them in advance
that it was in fact Forth.

Uwe

Uwe Klo=DF <uwe.kloss@gmx.de> wrote:
> Elizabeth D Rather schrieb:
>=20
> > The major reason Forth hasn't been accepted is lack of marketing,
> > either in the form of adoption by major companies or organizations
> > or papers in various publications, meetings, etc.  The vast majority
> > of programmers out there haven't considered Forth and rejected it
> > for some reason(although some have heard -- and passed on -- rumors
> > about unreadability, etc.), they simply never heard of it.
>=20
> In that case we have to ask "why".
> What do other languages have, that Forth has not?

> As far as scripting for applications is concerned, in my personal
> experience Forth is rejected because of two reasons:
>=20
> 1. "We don't need all that!"
>  - instead of integrating Forth an then implementing the
> applicationspecific functions in Forth, a rudimentary scripting is
> implemented directly.
>=20
> 2. "It's not safe!"
>  - the 'run of the mill' Forth is not crash proof.
> At least that is what people who decide things know about Forth.
>=20
> In more than 25 years I was just once able to sneak in a Forth like
> scripting facility. And that only because I didn't tell them in
> advance that it was in fact Forth.

I want a scripting language to be easy to use. I just want to solve some
simple problems without the language getting in the way.

Particularly I want a scripting language when I want to write something
quick that I'll use once. I hope I'll know a right answer when I see it,
because I'm probably not going to do enough testing to make sure there
are no bugs. I just want to sit down and get my result and move on. I
hesitate to admit this; it sounds bad. But I expect it's true for most
people who write simple scripts that they intend to use once.

I personally found regexp to be almost useless for this sort of thing.
I'd try it, and inevitably make a mistake. So I'd fix the mistake and
then find a second mistake. After four or five tries I could get
something that looked like it was doing what I wanted, but of course
there might be hidden bugs somewhere. For something I wanted to use once
it took too many tries, and for something I wanted to re-use there were
too many possible errors to bite me later.

Of course if I took the time to sit down and really learn regexps then I
could use it effectively. I'd have to learn the details of precisely how
my particular scripting language did it, knowing that it would be
different in detail for a different scripting language. But I want a
scripting language to be easy to use, to not get in my way. I don't want
to sit down and learn all the details of an arcane process that has a
lot of traps for the unwary.

Well, if I have a scripting language that's mostly Forth, it's going to
be based heavily around a data stack. You get stuff from the stack and
leave stuff on the stack and your operations are concatenative -- each
one can just use the output from the last one without much fuss. If it
doesn't have that then it isn't Forth, it's at best a scripting language
written in Forth.

So just like I don't want to learn regexp, how many scripting language
users will want to learn how to use the data stack?

idknow <idknow@gmail.com> writes:
>Hi folks; regarding Forth and its general lack of acceptance a-la
>perl, python and the whole scriptable language tree, Forth's problem
>can be immediately traced to the lack of what I call the scaffolding
>-- that is, all the rest of the support code that is needed to make it
>viable as a scripting language.

Such as what?

>Forth is unused and unknown by the general public because we the
>devotee's of it haven't done anything with it to make it competitive
>with Perl, Python, Ruby and the other scriptable languages. And they
>can all be compiled (I think) to true binaries.

If it was important, you would not just think, you would know.

Compiling programs written in these languages to binary executables is
a very uncommon thing, and while there may be some fringe
implementations of these languages that can do it, AFAIK the dominant
implementations cannot.  One of the properties of a scripting language
is that the dominant way of running a program is from source code.

In contrast, there are a number of Forth implementations that can
generate binary executables.  Will that help Forth to make inroads as
a scripting language?  No, because that's not an important property of
a scripting language.

What is useful for a scripting language?  One thing is a convenient OS
command-line interface.  E.g., if the Forth system has a limited and
changeable dictionary size, then that should be settable on the
command line.

- 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.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

Thomas Pornin <pornin@bolet.org> wrote:
> According to Hugh Aguilar  <hugoaguilar@rosycrew.com>:
> > I don't have Knuth's books --- can you describe the algorithm?

> The "one bit at a time" algorithm is just a special case of the
> "manual division" that kids learn at school. Basically:

....

> There you have it: the hardware 64-by-32 division opcode helps you
> compute a division on bigger numbers.

Very nice; most descriptions of this algorithm are much harder to
follow.  I'm amazed you have the time, but thanks!

Andrew.

Jonah Thomas schrieb:
> So just like I don't want to learn regexp, how many scripting language
> users will want to learn how to use the data stack?

Next to none!
That's why you hide it.
At first.
At least that's what I did.

The 'laguage' I wrote had a very small vocabulary with runtime checks
like the Forth control structures (?PAIRS) and everything else was hidden.

The interesting thing was, my coworkers, all of them electrical
engineers, once they observed me extending the vocabulary, requested
that I remove the lock on the core system.

Asked if they really wanted to bother with the "stack crap" they
answered that if they could program complete test sessions and control
them from their office PC they'd bother with that and a lot more.

Until then they had to sit out their test sessions in the (chilly) lab
and push switches.

Uwe

P.S.: Evaluation of log files was done in perl.
      With regexps!
And by electrical engineers that had to lern perl just for that task.

On Nov 20, 12:07=A0am, Elizabeth D Rather <erat...@forth.com> wrote:
> There are D+, D-, M*, M/, and M*/ (and the unsigned operators). =A0These
> were adequate in a very wide variety of projects over a 30 year period,
> many of which were extremely computation-intensive and running on slow
> 16-bit processors.
>
> Forth's design is pragmatic: it has functions that have been needed and
> that have proven their usefulness *in Forth*, not necessarily those that
> have been required in other languages. =A0Generally speaking, Forth has
> the most flexible set of *integer* arithmetic operators of any language.
> =A0 In particular, M*/ was one of Chuck's most brilliant innovations. =A0=
I'm
> sure if Chuck were trying to do your continued fractions that is what he
> would rely on. =A0Yes, that sometimes requires thinking differently, like
> many other things in Forth.

Telling me that I need to start "thinking differently" is offensive.
Differently than what? It is very ironic that you should imply that I
am a C programmer because I mentioned that C has a LONG INT data type,
but the C programmers won't hire me because they think I am a Forth
programmer because I wrote a Forth compiler. Which is it? Am I a bad
Forth programmer, or a bad C programmer?

Mixed-precision arithmetic is certainly cool, but that doesn't change
the fact that double-precision arithmetic is occasionally needed. It
seems unlikely that Chuck Moore intended that Forth programmers
should be prevented from using any double-precision arithmetic beyond D
+ for ever and ever. Most likely, he failed to provide DUM/MOD for the
simple reason that whatever program he was writing at the time didn't
require it. It was not his intention, way back in the 1970s, that
Elizabeth Rather would be standing firm in opposition to DUM/MOD in
the year 2009.

I was in elementary school in the 1970s. How likely is it that Chuck
Moore was plotting to defeat me in my future efforts to use double-
precision arithmetic? That is actually somewhat humorous. I can
imagine Chuck Moore standing outside of the playground and telling
Elizabeth Rather: "See that little boy playing in there? I'm going to
put a curse on him so that he will never be able to use double-
precision arithmetic for all of his days. Brwaa-ha-ha! ANS-Forth! ANS-
Forth!"

Non-technical people have too much faith in the past. They believe
that any modification to what worked in the past is more likely to be
a step backward than forward, and therefore limitations are necessary
to prevent humanity from descending into chaos. Non-technical people
tend to be ignorant, superstitious and fearful --- that is why I don't
generally try to communicate with them.

I stand by what I said before. Forth fizzled because the ANS-Forth
standard was too limiting. The ANS-Forth committee was dominated by
non-technical marketing-department people who wanted to limit Forth to
what their existing compiler could do, in order to make their compiler
immediately salable as a standard system. There was no consideration
given to the possibility of future progress ever being made.

Op Sat, 21 Nov 2009 18:33:09 -0800 (PST) schreef Hugh Aguilar:

<snip>
 
> I stand by what I said before. Forth fizzled because the ANS-Forth
> standard was too limiting. The ANS-Forth committee was dominated by
> non-technical marketing-department people who wanted to limit Forth to
> what their existing compiler could do, in order to make their compiler
> immediately salable as a standard system. There was no consideration
> given to the possibility of future progress ever being made.

Allright then, stop whining, or buy a 64 bit machine.

code dum/mod    ( uq ud1 -- ud2 ud3 )
                mov     cl, # 16
                shl     ebx, cl
                pop     bx
                pop     edx
                rol     edx, cl
                pop     eax
                rol     eax, cl
                div     ebx
                rol     edx, cl
                push    edx
                push    ax
                shld    ebx, eax
                next
end-code

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html

On Nov 19, 8:52=A0pm, "P.M.Lawrence" <pml540...@gmail.com> wrote:
> Maybe we're still not talking about the same thing. What you describe
> sounds to me like going from two storage units for double precision to
> four storage units for quadruple precision. I was thinking of treating
> some N as 1 so that addition and subtraction remain the same, but you
> have to divide each product by N before, during or after multiplying
> to maintain consistency - which is cheap if N is a power of 2 so you
> can use a shift to do it.

On a 32-bit system, you could use 2^32 as unity (what you call N in
the post above). All that you would accomplish by doing this would be
to invent UM/MOD. We already have UM/MOD however.
Our goal is to invent:  DUM/MOD ( uq ud -- ud-rem ud-quot )

Actually, the dividend could be a double rather than a quadruple, but
there is no difference in speed with the bit-at-a-time method, so
allowing for a quadruple dividend makes for a more robust solution.

Uwe Klo� wrote:
> Elizabeth D Rather schrieb:
> 
>> The major reason Forth hasn't been accepted is lack of marketing, either
>> in the form of adoption by major companies or organizations or papers in
>> various publications, meetings, etc.  The vast majority of programmers
>> out there haven't considered Forth and rejected it for some reason
>> (although some have heard -- and passed on -- rumors about
>> unreadability, etc.), they simply never heard of it.
> 
> In that case we have to ask "why".
> What do other languages have, that Forth has not?

An organization behind them that is either large, well-funded, or both.

> My impression is, that for many popular uses where other languages offer
> capabilities, Forth offers just possibilities.
> 
> This is perhaps due to the primary target the laguages were developed
> for. I understand that Forth was first designed to control hardware.
> That is still it's main playground (OpenBoot) in terms of installations.

Yes, it is much easier for a language targeted at a particular 
application domain to be tailored for that domain.  Forth is very 
general; Forth programmers tailor it to the domain they're working in.

>...
> As far as scripting for applications is concerned, in my personal
> experience Forth is rejected because of two reasons:
> 
> 1. "We don't need all that!"
>  - instead of integrating Forth an then implementing the
> applicationspecific functions in Forth, a rudimentary scripting is
> implemented directly.

Gee, just above you were saying Forth offers too little; now you seem to 
be saying it has too much.

> 2. "It's not safe!"
>  - the 'run of the mill' Forth is not crash proof.
> At least that is what people who decide things know about Forth.

Yeah, that's one of the rumors, along with "unreadable".  The Forths I 
know are quite stable.  It's possible to write crashing programs in 
every language.  But the extreme modularity and high code-reuse in Forth 
makes it possible to make extremely reliable programs.

> In more than 25 years I was just once able to sneak in a Forth like
> scripting facility. And that only because I didn't tell them in advance
> that it was in fact Forth.

Unfortunately, that's all too common.

Cheers,
Elizabeth


-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

Hugh Aguilar wrote:
> On Nov 20, 12:07 am, Elizabeth D Rather <erat...@forth.com> wrote:
>> There are D+, D-, M*, M/, and M*/ (and the unsigned operators).  These
>> were adequate in a very wide variety of projects over a 30 year period,
>> many of which were extremely computation-intensive and running on slow
>> 16-bit processors.
>>
>> Forth's design is pragmatic: it has functions that have been needed and
>> that have proven their usefulness *in Forth*, not necessarily those that
>> have been required in other languages.  Generally speaking, Forth has
>> the most flexible set of *integer* arithmetic operators of any language.
>>   In particular, M*/ was one of Chuck's most brilliant innovations.  I'm
>> sure if Chuck were trying to do your continued fractions that is what he
>> would rely on.  Yes, that sometimes requires thinking differently, like
>> many other things in Forth.
> 
> Telling me that I need to start "thinking differently" is offensive.

I'm sorry, I intended no offense.

> Differently than what? 

Making effective use of words like M*/ (which no other languages have, 
to my knowledge) requires thinking about algorithms differently than the 
ways they're commonly described.

> It is very ironic that you should imply that I
> am a C programmer because I mentioned that C has a LONG INT data type,
> but the C programmers won't hire me because they think I am a Forth
> programmer because I wrote a Forth compiler. Which is it? Am I a bad
> Forth programmer, or a bad C programmer?

I don't have any opinion about your programming capability, because I've 
never seen your code.

> Mixed-precision arithmetic is certainly cool, but that doesn't change
> the fact that double-precision arithmetic is occasionally needed. It
> seems unlikely that Chuck Moore intended that Forth programmers
> should be prevented from using any double-precision arithmetic beyond D
> + for ever and ever. Most likely, he failed to provide DUM/MOD for the
> simple reason that whatever program he was writing at the time didn't
> require it. It was not his intention, way back in the 1970s, that
> Elizabeth Rather would be standing firm in opposition to DUM/MOD in
> the year 2009.

In the "good old days" we had only 16-bit platforms.  We were commonly 
doing math which required 32-bit precision.  That's the environment in 
which the few double and many mixed precision operators were developed. 
  The charm of M*/ is that it has a triple-precision intermediate 
product, so you get a precise, scaled double result.  DUM/MOD implies a 
quad-precision dividend; that simply hasn't been required in my 
experience, and I'd be surprised if it is here.

> I was in elementary school in the 1970s. How likely is it that Chuck
> Moore was plotting to defeat me in my future efforts to use double-
> precision arithmetic? That is actually somewhat humorous. I can
> imagine Chuck Moore standing outside of the playground and telling
> Elizabeth Rather: "See that little boy playing in there? I'm going to
> put a curse on him so that he will never be able to use double-
> precision arithmetic for all of his days. Brwaa-ha-ha! ANS-Forth! ANS-
> Forth!"

Nobody is prevented from doing anything in Forth, ANS or not.

> Non-technical people have too much faith in the past. They believe
> that any modification to what worked in the past is more likely to be
> a step backward than forward, and therefore limitations are necessary
> to prevent humanity from descending into chaos. Non-technical people
> tend to be ignorant, superstitious and fearful --- that is why I don't
> generally try to communicate with them.

I think if you did communicate with more non-technical people you might 
be surprised.  They obviously don't know much about technical subjects, 
but, then, you may not know much about the things they're experts in.  A 
lot of them are quite intelligent and well-informed.

> I stand by what I said before. Forth fizzled because the ANS-Forth
> standard was too limiting. The ANS-Forth committee was dominated by
> non-technical marketing-department people who wanted to limit Forth to
> what their existing compiler could do, in order to make their compiler
> immediately salable as a standard system. There was no consideration
> given to the possibility of future progress ever being made.

In fact, there were *no* "non-technical marketing-department people" on 
the ANS Forth TC.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

Elizabeth D Rather schrieb:
> Uwe Klo� wrote:

>> As far as scripting for applications is concerned, in my personal
>> experience Forth is rejected because of two reasons:
>>
>> 1. "We don't need all that!"
>>  - instead of integrating Forth an then implementing the
>> applicationspecific functions in Forth, a rudimentary scripting is
>> implemented directly.
> 
> Gee, just above you were saying Forth offers too little; now you seem to
> be saying it has too much.

Uhps!
May be I said that, but I _meant_ to say that 'they' said that. ;-)

Uwe

Uwe Klo� wrote:
> Elizabeth D Rather schrieb:
>> Uwe Klo� wrote:
> 
>>> As far as scripting for applications is concerned, in my personal
>>> experience Forth is rejected because of two reasons:
>>>
>>> 1. "We don't need all that!"
>>>  - instead of integrating Forth an then implementing the
>>> applicationspecific functions in Forth, a rudimentary scripting is
>>> implemented directly.
>> Gee, just above you were saying Forth offers too little; now you seem to
>> be saying it has too much.
> 
> Uhps!
> May be I said that, but I _meant_ to say that 'they' said that. ;-)

What is the actual footprint of a typical Forth vs. other scripting 
languages?

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

Elizabeth D Rather schrieb:
> Uwe Klo� wrote:
>> Elizabeth D Rather schrieb:
>>> Uwe Klo� wrote:
>>
>>>> As far as scripting for applications is concerned, in my personal
>>>> experience Forth is rejected because of two reasons:
>>>>
>>>> 1. "We don't need all that!"
>>>>  - instead of integrating Forth an then implementing the
>>>> applicationspecific functions in Forth, a rudimentary scripting is
>>>> implemented directly.
>>> Gee, just above you were saying Forth offers too little; now you seem to
>>> be saying it has too much.
>>
>> Uhps!
>> May be I said that, but I _meant_ to say that 'they' said that. ;-)
> 
> What is the actual footprint of a typical Forth vs. other scripting
> languages?
I don't think the project manager who rejected my proposal was aware of
that. He just wanted some configuration data read in in the first place.

When he heared me say "... full fledged interpreter ..." he probably saw
many work hour flashing in front of his eyes and felt the deadline
around his throat and the discussion was finished. X-(
You learn to be sneaky fast that way. ;-)

They didn't recognize the benefits of a more powerfull scripting
language until it was demonstrated. As I wrote in an other post, they
used to sit with their 19" racks an press buttons.
After implementing the scripting facilities the test systems ran 24/7
and the test results were collected during normal work hours from the
office.

AFAIK they still use that library or a modified version of it in their
HW controll apps in the lab.

Uwe

Elizabeth D Rather <erather@forth.com> writes:
>Uwe Klo� wrote:
>> What do other languages have, that Forth has not?
>
>An organization behind them that is either large, well-funded, or both.

I very much doubt that this is the decisive factor.  Ok, it made Java
widely known quickly, but that's rather the exception.  I am not aware
of particular organizational support for Python, Ruby, or Perl (just
to name a very few popular languages mentioned in this thread).

And if the size and funds of the supporting organization were the
decisive factor, everyone would program in Ada.  Yet, looking at the
popularity in Usenet, Ada is usually about as popular as Forth.

A good way to become popular is to have a killer application, or at
least a good demo and some marketing based on that.  For Java there
was HotJava and the write-once-run-everywhere propaganda (selling it
as the "Internet language").  For Ruby there is Ruby-on-Rails, for PHP
there is server-side web scripting, for Perl there were reports and
scripts for the sh/awk-illiterate.  I'm not sure how Python became
popular, mostly I saw it mentioned as a saner alternative to Perl.

>It's possible to write crashing programs in 
>every language.

Depends on what you consider to be a crash.  Certain kinds of crashes
don't happen in higher-level languages.  But does that make them
better to program?  E.g., in Prolog I don't get crashes from storing
at an arbitrary place in memory.  But when I make a mistake, the
typical symptom is that I run the program and it answers my query with
"no".  Very informative:-(.

- 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.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

On Sat, 21 Nov 2009 20:40:48 +1000, Uwe Klo� <uwe.kloss@gmx.de> wrote:

> Elizabeth D Rather schrieb:
>
>> The major reason Forth hasn't been accepted is lack of marketing, either
>> in the form of adoption by major companies or organizations or papers in
>> various publications, meetings, etc.  The vast majority of programmers
>> out there haven't considered Forth and rejected it for some reason
>> (although some have heard -- and passed on -- rumors about
>> unreadability, etc.), they simply never heard of it.

Even with money, it is hard to market unless you can occupy a development  
sector (wide) and provide tools up to visual software and data editing  
modeling development environments+ script etc.  You also need to make it  
easier (scripting as you are talking about, crosses over into language  
changes).  I have considered these things for a while, and I imagine  
Elisabeth thinks about them a bit as well, considering where she works.   
In my own scheme, the only people that need to know machine code  
programming, are OS, driver, object and custom api writers, applications  
programmers use objects with little code to control objects, custom code  
and application development systems, next up is content providers with  
scripting (using objects etc) and then authoring packages).  All having  
available visual environments.  What I concluded is that most of the  
processing is done in the objects, api, drivers and OS, so need the most  
refinement (a couple of levels there) and their behavior limits the  
efficiency of all upper levels.   Depending on application, much less  
processing will be done on the application level.  Less processing again  
is used on scripting level, but most people can write a script to waste  
time.  With the authoring package you are simply using the efficiently  
made code before, so these authors need only know what they are doing, but  
not even how to program.  The proceeding layers ensure maximum efficiency  
for the authors, as for the programmers on each proceeding level.  If you  
write the lower levels right and make the objects well, you get rid of a  
lot of bugs, raise efficiency and reduce the amount of work upper levels  
do.  There is one more secret ingredient involved, I'll leave you too it.

Of course it is not as simple as this, you would need suitable management,  
I came up with a system years ago that could be classified as a type of  
extreme programming to ensure efficiency, reliability and quality before  
test stage.  By being lazy, arrogant ("don't need" to do it properly or  
listen) it is doomed to the quality failures, as with many other  
projects.  Design is a root of all efficiency, analysis and ability are  
roots of design.

  (Wayne here)

On Nov 21, 7:45=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
>
> What is useful for a scripting language? =A0One thing is a convenient OS
> command-line interface. =A0E.g., if the Forth system has a limited and
> changeable dictionary size, then that should be settable on the
> command line.
>
> - anton

That is an interesting question. I am unusual in not having needed to
do scripting type tasks (heavy regex, text file processing, tool
integration, etc.), so I haven't learned perl, ruby, and have only a
smattering of Python. For some Web-based toys, I learned enough
JavaScript to be dangerous.

For the last few personal text-whacking tasks, I *did* reach for Forth
after trying to learn AWK and regex, and I managed to get the job done
without much effort.  The Forth string wordset is pretty much on par
with the <string.h> C standard library, plus/minus a few things.  I
find the addr-len abstraction to be a pretty convenient and efficient
means to reference substrings in large text, compared to the null-
termination requirement for handling C-strings, which often requires
an unnecessary string copy. Another convenience is using the
dictionary space (or PAD) as a large anonymous text buffer for lines
or entire files.

One of the factors I kept reinventing for text processing tasks was
the SPLIT word (either by character, string, or "match" predicate).

A big area which helps modern scripting languages succeed is their
library integration. Perl has its module system and CPAN. Python has
"batteries included". Shell scripting has the rich UNIX toolset and
pipes to plug them together.  Forth would need a similar library
system to really succeed as a scripting language. This is partially a
technical problem but mostly a social problem.

Ian

Anton Ertl wrote:
> Elizabeth D Rather <erather@forth.com> writes:
>> Uwe Klo� wrote:
>>> What do other languages have, that Forth has not?
>> An organization behind them that is either large, well-funded, or both.
> 
> I very much doubt that this is the decisive factor.  Ok, it made Java
> widely known quickly, but that's rather the exception.  I am not aware
> of particular organizational support for Python, Ruby, or Perl (just
> to name a very few popular languages mentioned in this thread).

Python: Originally developed at CWI (National Research Institute for 
Mathematics and Computer Science) in the Netherlands by Guido van 
Rossum.  This seems similar to Chuck Moore's early work on Forth at 
NRAO, with the difference that CWI actively encouraged publication and 
work on it, since its interests included computer science.  NRAO 
regarded Forth as a distraction, and actively discouraged its promotion. 
  Van Rossum subsequently moved to Corporation for National Research 
Initiatives (CNRI) in Reston, VA, which continued to support his work. 
Chuck became frustrated with NRAO, and he and I formed FORTH, Inc., 
where we struggled with no corporate backing whatever, only what we 
could earn with various programming projects.

Perl: Larry Wall began work on Perl in 1987, while working as a 
programmer at Unisys, which (like CWI) supported his work and 
publications.  Any paper on a language or similar development from an 
organization like Unisys (which at the time was well-known and highly 
respected in the computer industry) will inevitably get more respect 
than a paper from a microscopic company no one ever heard of (e.g. 
FORTH, Inc.).

Ruby: It's history is interesting, because it is more of an individual 
effort without institutional backing in the early days.  Matsumoto based 
his work (in the 1990's) on existing popular languages (Perl, Smalltalk, 
Eiffel, Ada, and Lisp), and was able to capitalize on both their 
popularity & familiarity as well as the Internet (Japanese newsgroups). 
  Here the contrast is that Forth was a *departure* from familiar and 
popular programming paradigms.  Instead of the Internet, Forth promotion 
in the 80's relied on print publications such as Byte and Dr. Dobbs, 
which editorially butchered programming examples, thus feeding the 
perception of unreadability.

> And if the size and funds of the supporting organization were the
> decisive factor, everyone would program in Ada.  Yet, looking at the
> popularity in Usenet, Ada is usually about as popular as Forth.

It quickly became the perception that Ada projects required budgets of 
$1M+, which tends to put a damper on acceptance!

> A good way to become popular is to have a killer application, or at
> least a good demo and some marketing based on that.  For Java there
> was HotJava and the write-once-run-everywhere propaganda (selling it
> as the "Internet language").   For Ruby there is Ruby-on-Rails, for PHP
> there is server-side web scripting, for Perl there were reports and
> scripts for the sh/awk-illiterate.  I'm not sure how Python became
> popular, mostly I saw it mentioned as a saner alternative to Perl.

Yes, focusing on a specific application domain is very helpful, as I 
said.  It enables you to focus the capabilities of your language, as 
well as its promotion.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

Ian Osgood wrote:
> One of the factors I kept reinventing for text processing tasks was
> the SPLIT word (either by character, string, or "match" predicate).

Here are my latest experiments...I don't know if this is of any interest
or use to anyone, but I've just been messing with it, so I feel like
discussing it. :)

I'm using matching words which return both the remainder of the text
(starting with the match) and the length of the match.  Then I use the
following SPLIT and do roughly `2dup find-match split`.

	: split  over >r  over min /string   2swap r> - ;

Here's an an example.  This requires a system (e.g. gforth) on which
`S"` has more than one buffer.  Note also that uncommenting the
parenthesized code in `1st-match` will give the other match-not-found
behavior (which I suspect is generally more useful).

	: 1st-match ( c-addr1 u1 c-addr2 u2 -- c-addr3 u3 u4 )
		dup >r search ( tuck and swap ) r> and ;

	: quote ( c-addr u -- )  [char] " dup >r emit type r> emit space ;

	s" 12345,67890,54321"
		2dup s" ," 1st-match split  quote
		2dup s" ," 1st-match split  quote
		2dup s" ," 1st-match split  quote
		quote

I haven't done much with it, but it seems reasonable so far...

As for the classic skip/scan/etc., I'm currently using this code (not
the most efficient, but avoids code duplication).

	: (skip) ( c-addr u x xt -- c-addr' u' )
		2>r begin dup while
			over c@ 2r@ execute while 1 /string
		repeat then 2rdrop ;

	: skip ( c-addr u char -- c-addr' u' )  ['] = (skip) ;
	: scan ( c-addr u char -- c-addr' u' )  ['] <> (skip) ;

	: execute-0= execute 0= ;
	: skip-with ( c-addr u xt -- c-addr' u' )  ['] execute (skip) ;
	: scan-with ( c-addr u xt -- c-addr' u' )  ['] execute-0= (skip) ;

--Josh

On Nov 21, 9:24 pm, Elizabeth D Rather <erat...@forth.com> wrote:
> I'm sorry, I intended no offense.
>
> > Differently than what?
>
> Making effective use of words like M*/ (which no other languages have,
> to my knowledge) requires thinking about algorithms differently than the
> ways they're commonly described.

I overreacted as I took your comment to mean that you don't think I
know how to use mixed-precision arithmetic. I apologize for being
sensitive on the subject.

> I don't have any opinion about your programming capability, because I've
> never seen your code.

Here is an example of some Forth code that I wrote that uses mixed-
precision arithmetic. This code does encryption using the linear-
congruential method. Also included is a function that cracks the
encryption program. It works on the assumption that the original
plaintext file was 7-bit ascii (every byte's high-bit is known to be
zero).

http://www.rosycrew.com/LC53.4th        ANS-Forth version
http://www.rosycrew.com/LC53.factor     Factor version
http://www.rosycrew.com/test.txt        plaintext test file

The speed on my laptop for cracking the test file is as follows:

assembly-language     17 seconds
SwiftForth            22 seconds
Factor      9 minutes 14 seconds

I no longer provide the assembly-language version on the website
because it was confusing people. The assembly and Forth were
intermixed (with [IF] directives) and people thought that the Forth
version relied on assembly-language, which it didn't. I can provide
the assembly-language version if anybody cares. It is SwiftForth
specific.

Note that Slava has told me that he is going to upgrade Factor in the
future to better handle integer arithmetic, with the goal of getting
LC53 close to or better than SwiftForth. In the meantime though, he
wrote a version of LC53 that ran in 11 minutes 14 seconds, which was
worse than the one that I wrote. Some other people have ported my LC53
over to Haskell and Clojure. The Haskell program ran in 17 minutes 28
seconds, but on a different machine, so I don't know how that compares
exactly. I don't have a time yet for the Clojure version on any
machine. I am working on an Erlang version that takes advantage of
concurrent execution on parallel processors, but I don't have that
available yet. It should hopefully beat SwiftForth, as SwiftForth
lacks concurrency. I have heard of Forth-Linda but never tried it,
although that might be similar to Erlang.

> In fact, there were *no* "non-technical marketing-department people" on
> the ANS Forth TC.

Whose idea was it for LOCALS| to declare the names backwards? That
looks like the work of non-technical people to me. How about the
haphazard mixture of words that work with counted strings (such as C")
and words that work with an adr/count pair (such as S")? This is
obviously an effort to be compatible with *every* existing Forth
system, despite the fact that they are all incompatible with each
other. The ANS-Forth standard appears to have been designed without
the help of *any* technical people.

The biggest problem with ANS-Forth is the CREATE DOES> construct.
There can only be *one* action associated with the data type. That is
a ridiculous limitation. Note that ANS-Forth came out at a time when C+
+, Objective C and Object Pascal were gaining popularity. These
languages allow multiple methods to be associated with each data type.
For the ANS-Forth to adhere to a 1970s hack such as CREATE DOES> was
just absurd. Now you claim that it was lack of marketing that brought
down ANS-Forth. No it wasn't. Not even Zig Ziglar could have sold
programmers on CREATE DOES> --- you have to have a standard that makes
sense in order for technical people to adopt it.

I have ANS-Forth software available that demonstrates how code
generated by defining words that I wrote myself is an order of
magnitude faster (on SwiftForth) than code generated by CREATE DOES>,
and less than half the size. All in all, CREATE DOES> was a grotesque
blunder. Never mind the lack of double-precision arithmetic in ANS-
Forth --- CREATE DOES> alone would have been enough to kill ANS-Forth
as a serious language. ANS-Forth came out in 1994, and it presented a
crufty throwback to software technology of 20 years previous. If you
had ejected CREATE DOES> and introduced :NAME in 1983, Forth would
have succeeded, and it still wasn't too late in 1994. By now (2009)
all of the old legacy code would have been rewritten to use :NAME and
the CREATE DOES> fiasco would have long since died an unlamented death
--- it would just be a vaguely disturbing memory from the bad old days
--- instead, we now have so much legacy code using CREATE DOES> that
we can't get rid of it.

On Nov 21, 8:50=A0am, Jonah Thomas <jethom...@gmail.com> wrote:
> Particularly I want a scripting language when I want to write something
> quick that I'll use once. I hope I'll know a right answer when I see it,
> because I'm probably not going to do enough testing to make sure there
> are no bugs. I just want to sit down and get my result and move on. I
> hesitate to admit this; it sounds bad. But I expect it's true for most
> people who write simple scripts that they intend to use once.

For simple, throw-away scripts, yes, testing tends to be less
rigorous.  Of course, often such simple scripts exist to answer simple
questions, and the correctness of the script is (usually) obvious.
For me, the process of creating simple scripts is just as iterative as
when I'm using Forth.  A script usually starts by parsing some input,
and so the first iteration is to write a parser (usually based on the
language's built-in string splitting or regular expressions) and
output what I parsed to the screen.  Once I've verified the
correctness of that parsing, I then move to processing which is often
just grouping data together or simple math.  That usually doesn't
require much if any testing, but when I'm unsure, it's simple to drop
in some "print" statements and verify that the processing is doing
what I want.  And finally, I need to output something, and that's
often just iterating over a table and outputting previous
calculations.

Normally, each iteration is written and incrementally tested by
editing a file and then invoking it with the scripting language's
interpreter.  But most every scripting language these days offers one
the ability to interactively write and execute code (just like in
Forth).  In some cases, this is provided by the language itself.
Other times, you can drop into a debugger which is usually just a
fancy "read eval print" loop that happens to have some added
functionality.  And in the rare case when this isn't available, one
can craft their own "read eval print" loop and turn a non-interactive
language into an interactive one.

I should also mention here that many times more complicated scripts
are really just concatenations of simpler scripts.  Sound familiar?
The Unix pipe notion has strong parallels to the idea in Forth that
you can compose more complicated words by the concatenation of them.

> I personally found regexp to be almost useless for this sort of thing.
> I'd try it, and inevitably make a mistake. So I'd fix the mistake and
> then find a second mistake. After four or five tries I could get
> something that looked like it was doing what I wanted, but of course
> there might be hidden bugs somewhere. For something I wanted to use once
> it took too many tries, and for something I wanted to re-use there were
> too many possible errors to bite me later.

The problem may be that you're trying to do too much with regular
expressions.  They aren't useful for all problems, and depending on
the input you're matching on, it may not even be possible.  For
example, most classic regular expression libraries can't match on
balanced symbols (like parenthesis or brackets) which means that if
you wanted to write a regular expression to parse "(1+(2*3))" you're
out of luck and should use other parsing methods.  Another issue that
is classic regular expressions are "greedy" so matching on shortest-
possible patterns may be impossible or require more explicit (and
thus, more brittle) patterns.

Another problem may be that you're using a too-powerful bells-and-
whistles regular expression library (such as the one that comes with
Perl) that gives you (seemingly) endless different exotic options.
The desire to come up with a single pattern to match what you want is
fine, but in my experience, you can get results faster by using a
simpler regular expression to first transform your input into
something simpler, and then in subsequent regular expressions be able
to use that simplified input.

> Of course if I took the time to sit down and really learn regexps then I
> could use it effectively. I'd have to learn the details of precisely how
> my particular scripting language did it, knowing that it would be
> different in detail for a different scripting language. But I want a
> scripting language to be easy to use, to not get in my way. I don't want
> to sit down and learn all the details of an arcane process that has a
> lot of traps for the unwary.

Every regular expression library I've used offers the same basic
functionality.  The *syntax* might change, and they may add options
and/or features.  But in terms of basic functionality, they all do
exactly the same thing.  So unless you're constantly doing something
exotic, your normal work with regular expressions will use the same
concepts and probably even the same syntax.  So I'm not sure how that
would get in your way.  Or maybe I do...

One of the recurring themes in comp.lang.forth is that Forth
programming is about creating an application-specific language that
solves the problem.  That statement is of course not unique,
programming in any language (at least any language that has readable
identifiers) is about creating an application-specific language that
solves the problem.  The only difference is that in Forth, you can
make the syntax appear nicer:

    : squared dup * ;
    3 squared

    int square(int n) { return n*n; }
    square(3);

The fact is that in nearly every programming language, one "creates an
application-specific language."  The fact that some languages may
impose their own syntax is secondary.  It's the difference between me
mumbling to my partner to pass me the salt at dinner ("salt") to a
more formal, verbose, and explicit expression ("Phillip, would you
please pick up the salt and hand it to me?").  The result is exactly
the same-- my blood pressure increases because I get too much
sodium.

The point of all this being that Forth programmers tend to think that
syntax is terribly, awfully, insanely, hyper-important.  So it doesn't
surprise me that (some) Forth programmers learning scripting languages
don't start with the larger concepts and instead focus on the syntax.
And when they do that, switching between different scripting languages
is a big deal.

But that's not the only way to approach scripting languages (or any
language, for that matter).  Instead of worrying about the syntax, one
can focus on the concepts and facilities the language provides and
think in terms of that.  Then syntax is merely you mapping concepts
and facilities to syntax.  Ever wonder how some people can can pick up
new programming languages so quickly?  That's how.

> Well, if I have a scripting language that's mostly Forth, it's going to
> be based heavily around a data stack. You get stuff from the stack and
> leave stuff on the stack and your operations are concatenative -- each
> one can just use the output from the last one without much fuss. If it
> doesn't have that then it isn't Forth, it's at best a scripting language
> written in Forth.
>
> So just like I don't want to learn regexp, how many scripting language
> users will want to learn how to use the data stack?

I consider that a failure of imagination, probably rooted in how the
Forth community loves to think inside the box that Forth defines for
them, and reflexively rejects anything that isn't Forth.

Let's first define what a scripting language is (or should be).  There
is no singular definition, so I prefer to define what a scripting
language is in terms of the features I look for.  And aside from the
painfully obvious (such as offering some form of "eval" to take a
string in that language and execute it), here are some of the big
deals:

1.  It provides a toolbox of useful facilities (often regular
expressions, associative arrays, lists, etc.).
2.  It provides automatic memory management (which implies garbage
collection).
3.  It usually provides automatic coercion between data types
(treating numeric strings as numbers, for example).
4.  It nearly always makes all data types (including functions) "first
class".
5.  It often recursively builds the language in terms of it's own
facilities (such as storing definitions in an associative array).
6.  It often offers rich introspection services and the ability to
manipulate the environment.
7.  It often offers object orientation features (or at least has the
primitives for such).
8.  It often offers hooks on primitive data types, allowing the
programmer to extend or subvert as needed.

So no, Forth itself doesn't qualify as a scripting language.  The
confusion comes from people applying the weakest form of scripting
languages-- command languages-- and thinking they are the same.  The
difference becomes immediately apparent the moment someone needs to do
something non-trivial in that Forth-based command language.  They
quickly have to drop to actual Forth, engaging in low-level stack
noise, thinking about the actual representation of data, thinking
about issues like memory leaks during errors, etc.

So what would a Forth-based scripting language look like?  Here are
some ideas:

1.  The Forth dictionary is scrapped for an associative array.  This
doesn't sound like a big deal, but it implies a lot:

1a.  It means that the programmer can treat the dictionary the same as
any other associative array in the system.  The programmer doesn't
need to learn anything new in order to manipulate the dictionary.
1b.  It means deleting and redefining definitions can be done at the
definition level-- just delete the key/value pair or redefine the
value.
1c.  It means that word lists can be little more than creating a new
associative array and putting definitions in it.
1d.  It provides a single consistent foundation for things like
modules, allowing a community to contribute code without worrying
about a particular implementations' take on modules.

2.  The language would use a typed stack.  So instead of a stack of
untyped cells, each stack element would be a type/value pair.  This
implies:

2a.  The stack is now unified-- the programmer now sees all values,
regardless of their actual size, as a single item on the stack.
2b.  Operators can now be polymorphic reducing the number of symbols
the programmer needs to know.  For example, "+" can now add a integer
and a float, and "." can print anything, regardless of type.

3.  The primary means of extending the language would be through hooks
that the programmer could change.  These hooks could (as in Lua) be
stored in just another associative array that is set on a particular
value.  For example:

3a.  A basic operation of associative arrays is the lookup operation--
given a key, return the value.  By changing an associative array's
lookup hook, you can do all sorts of interesting things.  One example
is to let you implement a form of inheritance where if a key is
missing in an associative array, you can look for it up a chain of
parents.  Another is to record accesses to a key to implement a most-
recently-used cache policy.
3b.  Types could define hooks for common operations (such as + or <).
This is useful for programmer-defined types.  For example, if I
created a complex number type, I can override the + and < hooks to
allow me to avoid a Forth-style type-specific operator (like c+ for
"complex addition").  This allows programmer-defined types to work in
expected ways with existing data types, and further reduces the amount
of syntax the programmer needs to keep in their head.
3c.  Standardization of these hooks behind a single consistent
interface means that we don't have the Forth Tower of Bable problem.
Programmers who want to extend the language don't have to resort to
implementation-specific means.  We provide a single consistent method.

4.  Classic Forth assumes you care more about speed than pretty much
anything else.  This is seen in the definition of words, which
classically are lists of addresses to other words.  But this static
model doesn't work so great with dynamic scripting languages.  So I
would change definitions to result in a dynamic lookup of the words.
That is, instead of the address of "*" I would store the symbol "*"
and let the normal lookup mechanisms apply.  Too slow?  Then take a
cue from Postscript.  In Postscript, dynamic lookups for definitions
are normal, and if speed is important you can tell the language
explicitly by using "bind" which replaces references to the symbol
with what the symbol resolves to.  In other words, you can make a
choice between speed and flexibility, and not be stuck in the Forth
mindset that faster is always better.

5.  The last idea I'll bring up here is optional, but it does lead to
a language that is more consistent than Forth and easier to learn.
When most people start off learning about Forth, they are told that
it's a postfix language.  And that's mostly true, except when it comes
to defining words like VARIABLE.  And yes, it's not hard to understand
how Forth evolved with bits of prefix in what otherwise is a postfix
language.  But let's avoid the whole issue in this new scripting
language and make it purely postfix.  How?  Postscript again showed
the way here.  Instead of words that reach into the input buffer and
extract the next word, the solution is for the programmer to put a
string on the stack.  For example, the Forth-based scripting language
definitions might look like this:

     "square" { dup * } def

Aside from making the language purely postfix, there are a few things
to note here:

5a.  The name of the word in this example came from a literal in the
code, but it could have come from any calculation that resulted in a
string.

5b.  The definition leaves on the stack a reference to an anonymous
function, but it could be any value-- for example, a number or string:

     "pi" 3.1415 def
     "name" "John Passaniti" def

So we don't need to have different words to define functions and
variables.  We can unify them all in "def".

5c.  The definition for "def" would probably be something like:

     { dict ! }

That is, dictionary would have been previously defined as an
associative array.  Because "!" is polymorphic, it defers to the store
definition for an associative array, which is to take a name/value
pair on the stack and store it in the associative array.

5d.  Because the store operation for an associative array could have a
hook, that hook could implement any kind of policy the programmer
wanted.  So for example, if I wanted to implement a check for
redefinitions, all I have to do is add code to the hook to test for
the existence of the definition before it stores it.  This means that
the base language doesn't have to supply such a test; if a programmer
wants to extend the language for such a check, they can do it
themselves.  This leads to a language where like Forth you can freely
change most of how things work, but the key is that unlike Forth,
there would be a single, simple way to do that.

I'm sure that as Forth traditionalists and Forth purists look through
these ideas, they will kneejerk and complain that "but Forth doesn't
do it like that."  Well, yes, exactly.  I'm not talking about Forth or
a language to replace Forth.  I'm talking about a true scripting
language based on Forth, not a cheesy command language that is Forth
with none of the benefits of a scripting language.  Of course, if you
don't actually understand the benefits of a scripting language, then
you're not going to get anything I just wrote.

Hugh Aguilar wrote:
> On Nov 21, 9:24 pm, Elizabeth D Rather <erat...@forth.com> wrote:
....
>> In fact, there were *no* "non-technical marketing-department people" on
>> the ANS Forth TC.
> 
> Whose idea was it for LOCALS| to declare the names backwards? That
> looks like the work of non-technical people to me. How about the
> haphazard mixture of words that work with counted strings (such as C")
> and words that work with an adr/count pair (such as S")? This is
> obviously an effort to be compatible with *every* existing Forth
> system, despite the fact that they are all incompatible with each
> other. The ANS-Forth standard appears to have been designed without
> the help of *any* technical people.

All members were technical people, a combination of Forth implementors 
and users.

LOCALS| had been in use in MacForth for some years, with several 
thousand systems and applications in the field.  There were no other 
locals implementation in general use.  It seemed at the time more 
appropriate to adopt an existing usage than try to invent a new one.

Major standards bodies (ANSI, IEEE, ISO) have strong guidelines about 
standards.  Among other things, they caution against trying to invent 
new technology and invalidating existing usage unnecessarily.

I have explained about S" and C" elsewhere.  I still think it was 
appropriate to avoid disrupting roughly half the systems in use.  In 
retrospect, S" has "won", and it would be appropriate to deprecate C" if 
anyone cares.

> The biggest problem with ANS-Forth is the CREATE DOES> construct.
> There can only be *one* action associated with the data type. That is
> a ridiculous limitation. Note that ANS-Forth came out at a time when C+
> +, Objective C and Object Pascal were gaining popularity. These
> languages allow multiple methods to be associated with each data type.
> For the ANS-Forth to adhere to a 1970s hack such as CREATE DOES> was
> just absurd. Now you claim that it was lack of marketing that brought
> down ANS-Forth. No it wasn't. Not even Zig Ziglar could have sold
> programmers on CREATE DOES> --- you have to have a standard that makes
> sense in order for technical people to adopt it.

Well, we'll have to agree to disagree on that one.  CREATE DOES> was in 
widespread use before ANS Forth, and remains in widespread use.  Had 
there been general dissatisfaction with it, there would have been 
competing schemes called to our attention, and that didn't happen.  It 
is not the mission of a standards committee to design new technology.

> I have ANS-Forth software available that demonstrates how code
> generated by defining words that I wrote myself is an order of
> magnitude faster (on SwiftForth) than code generated by CREATE DOES>,
> and less than half the size. All in all, CREATE DOES> was a grotesque
> blunder. Never mind the lack of double-precision arithmetic in ANS-
> Forth --- CREATE DOES> alone would have been enough to kill ANS-Forth
> as a serious language. ANS-Forth came out in 1994, and it presented a
> crufty throwback to software technology of 20 years previous. If you
> had ejected CREATE DOES> and introduced :NAME in 1983, Forth would
> have succeeded, and it still wasn't too late in 1994. By now (2009)
> all of the old legacy code would have been rewritten to use :NAME and
> the CREATE DOES> fiasco would have long since died an unlamented death
> --- it would just be a vaguely disturbing memory from the bad old days
> --- instead, we now have so much legacy code using CREATE DOES> that
> we can't get rid of it.

You have proposed :NAME.  Programmers who find it attractive will 
implement it.  If it is in widespread use a few years from now, it will 
be appropriate to consider it for standardization.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

On Nov 22, 8:44=A0pm, John Passaniti <john.passan...@gmail.com> wrote:
> So what would a Forth-based scripting language look like? =A0

It would look like Factor.

I think Forth needs to focus on micro-controller code. Leave scripting
to Factor.

> 1. =A0The Forth dictionary is scrapped for an associative array. =A0This
> doesn't sound like a big deal, but it implies a lot:

I recently ported my symtab.factor program to Forth (and fixed a bug
in it). You couldn't figure out symtab last time I posted it, but
maybe you'll get it this time. Here is the Factor version again:

http://www.rosycrew.com/symtab.factor

I am planning on making the symtab program available in the near
future as part of a package of Forth programs intended to be used by
novices. I have arrays, string functions, etc., that are necessary for
scripting-type programs, but which most novices aren't able to write
for themselves.

> 2. =A0The language would use a typed stack. =A0So instead of a stack of
> untyped cells, each stack element would be a type/value pair. =A0This
> implies:
>
> 2a. =A0The stack is now unified-- the programmer now sees all values,
> regardless of their actual size, as a single item on the stack.
> 2b. =A0Operators can now be polymorphic reducing the number of symbols
> the programmer needs to know. =A0For example, "+" can now add a integer
> and a float, and "." can print anything, regardless of type.

This will never be implemented in Forth --- the result wouldn't be
Forth any more. Forth is an embedded micro-controller language, and
you can't have dynamic typing on a real-time system. I discussed with
Slava the possibility of putting Factor on a micro-controller. I tried
to convince him to put Factor on the eZ80, with the intention of
putting Forth on the PIC24 and using them together on the same board,
but he didn't like the idea. He thinks that the ColdFire is the
smallest processor that could support Factor. This just shows what
kind of overhead is involved in a scripting language.

> 3. =A0The primary means of extending the language would be through hooks
> that the programmer could change. =A0These hooks could (as in Lua) be
> stored in just another associative array that is set on a particular
> value. =A0For example:

This has been in Forth since the 1970s. Lua doesn't have anything on
Forth in this regard.

> 5. =A0The last idea I'll bring up here is optional, but it does lead to
> a language that is more consistent than Forth and easier to learn.
> When most people start off learning about Forth, they are told that
> it's a postfix language. =A0And that's mostly true, except when it comes
> to defining words like VARIABLE. =A0And yes, it's not hard to understand
> how Forth evolved with bits of prefix in what otherwise is a postfix
> language. =A0But let's avoid the whole issue in this new scripting
> language and make it purely postfix. =A0How? =A0Postscript again showed
> the way here. =A0Instead of words that reach into the input buffer and
> extract the next word, the solution is for the programmer to put a
> string on the stack. =A0For example, the Forth-based scripting language
> definitions might look like this:
>
> =A0 =A0 =A0"square" { dup * } def

This is pretty much what my :NAME did, but everybody hated it.

BTW, you said that your "partner" is "Phillip." Are you trying to tell
us that you're a faggot?

Hugh Aguilar wrote:

   ...

> BTW, you said that your "partner" is "Phillip." Are you trying to tell
> us that you're a faggot?

You've been pissing me off for a while now. You just earned a berth in 
my killfile.

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

Hugh Aguilar wrote:
....
> BTW, you said that your "partner" is "Phillip." Are you trying to tell
> us that you're a faggot?

That is an extremely offensive remark that has no place in this 
newsgroup.  You owe all of us an apology.

Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

On Nov 22, 2:39=A0am, Elizabeth D Rather <erat...@forth.com> wrote:
> What is the actual footprint of a typical Forth vs. other scripting
> languages?

Every now and then in this newsgroup, you've undoubtedly read that a
simple "hello world" program compiled in C can generate an executable
image that's a megabyte or more.  This causes great delight by
Forthers until someone (such as myself) points out that size is not
just the executable code, but tables providing references to
dynamically linked libraries, symbol tables used for debuggers,
padding for the OS loader, and other whatnot.  When you strip out
debugging information, you tend to get reasonable sizes.  And when you
move the target to an embedded system (to avoid the usual fruit salad
comparisons), you find the results usually aren't terribly far from if
you wrote it by hand in assembler.

The point being that unless you know what is being quoted, the numbers
can be meaningless or misleading.

So in an effort to not offer meaningless or misleading numbers, I'm
going to compare apples to apples.  Forth tends to be used in embedded
systems without an OS and so I'm going to pick a scripting language
that is often used in the same context:  Lua.  I don't have numbers
for the current version of Lua (5.1), but the Lua folk did look at
this in the past for Lua 4 targeting a 32-bit x86 processor.  The
numbers for Lua 5.1 are undoubtedly a bit larger, but I wouldn't
expect them to be insanely so.  I'll try to get those numbers if there
is interest.

Lua can be divided into two major parts-- the core and libraries.  The
core takes up 41.7k and the libraries take up about 22.5k.  So the
total size, excluding any run-time memory is about 64.2k.  What that
64.2k gave you was a stack-based virtual machine, a compiler, and
libraries.  But that's not the full story, as often embedded
applications (like Forth) don't need the compiler.  In Lua, you can
compile Lua code to a form that doesn't need Lua's compiler.  So the
next logical question is, how much of the language core is the
compiler.  The answer in the case of Lua 4 is about 16.6k.  So if you
have a sealed application that doesn't require the compiler, your core
drops to 25.1k for a total size of 47.6k.

A minimal Forth with the same level of functionality for the same
target could probably match or beat that.  But that's not really the
point, is it?  The point is that the cost of scripting languages isn't
necessarily that large and can compare favorably to Forth.  Moreover,
three features that people often cite as being important to Forth
development for embedded systems (interactivity, incremental
development, having a compiler on the target system) is available in
other languages.  This is why I keep saying the Forth community seems
to be stuck in 1980, when the only real competition was an expensive
and slow C compiler on an expensive and slow development system
separate from the target.

John Passaniti <john.passaniti@gmail.com> wrote:
> Jonah Thomas <jethom...@gmail.com> wrote:

> > Particularly I want a scripting language when I want to write
> > something quick that I'll use once. I hope I'll know a right answer
> > when I see it, because I'm probably not going to do enough testing
> > to make sure there are no bugs. I just want to sit down and get my
> > result and move on. I hesitate to admit this; it sounds bad. But I
> > expect it's true for most people who write simple scripts that they
> > intend to use once.
> 
> For simple, throw-away scripts, yes, testing tends to be less
> rigorous.  Of course, often such simple scripts exist to answer simple
> questions, and the correctness of the script is (usually) obvious.

Yes. Like, I get an answer I can test. I don't verify that there's no
other answer. 

> For me, the process of creating simple scripts is just as iterative as
> when I'm using Forth.  A script usually starts by parsing some input,
> and so the first iteration is to write a parser (usually based on the
> language's built-in string splitting or regular expressions) and
> output what I parsed to the screen.  Once I've verified the
> correctness of that parsing, I then move to processing which is often
> just grouping data together or simple math.  That usually doesn't
> require much if any testing, but when I'm unsure, it's simple to drop
> in some "print" statements and verify that the processing is doing
> what I want.  And finally, I need to output something, and that's
> often just iterating over a table and outputting previous
> calculations.
> 
> Normally, each iteration is written and incrementally tested by
> editing a file and then invoking it with the scripting language's
> interpreter.  But most every scripting language these days offers one
> the ability to interactively write and execute code (just like in
> Forth).  In some cases, this is provided by the language itself.
> Other times, you can drop into a debugger which is usually just a
> fancy "read eval print" loop that happens to have some added
> functionality.  And in the rare case when this isn't available, one
> can craft their own "read eval print" loop and turn a non-interactive
> language into an interactive one.

I hope we're talking about different levels of complexity here. I want
something that gets me results within three or four tries. If I actually
have to program it, I might as well use Forth.

> I should also mention here that many times more complicated scripts
> are really just concatenations of simpler scripts.  Sound familiar?
> The Unix pipe notion has strong parallels to the idea in Forth that
> you can compose more complicated words by the concatenation of them.

Yes.
 
> > I personally found regexp to be almost useless for this sort of
> > thing. I'd try it, and inevitably make a mistake. So I'd fix the
> > mistake and then find a second mistake. After four or five tries I
> > could get something that looked like it was doing what I wanted, but
> > of course there might be hidden bugs somewhere. For something I
> > wanted to use once it took too many tries, and for something I
> > wanted to re-use there were too many possible errors to bite me
> > later.
> 
> The problem may be that you're trying to do too much with regular
> expressions.  They aren't useful for all problems, and depending on
> the input you're matching on, it may not even be possible.  For
> example, most classic regular expression libraries can't match on
> balanced symbols (like parenthesis or brackets) which means that if
> you wanted to write a regular expression to parse "(1+(2*3))" you're
> out of luck and should use other parsing methods.  Another issue that
> is classic regular expressions are "greedy" so matching on shortest-
> possible patterns may be impossible or require more explicit (and
> thus, more brittle) patterns.
> 
> Another problem may be that you're using a too-powerful bells-and-
> whistles regular expression library (such as the one that comes with
> Perl) that gives you (seemingly) endless different exotic options.

I think that's it. Very powerful. I had to understand the whole thing to
be sure I wasn't accidentally using advanced features I didn't want to
use.

> The desire to come up with a single pattern to match what you want is
> fine, but in my experience, you can get results faster by using a
> simpler regular expression to first transform your input into
> something simpler, and then in subsequent regular expressions be able
> to use that simplified input.

That sounds like a very good idea. I did some of that, but of course
each time I changed the data I had to make sure I didn't accidentally
change it in unexpected ways. Again a simpler regexp would surely have
helped.

> > Of course if I took the time to sit down and really learn regexps
> > then I could use it effectively. I'd have to learn the details of
> > precisely how my particular scripting language did it, knowing that
> > it would be different in detail for a different scripting language.
> > But I want a scripting language to be easy to use, to not get in my
> > way. I don't want to sit down and learn all the details of an arcane
> > process that has a lot of traps for the unwary.
> 
> Every regular expression library I've used offers the same basic
> functionality.  The *syntax* might change, and they may add options
> and/or features.  But in terms of basic functionality, they all do
> exactly the same thing.  So unless you're constantly doing something
> exotic, your normal work with regular expressions will use the same
> concepts and probably even the same syntax.  So I'm not sure how that
> would get in your way.  Or maybe I do...

A complex regexp with lots and lots of features. Switches to change it
around for different purposes, for example special cases to deal with
filenames and different dictionary orders. 

> One of the recurring themes in comp.lang.forth is that Forth
> programming is about creating an application-specific language that
> solves the problem.  That statement is of course not unique,
> programming in any language (at least any language that has readable
> identifiers) is about creating an application-specific language that
> solves the problem.  The only difference is that in Forth, you can
> make the syntax appear nicer:
> 
>     : squared dup * ;
>     3 squared
> 
>     int square(int n) { return n*n; }
>     square(3);
> 
> The fact is that in nearly every programming language, one "creates an
> application-specific language."  The fact that some languages may
> impose their own syntax is secondary.  It's the difference between me
> mumbling to my partner to pass me the salt at dinner ("salt") to a
> more formal, verbose, and explicit expression ("Phillip, would you
> please pick up the salt and hand it to me?").  The result is exactly
> the same-- my blood pressure increases because I get too much
> sodium.
> 
> The point of all this being that Forth programmers tend to think that
> syntax is terribly, awfully, insanely, hyper-important.  So it doesn't
> surprise me that (some) Forth programmers learning scripting languages
> don't start with the larger concepts and instead focus on the syntax.
> And when they do that, switching between different scripting languages
> is a big deal.

I started with one scripting language whose regexp had a truly powerful
syntax. Change one character and you get a very different result. The
syntax looked hyper-important because it meant the difference between
success and failure in each individual example. Clearly I would have
done better to find a combination of switches that would turn off most
of the advanced features and leave me with the basic functionality
common to most regexps. What I did instead was puzzle over the online
manuals, look at examples, and struggle through until it started looking
easier to use the more predictable features of the scripting language
instead.

> But that's not the only way to approach scripting languages (or any
> language, for that matter).  Instead of worrying about the syntax, one
> can focus on the concepts and facilities the language provides and
> think in terms of that.  Then syntax is merely you mapping concepts
> and facilities to syntax.  Ever wonder how some people can can pick up
> new programming languages so quickly?  That's how.
> 
> > Well, if I have a scripting language that's mostly Forth, it's going
> > to be based heavily around a data stack. You get stuff from the
> > stack and leave stuff on the stack and your operations are
> > concatenative -- each one can just use the output from the last one
> > without much fuss. If it doesn't have that then it isn't Forth, it's
> > at best a scripting language written in Forth.
> >
> > So just like I don't want to learn regexp, how many scripting
> > language users will want to learn how to use the data stack?
> 
> I consider that a failure of imagination, probably rooted in how the
> Forth community loves to think inside the box that Forth defines for
> them, and reflexively rejects anything that isn't Forth.
> 
> Let's first define what a scripting language is (or should be).  There
> is no singular definition, so I prefer to define what a scripting
> language is in terms of the features I look for.  And aside from the
> painfully obvious (such as offering some form of "eval" to take a
> string in that language and execute it), here are some of the big
> deals:
> 
> 1.  It provides a toolbox of useful facilities (often regular
> expressions, associative arrays, lists, etc.).
> 2.  It provides automatic memory management (which implies garbage
> collection).
> 3.  It usually provides automatic coercion between data types
> (treating numeric strings as numbers, for example).
> 4.  It nearly always makes all data types (including functions) "first
> class".
> 5.  It often recursively builds the language in terms of it's own
> facilities (such as storing definitions in an associative array).
> 6.  It often offers rich introspection services and the ability to
> manipulate the environment.
> 7.  It often offers object orientation features (or at least has the
> primitives for such).
> 8.  It often offers hooks on primitive data types, allowing the
> programmer to extend or subvert as needed.
> 
> So no, Forth itself doesn't qualify as a scripting language.  The
> confusion comes from people applying the weakest form of scripting
> languages-- command languages-- and thinking they are the same.  The
> difference becomes immediately apparent the moment someone needs to do
> something non-trivial in that Forth-based command language.  They
> quickly have to drop to actual Forth, engaging in low-level stack
> noise, thinking about the actual representation of data, thinking
> about issues like memory leaks during errors, etc.
> 
> So what would a Forth-based scripting language look like?  Here are
> some ideas:> Let's first define what a scripting language is (or
> should be).  There is no singular definition, so I prefer to define
> what a scripting language is in terms of the features I look for. 
> 
> 1.  The Forth dictionary is scrapped for an associative array.  This
> doesn't sound like a big deal, but it implies a lot:
> 
> 1a.  It means that the programmer can treat the dictionary the same as
> any other associative array in the system.  The programmer doesn't
> need to learn anything new in order to manipulate the dictionary.
> 1b.  It means deleting and redefining definitions can be done at the
> definition level-- just delete the key/value pair or redefine the
> value.
> 1c.  It means that word lists can be little more than creating a new
> associative array and putting definitions in it.
> 1d.  It provides a single consistent foundation for things like
> modules, allowing a community to contribute code without worrying
> about a particular implementations' take on modules.

Of course I like that.

> 2.  The language would use a typed stack.  So instead of a stack of
> untyped cells, each stack element would be a type/value pair.  This
> implies:
> 
> 2a.  The stack is now unified-- the programmer now sees all values,
> regardless of their actual size, as a single item on the stack.
> 2b.  Operators can now be polymorphic reducing the number of symbols
> the programmer needs to know.  For example, "+" can now add a integer
> and a float, and "." can print anything, regardless of type.

I think I see how to do that. It adds some overhead, and I'm not sure
whether it gives simpler results or not. But that's because I haven't
spent enough time using a system that works that way to see how great it
would be. i get the impression you have extensively used systems like
that, so you know what you're talking about while I'm just guessing.

> 3.  The primary means of extending the language would be through hooks
> that the programmer could change.  These hooks could (as in Lua) be
> stored in just another associative array that is set on a particular
> value.  For example:
> 
> 3a.  A basic operation of associative arrays is the lookup operation--
> given a key, return the value.  By changing an associative array's
> lookup hook, you can do all sorts of interesting things.  One example
> is to let you implement a form of inheritance where if a key is
> missing in an associative array, you can look for it up a chain of
> parents.  Another is to record accesses to a key to implement a most-
> recently-used cache policy.
> 3b.  Types could define hooks for common operations (such as + or <).
> This is useful for programmer-defined types.  For example, if I
> created a complex number type, I can override the + and < hooks to
> allow me to avoid a Forth-style type-specific operator (like c+ for
> "complex addition").  This allows programmer-defined types to work in
> expected ways with existing data types, and further reduces the amount
> of syntax the programmer needs to keep in their head.
> 3c.  Standardization of these hooks behind a single consistent
> interface means that we don't have the Forth Tower of Bable problem.
> Programmers who want to extend the language don't have to resort to
> implementation-specific means.  We provide a single consistent method.

That's interesting. Some of the features you describe are things I think
I wouldn't want. But if they're easily available that doesn't force me
to use them. A simple pattern provides things I want plus things other
people want. Cool.

> 4.  Classic Forth assumes you care more about speed than pretty much
> anything else.  This is seen in the definition of words, which
> classically are lists of addresses to other words.  But this static
> model doesn't work so great with dynamic scripting languages.  So I
> would change definitions to result in a dynamic lookup of the words.
> That is, instead of the address of "*" I would store the symbol "*"
> and let the normal lookup mechanisms apply.  Too slow?  Then take a
> cue from Postscript.  In Postscript, dynamic lookups for definitions
> are normal, and if speed is important you can tell the language
> explicitly by using "bind" which replaces references to the symbol
> with what the symbol resolves to.  In other words, you can make a
> choice between speed and flexibility, and not be stuck in the Forth
> mindset that faster is always better.

That's easy. You compile code or you use text macros. That's available
in Forth now with essentially zero overhead. I mean, you don't have to
add much of anything to Forth to take advantage of it. You of course get
the overhead of dynamic lookup. In previous discussions I've seen
competent Forthers reject this approach because they didn't like the
bugs available when you redefine words and change the search order and
then do dynamic lookups. Your feature looked like a bug to them. But
that's a programming choice, what you want to do is available already,
all it needs is the decision to use it.

> 5.  The last idea I'll bring up here is optional, but it does lead to
> a language that is more consistent than Forth and easier to learn.
> When most people start off learning about Forth, they are told that
> it's a postfix language.  And that's mostly true, except when it comes
> to defining words like VARIABLE.  And yes, it's not hard to understand
> how Forth evolved with bits of prefix in what otherwise is a postfix
> language.  But let's avoid the whole issue in this new scripting
> language and make it purely postfix.  How?  Postscript again showed
> the way here.  Instead of words that reach into the input buffer and
> extract the next word, the solution is for the programmer to put a
> string on the stack.  For example, the Forth-based scripting language
> definitions might look like this:
> 
>      "square" { dup * } def
> 
> Aside from making the language purely postfix, there are a few things
> to note here:
> 
> 5a.  The name of the word in this example came from a literal in the
> code, but it could have come from any calculation that resulted in a
> string.
> 
> 5b.  The definition leaves on the stack a reference to an anonymous
> function, but it could be any value-- for example, a number or string:
> 
>      "pi" 3.1415 def
>      "name" "John Passaniti" def
> 
> So we don't need to have different words to define functions and
> variables.  We can unify them all in "def".
> 
> 5c.  The definition for "def" would probably be something like:
> 
>      { dict ! }
> 
> That is, dictionary would have been previously defined as an
> associative array.  Because "!" is polymorphic, it defers to the store
> definition for an associative array, which is to take a name/value
> pair on the stack and store it in the associative array.
> 
> 5d.  Because the store operation for an associative array could have a
> hook, that hook could implement any kind of policy the programmer
> wanted.  So for example, if I wanted to implement a check for
> redefinitions, all I have to do is add code to the hook to test for
> the existence of the definition before it stores it.  This means that
> the base language doesn't have to supply such a test; if a programmer
> wants to extend the language for such a check, they can do it
> themselves.  This leads to a language where like Forth you can freely
> change most of how things work, but the key is that unlike Forth,
> there would be a single, simple way to do that.

I like it. Look-ahead words have added unneeded complexity to Forth, and
they aren't necessary. The only problem is that we already have so much
tradition using them that we can't change. It would have to be a new
Forth-like language.
 
> I'm sure that as Forth traditionalists and Forth purists look through
> these ideas, they will kneejerk and complain that "but Forth doesn't
> do it like that."  Well, yes, exactly.  I'm not talking about Forth or
> a language to replace Forth.  I'm talking about a true scripting
> language based on Forth, not a cheesy command language that is Forth
> with none of the benefits of a scripting language.  Of course, if you
> don't actually understand the benefits of a scripting language, then
> you're not going to get anything I just wrote.

I doubt I got everything you wrote. You've clearly put a lot of thought
into it. 

When I think about it, I've probably misunderstood the benefits of a
scripting language. 

What I like about Forth is that it gives me a simple clear model for
what's going on. So for example I seldom want to add an integer to a
float. It's a special circumstance when that's worth doing. So I don't
need to make the type conversion be automatic. It's easy to think about
the details of what I'm doing. But on the other hand I have to think
about the details. I can't just be sloppy and use a float in place of an
integer and expect the system to clean up after me.

The times I've wanted a scripting language, I thought it was something
really simple and I didn't need efficiency and I didn't care about
programming details, I just wanted my results. Typically there'd be
heavy string manipulation and I didn't want to think about it, it was
simple obvious stuff that I just wanted results for.

Basicly I wanted scripting languages when I wanted a DWIM language. (Do
What I Mean)  "I want my results without having to think!" 

And when I do think about it, I don't think I'm going to find scripting
languages that work that way. If I can get results without having to
think it means I'm traveling down a path a lot of people have been down
before, and the language has built a road to make it easy, and if I'm
lucky I can go down that road and end up where I want to be and not
somewhere else that the language designer thought I'd want to be.

> Let's first define what a scripting language is (or should be). There
> is no singular definition, so I prefer to define what a scripting
> language is in terms of the features I look for.

> 1.  It provides a toolbox of useful facilities (often regular
> expressions, associative arrays, lists, etc.).

Good!

> 2.  It provides automatic memory management (which implies garbage
> collection).

I mostly don't care, provided it doesn't run out of memory before I get
my answer.

> 3.  It usually provides automatic coercion between data types
> (treating numeric strings as numbers, for example).

I don't care, but I could live with that.

> 4.  It nearly always makes all data types (including functions) "first
> class".

I've forgotten what that means. It sounds good.

> 5.  It often recursively builds the language in terms of it's own
> facilities (such as storing definitions in an associative array).

Good but not particularly important.

> 6.  It often offers rich introspection services and the ability to
> manipulate the environment.

Vital!

> 7.  It often offers object orientation features (or at least has the
> primitives for such).

I don't care.

> 8.  It often offers hooks on primitive data types, allowing the
> programmer to extend or subvert as needed.

Also vital.

So the way I think of it now, in terms of features, a scripting language
should provide powerful features -- preferably in an integrated way so
that they aren't just tacked on but it's giving you access to powerful
yet simple tools the language uses itself. And if you learn the language
well enough you can change it around to do what you need instead of what
it already does. It's easy to see what it's doing so you can do quick
interactive debugging etc.

All of this can be said to be true of Forth as it stands. But the
powerful features Forth is built on are not as powerful as those used by
more modern languages.

John Passaniti <john.passaniti@gmail.com> writes:
>On Nov 22, 2:39=A0am, Elizabeth D Rather <erat...@forth.com> wrote:
>> What is the actual footprint of a typical Forth vs. other scripting
>> languages?

In the following you see the resident set size as reported by ps on a
Linux-AMD64 system with enough RAM (that's a pretty good approximation
to the run-time footprint size). The various systems were just
started, and then waited in their iterpretive loop.  If no
interpretive loop was available (awk), a simple program was used, and
that waited for its input).

 904KB Gforth 0.6.2 (Debian package)
9064KB vfxlin 4.30 RC1 [build 0324] (probably initializes the dictionary)
4556KB iforth 2.1.2541 (probably initializes the dictionary)
 792KB bigForth 2.3.1 
3556KB Python
6644KB Ruby 1.9.0 (started with irb)
 724KB gawk 3.1.5 (started with 'awk "{print}"')
1548KB perl 5.10.0 (perl -e 'while (<>) {print $_; }')
7036KB bash 3.2.39(1)
1188KB lua 5.0.3
 644KB lua 4.0

I could not get Factor to do anything but give me some error message.

>Every now and then in this newsgroup, you've undoubtedly read that a
>simple "hello world" program compiled in C can generate an executable
>image that's a megabyte or more.

I haven't.  Looks like a straw man to me.

>This causes great delight by
>Forthers until someone (such as myself) points out that size is not
>just the executable code, but tables providing references to
>dynamically linked libraries, symbol tables used for debuggers,
>padding for the OS loader, and other whatnot.

Let's see (on Linux-AMD64):

[c8:/tmp:26079] cat hello.c
#include <stdio.h>

int main()
{
  printf("hello, world");
  return 0;
}
[c8:/tmp:26080] gcc -g -Wall hello.c -o hello
[c8:/tmp:26081] ls -l hello
-rwxr-xr-x 1 anton users 9661 Nov 23 11:33 hello*
[c8:/tmp:26082] size hello
   text    data     bss     dec     hex filename
   1170     520      16    1706     6aa hello
[c8:/tmp:26083] file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped

>When you strip out
>debugging information, you tend to get reasonable sizes.

[c8:/tmp:26084] strip hello
[c8:/tmp:26085] ls -l hello
-rwxr-xr-x 1 anton users 4448 Nov 23 11:36 hello*
[c8:/tmp:26086] size hello
   text    data     bss     dec     hex filename
   1170     520      16    1706     6aa hello

If you really want to see large numbers, you have to forego the
dynamic linkage tables and use static linking:

[c8:/tmp:26095] gcc -g -Wall -static hello.c -o hello
[c8:/tmp:26096] ls -l hello
-rwxr-xr-x 1 anton users 641462 Nov 23 11:48 hello*
[c8:/tmp:26097] size hello
   text    data     bss     dec     hex filename
 551009    3424   12328  566761   8a5e9 hello
[c8:/tmp:26098] strip hello
[c8:/tmp:26099] ls -l hello
-rwxr-xr-x 1 anton users 566504 Nov 23 11:49 hello*

- 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.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

On Sun, 22 Nov 2009 20:23:23 -0800 (PST), Hugh Aguilar
<hugoaguilar@rosycrew.com> wrote:

>Are you trying to tell us that you're a faggot?

My tolerance level has been exceeded. Please apologise and/or
go away.

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
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.mpeforth.com - free VFX Forth downloads

Anton Ertl wrote:
> Let's see (on Linux-AMD64):
> 
> [c8:/tmp:26079] cat hello.c
> #include <stdio.h>
> 
> int main()
> {
>   printf("hello, world");
>   return 0;
> }
> [c8:/tmp:26080] gcc -g -Wall hello.c -o hello
> [c8:/tmp:26081] ls -l hello
> -rwxr-xr-x 1 anton users 9661 Nov 23 11:33 hello*

Hm, wasn't the question about RSS?  I get 376kB on Linux-AMD64 for a simple 
program that only does getc(stdin); and 996kB from bigForth (how much you 
get depends on how much glibc contributes to RSS).  A funny thing on that is 
that forthker (bigForth's kernel) has a larger RSS than bigForth - this 
comes from the dynamic memory handling in bigForth, which has a garbage 
collector that isn't part of the kernel (bigForth tells the OS which pages 
it considers as unused).

Some other figures, which also make me wonder:

xbigforth: 6500kB (MINOS compiled on bigForth, with several shared 
libraries, ttf fonts, caches from the font renderer, etc.)
xvfxlin: 29548kB (MINOS compiled on VFX, all other things identical).

This can be neither explained by the 8MB more from vfxlin than from 
bigForth, nor by the larger executable (1.2MB instead of 550kB).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

>Are you trying to tell us that you're a faggot?

: ASSHOLE? ANTI-GAY? IF GO-AWAY THEN ;

Hugh Aguilar <hugoaguilar@rosycrew.com> wrote:

> BTW, you said that your "partner" is "Phillip." Are you trying to tell
> us that you're a faggot?

He was hinting at something like that. So what?

Various Forth experts have been unconventional in one way or another in
their personal lives, and I've known of one widely self-proclaimed
homosexual with HIV, Roedy Green. He has largely given up Forth for
Java, but still distributes Abundance, his much-featured Forth database
system.

I figure this issue is a good one to practice behaving like a
responsible adult. If somebody has something useful to say on a
technical newsgroup, then I'm not going to worry about their sex life
and I'd prefer not to hear too many details. If a co-worker of any sort
wants to proposition me and can take a polite "no thank you" as a
response, then I figure that's the best I can expect. Women have to deal
with that *all the time*. Somebody who can't take no for an answer is a
workplace problem regardless of gender or gender preference, but short
of that it isn't my issue.

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> [c8:/tmp:26080] gcc -g -Wall hello.c -o hello
>> [c8:/tmp:26081] ls -l hello
>> -rwxr-xr-x 1 anton users 9661 Nov 23 11:33 hello*
>
>Hm, wasn't the question about RSS?

My guess is that John Passaniti was talking about file size, not
resident set size (RSS).  E.g., he mentions debugging symbols and
stripping, which don't affect RSS in normal execution.

[RSS]
>Some other figures, which also make me wonder:
>
>xbigforth: 6500kB (MINOS compiled on bigForth, with several shared 
>libraries, ttf fonts, caches from the font renderer, etc.)
>xvfxlin: 29548kB (MINOS compiled on VFX, all other things identical).
>
>This can be neither explained by the 8MB more from vfxlin than from 
>bigForth, nor by the larger executable (1.2MB instead of 550kB).

Take a look at /proc/$pid/maps before and after loading MINOS.

- 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.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

On Nov 23, 7:39=A0am, Jonah Thomas <jethom...@gmail.com> wrote:
> Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
> > BTW, you said that your "partner" is "Phillip." Are you trying to tell
> > us that you're a faggot?
>
> He was hinting at something like that. So what?

I apologize for the use of the word "faggot" --- please educate me on
what word should be used.

I work as a cab driver, so I have to to be tolerant of a wide variety
of people that I wouldn't associate with outside of work. My policy is
to ignore that kind of thing. If the person feels compelled to inform
me of his issue however, then I make that person pay up front. For
example, if a person gets in the cab and immediately informs me that
he is member of a specific race, then I see that as a warning sign
that I'm dealing with a racist. Why tell me? --- how does this pertain
to the business at hand? The same thing is true for John Passaniti-
type of people (I still don't have a politically-correct word to use
here). Why tell me that he is what he is? How does this pertain to the
business at hand?

In my experience, people tell me things like this because they are
trying to justify themselves. In the cab context, this usually means
that they are going to try to run off without paying. There are also
other stunts that people try. One guy committed assault against me. I
put him in jail, and he is still there as far as I know. In every case
that somebody has tried some kind of stunt, that person has provided
me with plenty of warning; these kinds of things don't just happen out
of the blue. People always start out by explaining that they are
somehow special, and their past or (more likely) future behavior has
to be tolerated within this context. It is foolish; it is like showing
your cards at the poker table. People would be a lot more successful
against me if they would just attack without warning rather than first
try to justify themselves, but nobody ever does this. The result is
that I survive in an environment in which the odds are against me.
Other cab drivers have gotten their throats slit, but not me --- my
head is still attached.

Let's all of us agree that it is inappropriate to bring up issues such
as John Passaniti brought up. This is true on c.l.f., and within any
polite society.

On Nov 20, 8:27=A0am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> idknow <idk...@gmail.com> wrote:
> > Forth is unused and unknown by the general public because we the
> > devotee's of it haven't done anything with it to make it competitive
> > with Perl, Python, Ruby and the other scriptable languages.
>
> But they're *designed* for that job. =A0Forth is a multi-level general
> purpose programming language, particularly strong in the area of
> embedded applications. =A0You could certainly build a good language for
> this application area on top of Forth, and it might well gain some
> advantages from that, but it would be Language X, not Forth.

This thread started out by discussing continued fractions. These are
absolutely necessary for integer arithmetic (for use in */ and M*/),
and integer arithmetic is obviously the mainstay of embedded micro-
controller work. The point I was making is that I normally have to use
a 32-bit system to calculate rationals for a 16-bit system, or use a
64-bit system to calculate rationals for a 32-bit system. Forth would
make a lot more sense if I could use the same system for calculating
rationals as the system that I'm going to be using the rationals on.
All we need is DUM/MOD. Even if it were slow this wouldn't bother me
too much, as it is primarily used at compile-time. I can think of
cases in which it would be used at run-time (implementing a Factor-
like rational data type), but none of these cases involve embedded
micro-controllers, so the inherent speed issue shouldn't be much of a
practical problem.

Now our thread has diverged into a discussion of scripting languages
such as Perl, Python and Ruby. We even have discussion of regular
expressions! This is getting a long ways away from what I consider to
be Forth. Back in the 1980s it was realistic to have a single language
that was all things to all people, with Pascal and C both aspiring for
this coveted position. In 2009 this is no longer realistic; this is
the age of specialization. We can't expect Forth to compete with
heavily dynamic languages such as Ruby, and simultaneously compete
with GCC on micro-controllers. It seems significant to me that the
Ruby folks know better than to pit Ruby against GCC or Forth in the
micro-controller arena. We should be alert to the fact that they
haven't challenged us, and stop challenging them.

I think that a Forth-like language (Andrew Haley's "language X") can
compete against Ruby. That language is called "Factor." When I want to
write a scripting type of program on a desktop computer I use Factor
(or AWK or XSLT or whatever is appropriate). When I want to write a
real-time program on a micro-controller I use Forth (or assembly-
language if appropriate). I don't use C or C++ in either environment
for various reasons that I won't go into here. Who will disagree with
this pattern?

Hugh Aguilar wrote:
....
> Let's all of us agree that it is inappropriate to bring up issues such
> as John Passaniti brought up. This is true on c.l.f., and within any
> polite society.

Would it be "inappropriate" for me to mention my husband?  It was wildly 
inappropriate for you to have commented on John's remark, particularly 
in such an offensive way.  You are at fault here, not John.

Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

On Nov 23, 11:39=A0am, Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
> Forth would
> make a lot more sense if I could use the same system for calculating
> rationals as the system that I'm going to be using the rationals on.
> All we need is DUM/MOD. Even if it were slow this wouldn't bother me
> too much, as it is primarily used at compile-time.

I just had a thought! The primary reason for not including DUM/MOD in
standard Forth is that it is slow (on any microprocessor). People will
use it and then complain about the slowness, and Forth will get
blamed. Considering that DUM/MOD is primarily only needed for
continued fractions, then why not introduce a word CF into the
standard to calculate continued fractions? All of that messy double-
precision arithmetic would be buried inside of CF where it would be
out of the way.

Another advantage to doing this is that novices would be able to use
CF to calculate rationals for use in */ and M*/ without having to know
how to write CF themselves. While it was cool that Grossman provided
us with a Forth program to calculate continued fractions, how many
novices are going to look up a 1984 edition of Forth Dimensions to
read his article? For that matter, how many Forth programmers have the
mathematical background to understand his article? The guy is a
mathematics professor at UCLA, whereas my education is limited to H.S.
algebra. I can appreciate the need for a function such as CF, but I'm
not a good candidate for writing it.

Elizabeth Rather is a big fan of */ and M*/, which she considers
(rightly) to be Chuck Moore's best invention. These scalers are not
useful without rationals however, and rationals can only be calculated
with continued fractions. Chuck Moore gave us the first piece of the
puzzle 30 years ago with mixed-precision arithmetic, but now it is our
job to complete the puzzle with CF.

On Nov 23, 11:40=A0am, Elizabeth D Rather <erat...@forth.com> wrote:
> Hugh Aguilar wrote:
> > Let's all of us agree that it is inappropriate to bring up issues such
> > as John Passaniti brought up. This is true on c.l.f., and within any
> > polite society.
>
> Would it be "inappropriate" for me to mention my husband? =A0It was wildl=
y
> inappropriate for you to have commented on John's remark, particularly
> in such an offensive way. =A0You are at fault here, not John.

Unless he's a Forth programmer, then yes, it would be.

People are always telling me things that I don't need to know. In the
cab for example, a woman might get in and immediately tell me that she
has a husband, he works as a policeman, an he's over 6' tall. This may
very well be true, but it was inappropriate to tell me --- she is
definitely going to have to pay up front --- people need to be a lot
more circumspect about what they say to me.

On Mon, 23 Nov 2009 09:54:35 -0800 (PST)
Hugh Aguilar <hugoaguilar@rosycrew.com> wrote:

> On Nov 23, 7:39=A0am, Jonah Thomas <jethom...@gmail.com> wrote:
> > Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
> > > BTW, you said that your "partner" is "Phillip." Are you trying to
> > > tell us that you're a faggot?
> >
> > He was hinting at something like that. So what?
>=20
> I apologize for the use of the word "faggot" --- please educate me on
> what word should be used.

I am probably not the one to give you advice about that. When I say
"homosexual" in a nonjudgemental context I usually don't get trouble for
it, but I gather that "gay" is generally more acceptable.=20

> I work as a cab driver, so I have to to be tolerant of a wide variety
> of people that I wouldn't associate with outside of work. My policy is
> to ignore that kind of thing. If the person feels compelled to inform
> me of his issue however, then I make that person pay up front. For
> example, if a person gets in the cab and immediately informs me that
> he is member of a specific race, then I see that as a warning sign
> that I'm dealing with a racist. Why tell me? --- how does this pertain
> to the business at hand? The same thing is true for John Passaniti-
> type of people (I still don't have a politically-correct word to use
> here). Why tell me that he is what he is? How does this pertain to the
> business at hand?

I've sometimes had suspicions along those lines myself. But notice the
results you got.=20

John Passaniti has a unique viewpoint that makes him valuable here in
spite of his abrasive manner. If it comes to an argument about whether
it's worse for him to talk about his sex live or worse for you to tell
him you don't want to hear it, people here will tend to protect the
persecuted minority rather than side with the prejudiced one. It doesn't
exactly make sense but the reverse situation -- where gays really do get
put down -- is at least as bad and I seldom find groups that don't do it
one way or the other.=20

> In my experience, people tell me things like this because they are
> trying to justify themselves. In the cab context, this usually means
> that they are going to try to run off without paying. There are also
> other stunts that people try. One guy committed assault against me. I
> put him in jail, and he is still there as far as I know. In every case
> that somebody has tried some kind of stunt, that person has provided
> me with plenty of warning; these kinds of things don't just happen out
> of the blue. People always start out by explaining that they are
> somehow special, and their past or (more likely) future behavior has
> to be tolerated within this context. It is foolish; it is like showing
> your cards at the poker table. People would be a lot more successful
> against me if they would just attack without warning rather than first
> try to justify themselves, but nobody ever does this. The result is
> that I survive in an environment in which the odds are against me.
> Other cab drivers have gotten their throats slit, but not me --- my
> head is still attached.

John Passaniti isn't going to steal your cabfare or assault you. The
most he's likely to do is help you make yourself look like a boor that
nobody wants to talk to. He could do quite a lot in that direction if he
wanted to, because the default in liberal circles is that if a member of
a minority -- black, woman, gay, inuit, latino, etc -- says that you
have offended him/her, people will mostly assume you are at fault.
That's just how it works. So any time you discuss race relations with
somebody who's black, or feminism with a woman, or homosexuality with
somebody who's gay, etc then you are depending on their goodwill. If
they want to improve communication and come to a common understanding
etc, then you might have a rewarding conversation. But if they want to
make you look bad they can do it and there's nothing you can do about
it. So if you suspect they're bringing it up to get an advantage then
your best bet is to decline the gambit. Ignore the personal stuff
entirely and pay attention to the technical issues that are your main
interest anyway. You have nothing to gain by stepping into that tar pit.

> Let's all of us agree that it is inappropriate to bring up issues such
> as John Passaniti brought up. This is true on c.l.f., and within any
> polite society.

Whatever you decide, John Passaniti will bring up his lifestyle when he
chooses to. And whatever your opinion, you are better off to ignore it
than to challenge him on it. That's just the way this particular culture
works (and many others).=20

Remember too, if you happen to be correct on the technical issues, then
you do better by following up on those than by chasing red herrings that
have nothing to do with the discussion.

On Nov 23, 12:27=A0pm, Jonah Thomas <jethom...@gmail.com> wrote:
> ... the default in liberal circles is that if a member of
> a minority -- black, woman, gay, inuit, latino, etc -- says that you
> have offended him/her, people will mostly assume you are at fault.
> That's just how it works.

I'm well aware of the importance of minding my own business. Let me
tell a story:

Last week I was at the library and there was a group of youths sitting
in the chairs nearby and talking loudly enough for everybody to hear
them. There were two boys of age 18 or 19, and maybe four boys of age
14 or 15. The two older boys were bragging about breaking into cars
and stealing. One of them described how he stole something off some
guy's front porch and the man chased him for two blocks, which he
described as "funny as hell." The younger boys were highly impressed
by these true-crime stories. One of them dumped his breakfast cereal
on the floor and didn't pick it up. The librarian told him to clean up
the mess, and also told him that he wasn't supposed to be eating in
the library. He was very rude to her, but grudgingly picked up the
cereal while his comrades snickered at the librarian. A man standing
nearby commented: "You're a punk!" The boy raised his middle finger in
the man's face. The man shouted, "Don't you flip me off!," and he
stepped toward the boy. The boy and his comrades ran out the front
door laughing. The man then went upstairs.

About 10 minutes later the boy's mother came in yelling. She said that
she was going to call the police on that man, and she went to the pay-
phones to do this. At this time I decided to get involved. I went
upstairs and found the man browsing through the nonfiction books and I
told him that  the police were on their way, and that he needed to run
away immediately in order to avoid getting put in jail. He asked me in
bewilderment: "Why would I go to jail?" I gave him a brief
explanation, pretty much the same as you did in your post above. I
pointed out that the librarian is not going to back him up. She is
elderly and is just counting the days until retirement, when she can
begin collecting her government pension --- she doesn't want to get
involved in sensitive issues such as this. A glimmer of understanding
flickered in his eyes and he said: "Thank you." He left. Outside the
library words were exchanged between him and the mother, he called her
a "whore," and he ran away. Actually, he power-walked, as he was too
old and overweight to actually run.

The police showed up about 5 minutes later and talked to the woman.
She said that the man had tried to assault her son. She said that she
had often seen him lurking around schools and libraries, and
considered him to be a pedophile. She said that he had impersonated a
police officer. I don't think that any of this was true. As I
predicted, the librarian hid behind some book shelves and didn't get
involved.

So --- did that man do the right thing by calling that boy a punk? No,
he was an idiot to get involved in something that wasn't his business.
Did I do the right thing by tipping him off that the police were on
their way? Well, an argument can be made that I was also getting
involved in something that wasn't my business. Interfering with police
work is a crime, so I could theoretically be sent to jail for what I
did. I read about a similar situation in which the police had a sting
going on in which a policewoman pretended to be a prostitute and
solicited men passing by. If the guy showed interest, the police would
swoop in and arrest him. A bystander shouted out a warning to another
man: "She's a policewoman!" The police put him in jail too.
Considering this precedent, I could have been put in jail for warning
that other man. I think I did the right thing though. I would have
felt like a collaborator with that woman if I had just sat there and
done nothing. If I hadn't warned him, that poor fool would have
remained upstairs in the nonfiction section unaware of how much danger
he was in , right up to the moment when the police put the handcuffs
on him. He would likely be charged with "inappropriate sexual contact
with a minor," which is a felony. The end result would likely be that
the woman would drop the charges against him in exchange for a large
cash settlement. This is the kind of thing that happens to people who
don't mind their own business.

On Mon, 23 Nov 2009 09:54:35 -0800 (PST), Hugh Aguilar
<hugoaguilar@rosycrew.com> wrote:

>I apologize for the use of the word "faggot"

And so you bloody well should. It's been offensive for the last
30+ years.

Let's look at the post that triggered your assumptions:
> It's the difference between me
> mumbling to my partner to pass me the salt at dinner ("salt") to a
> more formal, verbose, and explicit expression ("Phillip, would you
> please pick up the salt and hand it to me?").  The result is exactly
> the same-- my blood pressure increases because I get too much
> sodium.

That was a constructed example. Just as it was popular to use
"hers" instead of "his" for a while in order to be gender neutral,
so you fell into a trap. Perhaps it was a deliberate trap, but
you fell into it and exposed yourself. Now you need to apologise
for the sentiment, not just the word.

This is a technical newsgroup. There are probably people of
genders and sexualities that you know nothing about in this
group. What you did was to extrapolate beyond reason and be
offensive in public. That makes it your shame. The safe thing
to do is not go outside the remit of this group. Note also
that your political rants are likely to be offensive to a
portion of this group. At present, you bring cab drivers into
disrepute.

If you really want to deconstruct postings, please study semiology,
linguistics and anthropology. At present, you know know nothing
about the personal lives of the people who post here. They are
not your business.

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
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.mpeforth.com - free VFX Forth downloads

Hugh Aguilar wrote:
> On Nov 23, 11:39 am, Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
>> Forth would
>> make a lot more sense if I could use the same system for calculating
>> rationals as the system that I'm going to be using the rationals on.
>> All we need is DUM/MOD. Even if it were slow this wouldn't bother me
>> too much, as it is primarily used at compile-time.
> 
> I just had a thought! The primary reason for not including DUM/MOD in
> standard Forth is that it is slow (on any microprocessor). People will
> use it and then complain about the slowness, and Forth will get
> blamed. Considering that DUM/MOD is primarily only needed for
> continued fractions, then why not introduce a word CF into the
> standard to calculate continued fractions? All of that messy double-
> precision arithmetic would be buried inside of CF where it would be
> out of the way.

 From Starting Forth:

Handy Table of Rational Approximations to Various Constants

Number          Approximation         Error

π = 3.141 ...   355 / 113            8.5 x 10-8

π = 3.141 ...   1068966896 / 340262731 3.0 x 10-18

√2 = 1.414 ...  19601 / 13860        1.5 x 10-9

√3 = 1.732 ...  18817 / 10864        1.1 x 10-9

e = 2.718 ...   28667 / 10546        5.5 x 10-9

√10 = 3.162 ... 22936 / 7253         5.7 x 10-9

12√2 = 1.059 ... 26797 / 25293       1.0 x 10-9

log(2) / 1.6384 = 0.183 ... 2040 / 11103 1.1 x 10-8

ln(2) / 16.384 = 0.042 ... 485 / 11464 1.0 x 10-7

All done on a 16-bit Forth in 1980, without DUM/MOD.

The reason it's not in the standard is that it's rarely needed.  Folks 
already complain that the standard has too many words in it.  Those that 
get added are words that are used often enough that a lot of systems 
have seen fit to include them.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

Hugh Aguilar wrote:
> On Nov 23, 12:27 pm, Jonah Thomas <jethom...@gmail.com> wrote:
>> ... the default in liberal circles is that if a member of
>> a minority -- black, woman, gay, inuit, latino, etc -- says that you
>> have offended him/her, people will mostly assume you are at fault.
>> That's just how it works.
> 
> I'm well aware of the importance of minding my own business. Let me
> tell a story:

[story snipped]
> 
> ...If I hadn't warned him, that poor fool would have
> remained upstairs in the nonfiction section unaware of how much danger
> he was in , right up to the moment when the police put the handcuffs
> on him. He would likely be charged with "inappropriate sexual contact
> with a minor," which is a felony. The end result would likely be that
> the woman would drop the charges against him in exchange for a large
> cash settlement. This is the kind of thing that happens to people who
> don't mind their own business.

Maybe, unless someone who witnessed the incident was willing to tell the 
policeman what actually happened, which is what I would have done.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

Anton Ertl wrote:
>>xbigforth: 6500kB (MINOS compiled on bigForth, with several shared
>>libraries, ttf fonts, caches from the font renderer, etc.)
>>xvfxlin: 29548kB (MINOS compiled on VFX, all other things identical).
>>
>>This can be neither explained by the 8MB more from vfxlin than from
>>bigForth, nor by the larger executable (1.2MB instead of 550kB).
> 
> Take a look at /proc/$pid/maps before and after loading MINOS.

That's a saved image, with MINOS preloaded.  On the computer here at 
home, the difference looks a lot more consistent - 6192kB for xbigforth, 
14060kB for xvfxlin, close to the difference between bigforth and 
vfxlin.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

On Nov 23, 1:38=A0pm, stephen...@mpeforth.com (Stephen Pelc) wrote:
> On Mon, 23 Nov 2009 09:54:35 -0800 (PST), Hugh Aguilar
>
> <hugoagui...@rosycrew.com> wrote:
> >I apologize for the use of the word "faggot"
>
> And so you bloody well should. It's been offensive for the last
> 30+ years.

One of my cab customers refers to himself as a "gay boy." Would that
be offensive? The problem is that there aren't any words for the
subject that can't be used with mal-sentiment. In regard to that
customer btw, he thanked me at the end of the trip for not making any
snide remarks about the way that he was dressed, so I gave him my
phone number and told him to call me directly the next time he needs a
cab, rather than go through the dispatch service. Cab driving is all
about money after all, and developing regular customers is better than
relying on the luck of the dispatch.

> Let's look at the post that triggered your assumptions:
>
> > It's the difference between me
> > mumbling to my partner to pass me the salt at dinner ("salt") to a
> > more formal, verbose, and explicit expression ("Phillip, would you
> > please pick up the salt and hand it to me?"). =A0The result is exactly
> > the same-- my blood pressure increases because I get too much
> > sodium.
>
> That was a constructed example. Just as it was popular to use
> "hers" instead of "his" for a while in order to be gender neutral,
> so you fell into a trap. Perhaps it was a deliberate trap, but
> you fell into it and exposed yourself. Now you need to apologise
> for the sentiment, not just the word.

What sentiment? I asked him if he was trying to tell us that he is an
xxx. It was a question, not a sentiment. Also, I have yet to get an
answer. People such as yourself have gone ballistic --- I even got
called an a**hole by one guy --- but it is possible that John
Passaniti didn't care. If it was a deliberate trap, it was people such
as yourself who fell into the trap by becoming emotionally involved. I
didn't fall into any trap because I haven't become emotionally
involved.

> The safe thing
> to do is not go outside the remit of this group.

I don't even know what the "remit of this group" is. Your vocabulary
is beyond me.

> If you really want to deconstruct postings, please study semiology,
> linguistics and anthropology.

I don't know what semiology is either. Forth programming sure is
getting complicated these days.

Hugh Aguilar wrote:
> On Nov 23, 1:38 pm, stephen...@mpeforth.com (Stephen Pelc) wrote:
....
>> Let's look at the post that triggered your assumptions:
>>
>>> It's the difference between me
>>> mumbling to my partner to pass me the salt at dinner ("salt") to a
>>> more formal, verbose, and explicit expression ("Phillip, would you
>>> please pick up the salt and hand it to me?").  The result is exactly
>>> the same-- my blood pressure increases because I get too much
>>> sodium.
>> That was a constructed example. Just as it was popular to use
>> "hers" instead of "his" for a while in order to be gender neutral,
>> so you fell into a trap. Perhaps it was a deliberate trap, but
>> you fell into it and exposed yourself. Now you need to apologise
>> for the sentiment, not just the word.
> 
> What sentiment? I asked him if he was trying to tell us that he is an
> xxx. It was a question, not a sentiment. Also, I have yet to get an
> answer. People such as yourself have gone ballistic --- I even got
> called an a**hole by one guy --- but it is possible that John
> Passaniti didn't care. If it was a deliberate trap, it was people such
> as yourself who fell into the trap by becoming emotionally involved. I
> didn't fall into any trap because I haven't become emotionally
> involved.
> 
>> The safe thing
>> to do is not go outside the remit of this group.
> 
> I don't even know what the "remit of this group" is. Your vocabulary
> is beyond me.

He means that John's example wasn't about his sexual orientation, it was 
about communication and causality, and your question was (in addition to 
being offensively phrased) wasn't relevant to the discussion or to 
Forth.  Whether "partner" in that context meant life partner, business 
partner, or tennis partner is irrelevant to the example.  Your question 
shouldn't have been asked, and isn't worth being discussed further.

John is wisely staying out of it and letting other fight his battles for 
him.

This group is about Forth.  Stick to that subject and don't raise 
personal issues.

Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

Hugh Aguilar <hugoaguilar@rosycrew.com> wrote:
> stephen...@mpeforth.com (Stephen Pelc) wrote:
> > Hugh Aguilar

> > >I apologize for the use of the word "faggot"
> >
> > And so you bloody well should. It's been offensive for the last
> > 30+ years.

> > Let's look at the post that triggered your assumptions:
> >
> > > It's the difference between me
> > > mumbling to my partner to pass me the salt at dinner ("salt") to a
> > > more formal, verbose, and explicit expression ("Phillip, would you
> > > please pick up the salt and hand it to me?"). =A0The result is
> > > exactly the same-- my blood pressure increases because I get too
> > > much sodium.
> >
> > That was a constructed example. Just as it was popular to use
> > "hers" instead of "his" for a while in order to be gender neutral,
> > so you fell into a trap. Perhaps it was a deliberate trap, but
> > you fell into it and exposed yourself. Now you need to apologise
> > for the sentiment, not just the word.
>=20
> What sentiment? I asked him if he was trying to tell us that he is an
> xxx. It was a question, not a sentiment. Also, I have yet to get an
> answer. People such as yourself have gone ballistic --- I even got
> called an a**hole by one guy --- but it is possible that John
> Passaniti didn't care. If it was a deliberate trap, it was people such
> as yourself who fell into the trap by becoming emotionally involved. I
> didn't fall into any trap because I haven't become emotionally
> involved.

You have offended multiple people. You are in a hole and you continue to
dig.

Unless you feel like you win by offending people and then believing that
they are irrational and wrong and you are right, you have no way to win
at what you're doing. You can't even break even. You'd do far better to
apologise and then talk about Forth.=20

It may be a historical accident that Forthers tend to stand up for
minorities rather than be all homophobic. I don't see anything
fundamental about Forth that would make it that way. But still that's
the way it is. At least some of us feel like your questions about John's
personal life are offensive, far more than John's own comments about his
personal life. You could say that we're irrational and prejudiced and
narrow-minded and stuck in conventional roles, but that won't impress us
much. We do Forth, and this newsgroup is about Forth.

If you're stuck in the wrong hole, stop digging.

On Nov 22, 11:23=A0pm, Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
> I recently ported my symtab.factor program to Forth (and fixed a bug
> in it). You couldn't figure out symtab last time I posted it, but
> maybe you'll get it this time. Here is the Factor version again:
>
> http://www.rosycrew.com/symtab.factor

I would prefer that you revert the code back to what I casually
reviewed and *then* tell me precisely what I got wrong.  Note the word
"precisely"

> > 2. =A0The language would use a typed stack. =A0[...]
>
> This will never be implemented in Forth --- the result wouldn't be
> Forth any more.

The problem is that you didn't bother to read the entire message
(although amusingly, you quote from it).  I wasn't describing a change
to Forth.  As I wrote, Forth is fine as it is.  The only problems with
Forth are in the community, not the language.  What I was describing
were ideas for a separate scripting language.  Scripting languages are
necessarily higher-level languages than Forth, and the ideas I listed
applied to that language, not Forth.  I made that explicit at least
twice.

> > 3. =A0The primary means of extending the language would be through hook=
s
> > that the programmer could change. =A0These hooks could (as in Lua) be
> > stored in just another associative array that is set on a particular
> > value. =A0For example:
>
> This has been in Forth since the 1970s. Lua doesn't have anything on
> Forth in this regard.

Then you don't know Lua.  Lua's metatable mechanism provides the hooks
I'm talking about, and exists per-value.  There is no equivalent in
Forth.

> BTW, you said that your "partner" is "Phillip." Are you trying to tell
> us that you're a faggot?

I referenced my partner in a casual remark to illustrate a point about
language.  That point was independent of my partner's gender, so no,
the point was not declare my sexuality any more than if I had a wife
and used her name in the same casual remark.  And while I have no
particular interest in using programming language newsgroup to discuss
my sexuality, I also will not be monitoring my words to carefully
shield people like yourself with an apparently inordinate interest in
the incidental details of others.

On Nov 23, 4:44=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> >Every now and then in this newsgroup, you've undoubtedly read that a
> >simple "hello world" program compiled in C can generate an executable
> >image that's a megabyte or more.
>
> I haven't. =A0Looks like a straw man to me.

Amusing.  I wrote that to make the point that people quoting sizes
often don't know what they're measuring, and further that they often
compare apples to oranges.  And that's exactly what you did.

I compared the size of Lua used as a stand-alone language in an
embedded system.  You compared the sizes of various scripting
languages used on top of an operating system.  The majority of the RSS
sizes you quoted have little to do with the language and instead are
the result of the grotesquely huge glibc and language libraries that
may not even be relevant in a stand-alone system (for example, if
you're not on top of an OS, it doesn't make much sense to include the
size of libraries that interact with an OS that isn't there).  If you
wanted a more meaningful comparison, you would have linked against
something like uClibc, dietlibc, or other stripped down C library
typically used in embedded systems.

On Nov 23, 12:54=A0pm, Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
> Let's all of us agree that it is inappropriate to bring up issues such
> as John Passaniti brought up. This is true on c.l.f., and within any
> polite society.

Then I assume that in the future when someone casually mentions they
have a husband or wife, you will be complaining about that too?

Sorry that you over react to incidental data about others here.  Maybe
one day you can find a way to overcome it.

On Nov 23, 2:12=A0pm, Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
> People are always telling me things that I don't need to know.

Just as you've used comp.lang.forth to tell us you're a cab driver and
other random details about your life.

You're free to be a hypocrite.  We're free to point it out.

On Nov 23, 2:27=A0pm, Jonah Thomas <jethom...@gmail.com> wrote:
> John Passaniti has a unique viewpoint that makes him valuable here in
> spite of his abrasive manner. If it comes to an argument about whether
> it's worse for him to talk about his sex live or worse for you to tell
> him you don't want to hear it, people here will tend to protect the
> persecuted minority rather than side with the prejudiced one.

Wow, I really didn't realize that mentioning my partner passing me
salt at dinner was an exploration of my sex life.  Fascinating!  And
if you found that racy, then this is going to blow your mind: tonight,
he asked me to feed the cat because he was busy raking leaves in the
yard.  Wow!  Shocking!  Will comp.lang.forth ever be the same with all
this sexual detail?

On Nov 24, 8:48=A0am, John Passaniti <john.passan...@gmail.com> wrote:
> On Nov 23, 2:27=A0pm, Jonah Thomas <jethom...@gmail.com> wrote:
>
> > John Passaniti has a unique viewpoint that makes him valuable here in
> > spite of his abrasive manner. If it comes to an argument about whether
> > it's worse for him to talk about his sex live or worse for you to tell
> > him you don't want to hear it, people here will tend to protect the
> > persecuted minority rather than side with the prejudiced one.
>
> Wow, I really didn't realize that mentioning my partner passing me
> salt at dinner was an exploration of my sex life. =A0Fascinating! =A0And
> if you found that racy, then this is going to blow your mind: tonight,
> he asked me to feed the cat because he was busy raking leaves in the
> yard. =A0Wow! =A0Shocking! =A0Will comp.lang.forth ever be the same with =
all
> this sexual detail?

Personally, I'm on the edge of my seat! You'll be telling us you
washed the dishes next!

I can't stand it ;-)

On Nov 24, 8:48=A0am, John Passaniti <john.passan...@gmail.com> wrote:
> On Nov 23, 2:27=A0pm, Jonah Thomas <jethom...@gmail.com> wrote:
>
> > John Passaniti has a unique viewpoint that makes him valuable here in
> > spite of his abrasive manner. If it comes to an argument about whether
> > it's worse for him to talk about his sex live or worse for you to tell
> > him you don't want to hear it, people here will tend to protect the
> > persecuted minority rather than side with the prejudiced one.
>
> Wow, I really didn't realize that mentioning my partner passing me
> salt at dinner was an exploration of my sex life. =A0Fascinating! =A0And
> if you found that racy, then this is going to blow your mind: tonight,
> he asked me to feed the cat because he was busy raking leaves in the
> yard. =A0Wow! =A0Shocking! =A0Will comp.lang.forth ever be the same with =
all
> this sexual detail?

Personally, I'm on the edge of my seat! You'll be telling us you
washed the dishes next!

I can't stand it ;-)

On Tue, 24 Nov 2009 06:38:15 +1000, Stephen Pelc <stephenXXX@mpeforth.com>  
wrote:

> On Mon, 23 Nov 2009 09:54:35 -0800 (PST), Hugh Aguilar
> <hugoaguilar@rosycrew.com> wrote:
>
>> I apologize for the use of the word "faggot"
>
> And so you bloody well should. It's been offensive for the last
> 30+ years.
>
> Let's look at the post that triggered your assumptions:
>> It's the difference between me
>> mumbling to my partner to pass me the salt at dinner ("salt") to a
>> more formal, verbose, and explicit expression ("Phillip, would you
>> please pick up the salt and hand it to me?").  The result is exactly
>> the same-- my blood pressure increases because I get too much
>> sodium.
>
> That was a constructed example. Just as it was popular to use
> "hers" instead of "his" for a while in order to be gender neutral,
> so you fell into a trap. Perhaps it was a deliberate trap, but
> you fell into it and exposed yourself. Now you need to apologise
> for the sentiment, not just the word.
>
> This is a technical newsgroup. There are probably people of
> genders and sexualities that you know nothing about in this
> group. What you did was to extrapolate beyond reason and be
> offensive in public. That makes it your shame. The safe thing
> to do is not go outside the remit of this group. Note also
> that your political rants are likely to be offensive to a
> portion of this group. At present, you bring cab drivers into
> disrepute.
>
> If you really want to deconstruct postings, please study semiology,
> linguistics and anthropology. At present, you know know nothing
> about the personal lives of the people who post here. They are
> not your business.
>
> Stephen
>
>

I deal with a lot of bloody minded people, including around here (their  
interest is offensive not progressive, not truthful, to an extent not  
whatever good).   (Usually you have to justify yourself, and most often  
the truth, in respect to this behavior, often in relevance to them  
justifying some lie or their ego etc).  What was said is over the top, and  
offensive etc as people have described here.  As for the other statements,  
we could, in the same way, if we wanted to, lump all cab drivers together  
as wrongly automatically assuming that just because somebody shares  
something they 'must' be something wrong with them, suspicious etc, when  
they were just being friendly, as being whatever...  Also, I notice a lot  
of justification, and you could have testified that the woman was likely  
lying and that the librarian knew all about it.  if the police had any  
sense (don't assume) or could view security footage they would have dumped  
it, maybe given her a warning, though I doubt they would go as far a to  
investigate and question arresting her for false statements etc, but the  
world isn't perfect.  Now, if they want to do the right thing (not saying  
they would bother), they have to waste time tracking down and  
investigating all the potentially false statements rather then settling it  
on the spot, with one mans testimony against the testimony of a whole  
bunch of youths and an irate mother that is claiming a whole bunch of new  
stuff.  If he is not guilty he might choose to power walk away to get away  
 from being set up ;) .  I fully sympathize with your viewpoint in the  
library, but the law is a wonderful thing, if used properly it can result  
in these things being ten times less likely to happen, but it is too much  
to make up all worlds inadequacies.

If this was a troll, my hat off too you, the subsequent statement was so  
good that even I responded to it (as genuine).
-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

On Mon, 23 Nov 2009 17:01:06 +1000, John Passaniti  
<john.passaniti@gmail.com> wrote:

> On Nov 22, 2:39 am, Elizabeth D Rather <erat...@forth.com> wrote:
>> What is the actual footprint of a typical Forth vs. other scripting
>> languages?
>
> Every now and then in this newsgroup, you've undoubtedly read that a
> simple "hello world" program compiled in C can generate an executable
> image that's a megabyte or more.  This causes great delight by
> Forthers until someone (such as myself) points out that size is not
> just the executable code, but tables providing references to
> dynamically linked libraries, symbol tables used for debuggers,
> padding for the OS loader, and other whatnot.

I agree, you would need a better OS and machine architecture to take  
advantage of it.  Outside of precess information on my original VOS  
information, there was no overhead.


Thanks


Wayne.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

John Passaniti <john.passaniti@gmail.com> writes:
>On Nov 23, 4:44=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> >Every now and then in this newsgroup, you've undoubtedly read that a
>> >simple "hello world" program compiled in C can generate an executable
>> >image that's a megabyte or more.
>>
>> I haven't. =A0Looks like a straw man to me.
>
>Amusing.  I wrote that to make the point that people quoting sizes
>often don't know what they're measuring, and further that they often
>compare apples to oranges.

Which people?  Are you talking about yourself in third person?

>  And that's exactly what you did.

Where did I compare apples to oranges?  Or if you think I don't know
what I am measuring, please enlighten me.

>I compared the size of Lua used as a stand-alone language in an
>embedded system.

And I did not comment on that part, so this is a red herring.

>You compared the sizes of various scripting
>languages used on top of an operating system.  The majority of the RSS
>sizes you quoted have little to do with the language and instead are
>the result of the grotesquely huge glibc and language libraries

The contribution of glibc to the RSS is always the same for all the
languages involved; and that contribution is at most 368KB (a small
program doing only getchar() has an RSS of 376KB, and 8KB of that
comes from the code and data sections of this program.  So if you
prefer not to count glibc, glibc does not change the differences of
the RSS sizes.  bigForth has a larger footprint than lua 4.0, and
glibc does not change that.

I am not sure what you mean with the language libraries, but if the
language implementations load them by default, why shouldn't we count
them when determining their footprint.

>If you
>wanted a more meaningful comparison, you would have linked against
>something like uClibc, dietlibc, or other stripped down C library
>typically used in embedded systems.

Why should such a comparison be more meaningful than the one I made?

IMO such a comparison is less meaningful, because most people use
Python, Ruby, Gforth, or vfxlin on a general-purpose computer.  But
wrt RSS, the difference will only be a constant offset anyway.

- 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.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

Hugh Aguilar <hugoaguilar@rosycrew.com> wrote:
> On Nov 23, 11:40 am, Elizabeth D Rather <erat...@forth.com> wrote:
> > Hugh Aguilar wrote:
> > > Let's all of us agree that it is inappropriate to bring up issues such
> > > as John Passaniti brought up. This is true on c.l.f., and within any
> > > polite society.
> >
> > Would it be "inappropriate" for me to mention my husband?  It was wildly
> > inappropriate for you to have commented on John's remark, particularly
> > in such an offensive way.  You are at fault here, not John.
> 
> Unless he's a Forth programmer, then yes, it would be.

Obviously you did not notice that John mentioned his partner as
part of real life example in order to illustrate a point about
the role of syntax. That was the issue he was dealing with.

> 
> People are always telling me things that I don't need to know.

That is a very good line. Include it in your sig.

-- 
Marc

On Nov 24, 12:59=A0pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> > =A0And that's exactly what you did.
>
> Where did I compare apples to oranges? =A0Or if you think I don't know
> what I am measuring, please enlighten me.

If someone told you language X took 24k and language Y took 2400k,
what *useful* conclusions could you make from that statement about the
two languages?  Aside from the obvious and trivial (Y is bigger), you
can't make any useful conclusions from knowing those sizes.  Language
X could be hosted on a small 8-bit microcontroller and have only bare-
minimum features while Language Y could be hosted on a 64-bit
processor on top of Windows and have compiled-in support for operating
system, sound, graphics, regular expressions, arbitrary precision
math, HTTP, XML, bindings to databases, a full-featured debugger, a
JIT compiler, compression and cryptology libraries, etc.

Comparing one language to another based on nothing but size is
meaningless; you need more context to know what the sizes are
measuring.  And I'm going to bet that when Elizabeth asked about the
size of Forth compared to scripting languages, she wasn't interested
in meaningless numbers.  Since her primary experience seems to be in
embedded systems, it certainly seems that comparing Forth to scripting
languages in a domain she's experienced in would be maximally useful
to her.  I know that's a totally insane premise, but let's roll with
it.

So I started there.  In the interest of comparing like to like, I
started the an embedded system domain.  That's justified because the
predominate domain for Forth is embedded systems.  That then limits
what scripting languages we would compare.  You wouldn't toss in
numbers for PHP because it's not used in embedded systems work.  Perl
and Ruby also are rarely see in embedded systems.  Lua and Python are,
but I didn't have meaningful numbers for Python.  So I focused on
Lua.  Lua is also useful for considering because the base libraries
that come with the language are of similar scope to the ANS Forth
optional wordlists, so again, we're comparing like to like.

> I am not sure what you mean with the language libraries, but if the
> language implementations load them by default, why shouldn't we count
> them when determining their footprint.

Because it's somewhere between meaningless and misleading.  Tell me,
when you quoted the sizes of the scripting languages, did you
download, configure, and compile each one?  If not, how much of the
size of those languages' libraries comes from the defaults and how
much comes from the package maintainers' choices when packaging the
languages?  And for the languages that dynamically load libraries at
run time, how much of those sizes comes from prerequisite libraries
being loaded to satisfy some application you installed on your system?

There is also the issue of including libraries that simply don't make
sense.  My numbers were for an x86 embedded system without an
operating system.  So when you quote numbers for languages that offer
things either dependent on an operating system or which bind to other
applications (like databases), then you've got inflated numbers that
don't mean anything.

> >If you
> >wanted a more meaningful comparison, you would have linked against
> >something like uClibc, dietlibc, or other stripped down C library
> >typically used in embedded systems.
>
> Why should such a comparison be more meaningful than the one I made?

Because it's more representative.  If we're talking about an embedded
system that does run an operating system (such as Linux) then you
should be comparing against standard C libraries that are used in
embedded systems-- such as uClibc and dietlibc.  Again, comparing like
to like.

> IMO such a comparison is less meaningful, because most people use
> Python, Ruby, Gforth, or vfxlin on a general-purpose computer. =A0But
> wrt RSS, the difference will only be a constant offset anyway.

And to me the comparison is meaningless because we aren't talking
about "most people."  The specific person who asked the question is
Elizabeth, and her primary experience, her company's primary
experience, and the experience she talks about most often in this
newsgroup is clearly embedded systems.

On Nov 23, 8:52 pm, Elizabeth D Rather <erat...@forth.com> wrote:
> John is wisely staying out of it and letting other fight his battles for
> him.

This is pretty much the problem with liberals --- that they always
want to fight other people's battles for them, and they never ask
those people for permission to do this.

A good example is affirmative action. The minority people themselves
never asked for this, and it is an embarrassment to them because it
implies that they aren't capable of succeeding on their own merits. In
my estimation, the liberals who promote affirmative action are the
true racists because of their assumption that minority people are
inherently inferior. When the liberals see, for example, a Mexican
computer-programmer, they will say: "Affirmative action is a great
thing because it allows even a stupid Mexican such as yourself to work
as a computer programmer; if it wasn't for us heroic liberals, you
would be a field laborer, because that is the only work you are
qualified to do." If the programmer insists that he got where he is on
his own merits, the liberals will say: "No, affirmative action is the
law of the land; you were given lower requirements in college whether
you wanted them or not." All of this is despite the fact that the guy
in question knows how to program computers, and the liberals involved
don't typically know anything about computers.

This is the same attitude that I see in regard to John Passaniti; you
are fighting his battles for him on the assumption that he is too weak
to stand up for himself. Who asked you to get involved?

Consider Mark Willis who called me an a**hole? Who looks foolish here?
Not me. Not John Passaniti either. Neither one of us has become
emotionally involved, which is always a prerequisite to looking
foolish.

Consider Stephen Pelc who told me to apologize *and* go away. Why is
he so enthusiastic about defending the gay community? I think the
reason is because I criticize ANS-Forth, and he makes his living
selling an ANS-Forth compatible compiler. Eventually I am going to end
up writing my own Forth compiler in competition with MPE. If :NAME is
idiomatic in my compiler, and CREATE DOES> is idiomatic in MPE, then
programmers are going to abandon MPE in favor of mine because :NAME is
vastly better technology. The same thing is true in regard to
continued fractions, which is supposedly the topic of this thread ---
ANS-Forth doesn't provide adequate support, but any compiler that I
write certainly will. This is why Mr. Pelc wants me to go away. He
doesn't care about John Passaniti's feelings. Most likely, the only
person on the planet who does care about John Passaniti's feelings is
Phillip --- and only on good days. :-)

Consider the library incident that I described. You said that you
would present yourself to the police as an eyewitness and tell them
what "really happened." Did the man ask you to do this? Your testimony
of what really happened would certainly include the statement: "The
man shouted, 'Don't you flip me off!,' and he took a step toward the
boy." That would pretty much seal the case for a charge of
"threatening and intimidation," which is a misdemeanor. Considering
the age of the victim however, the charge would certainly be upgraded
to a felony. Any testimony that you make in regard to extenuating
circumstances is going to be left out of the arrest report --- only
that one statement will be included. Believe me, I've been
interrogated by the police many times (I called them on somebody who
was making trouble for me), and I know that a witness has to be very
circumspect about what is said to the police. If you just vaguely
believe "the truth will out," then you are badly out-classed and you
are likely to screw everything up --- maybe even badly enough that you
get arrested too. When that man gets convicted, he is not going to
thank you for getting involved --- he is going to point out that he
never asked for your help, and that you made the situation worse
rather than better.

This is what being a liberal is all about --- getting involved in
situations that aren't any of your business and making them worse
rather than better.

Hugh Aguilar wrote:
> On Nov 23, 8:52 pm, Elizabeth D Rather <erat...@forth.com> wrote:
>> John is wisely staying out of it and letting other fight his battles for
>> him.
> 
> This is pretty much the problem with liberals --- that they always
> want to fight other people's battles for them, and they never ask
> those people for permission to do this.

Wait, weren't you the one asserting that if something wasn't directly 
related to Forth it should't be discussed here?

Follow your own advice.

Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

On Nov 24, 4:56=A0pm, Elizabeth D Rather <erat...@forth.com> wrote:
> Hugh Aguilar wrote:
> > On Nov 23, 8:52 pm, Elizabeth D Rather <erat...@forth.com> wrote:
> >> John is wisely staying out of it and letting other fight his battles f=
or
> >> him.
>
> > This is pretty much the problem with liberals --- that they always
> > want to fight other people's battles for them, and they never ask
> > those people for permission to do this.
>
> Wait, weren't you the one asserting that if something wasn't directly
> related to Forth it should't be discussed here?
>
> Follow your own advice.

That's fine with me. I started another thread discussing my symtab
program. I say that my algorithm is good original work, but John
Passaniti says that it is neither. John Passaniti's supporters, both
numerous and ardent, can go over there and pitch in --- but keep the
thread focused on the technical merits (if any) of symtab.

To the best of my recollection, John Passaniti never commented on
continued fractions and/or DUM/MOD. If he doesn't care about that
issue, it is unlikely that he is even reading this thread anymore. He
seems to care mostly about scripting, which doesn't have anything to
do with integer arithmetic, and is IMHO better served by Factor than
Forth anyway. Maybe he should start a thread to discuss scripting
languages, but that is not the subject of this thread. Besides that,
you yourself discouraged me from discussing Factor in this forum, and
I am largely following your advice in this matter.

I definitely want to get this thread back to continued fractions. I
have made two suggestions so far:
1.) Introduce DUM/MOD into the standard.
2.) Introduce CF into the standard.

In my way of thinking, the standard should include low-level words
such as DUM/MOD in preference to high-level words such as CF. This is
more robust as words such as DUM/MOD may prove to be useful for
purposes other than supporting CF. The argument against this is that
DUM/MOD could be used for a variety of inappropriate uses (anything
that has to be fast), in which case it would cause more harm than
good. You have said that CF can be written using only mixed-precision
arithmetic, and without benefit of DUM/MOD. Well, I may not be from
Missouri, but I'll have to be shown this to believe it. Note that the
rational that CF takes as input has to be entered in double-precision.
There would be no point in entering the rational in single-precision
because getting it to fit in single-precision integers is what we are
trying to accomplish! If both the numerator and denominator are double-
precision, then we need some way of performing division with a double-
precision divisor. This seems to imply the need for DUM/MOD. Am I
wrong?

Hugh Aguilar wrote:
....
> I definitely want to get this thread back to continued fractions. I
> have made two suggestions so far:
> 1.) Introduce DUM/MOD into the standard.
> 2.) Introduce CF into the standard.
> 
> In my way of thinking, the standard should include low-level words
> such as DUM/MOD in preference to high-level words such as CF. This is
> more robust as words such as DUM/MOD may prove to be useful for
> purposes other than supporting CF. The argument against this is that
> DUM/MOD could be used for a variety of inappropriate uses (anything
> that has to be fast), in which case it would cause more harm than
> good. You have said that CF can be written using only mixed-precision
> arithmetic, and without benefit of DUM/MOD. Well, I may not be from
> Missouri, but I'll have to be shown this to believe it. Note that the
> rational that CF takes as input has to be entered in double-precision.
> There would be no point in entering the rational in single-precision
> because getting it to fit in single-precision integers is what we are
> trying to accomplish! If both the numerator and denominator are double-
> precision, then we need some way of performing division with a double-
> precision divisor. This seems to imply the need for DUM/MOD. Am I
> wrong?

Elsewhere in this thread, I posted some computed ratios, which were done 
by other people, but without adding any standard words.  Marcel updated 
the info with the fact that the extended-precision one was computed 
later, by Greg Bailey.  There are some links there.  Clearly this work 
has been done in the past, and DUM/MOD hasn't found its way into system 
facilities in any Forth I know of.  Nor has there been any demand for it 
recently, except from you.  I suggest you find and follow those links, 
there may be some code available.

I'm afraid I can't help further.  Others may wish to, if you haven't 
pissed them off too much.

Cheers,
Elizabeth


-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

On Tue, 2009-11-24 at 15:20 -0800, Hugh Aguilar wrote:
> they always want to fight other people's battles for them, and they=20
> never ask those people for permission to do this.

Bollocks. Needing help and being incapable are not the same thing. Quit
being a solipsist.

> A good example is affirmative action.=20

Er, no.

> The minority people

Where do they live? Minority city?

> themselves never asked for this, and it is an embarrassment to them becau=
se it
> implies that they aren't capable of succeeding on their own merits.

Translation: If you need help you are incapable. Sounds to me like
you're the one with associative biases.

> In my estimation,=20

Whose else would it be?

> the liberals who promote affirmative action are the
> true racists because of their assumption that minority people are
> inherently inferior.

As opposed to your assumption that anyone receiving help is inferior.=20

> "you would be a field laborer, because that is the only work you are
> qualified to do."=20

No dumbass. It's "because that is the only
BEGIN INSERTION -=20

work RACISTS THINK you

- END INSERTION

are qualified to do.

AND CONTINUING

Furthermore, to pull the minorities out of the hole that RACISTS put
them in, before their children HAVE TO suffer, not because anyone THINKS
they can't themselves, but BECAUSE IMPROVEMENTS HAVE TO HAPPEN BEFORE
FAMILIES SUFFER regardless of their ability."

> If the programmer insists that he got where he is on
> his own merits

FULL STOP Your premise is 540 degrees wrong therefore this beginning of=20
the sentence is absolute gibberish,

> , the liberals will say: "No, affirmative action is the
> law of the land; you were given lower requirements in college whether
> you wanted them or not."

and so is the above. Again you know so little about affirmative action.
It isn't primarily done through lowered standards but by higher quotas.
Some institutions choose to lower standards others promote their
offerings to more neighborhoods.

And some institutions are too bureaucratic to be able to be more
democratic therefore they are parasites on the community.

> All of this is despite the fact that the guy
> in question knows how to program computers, and the liberals involved
> don't typically know anything about computers.

Non-sequitur genus Salvador Dali.

> This is the same attitude that I see in regard to John Passaniti; you
> are fighting his battles for him on the assumption that he is too weak
> to stand up for himself. Who asked you to get involved?
>=20
> Consider Mark Willis who called me an a**hole? Who looks foolish here?
> Not me. Not John Passaniti either. Neither one of us has become
> emotionally involved, which is always a prerequisite to looking
> foolish.

You seem pretty emotionally involved by now.

> Consider Stephen Pelc who told me to apologize *and* go away. Why is
> he so enthusiastic about defending the gay community?

Because people still die in that community from abuse. Same with
negroes. It's not the INFERIORITY which seems to be your obsession. It's
the violent nature of discrimination. Every bit of support helps.

Maybe you're the one with the INFERIORITY complex.

> I think the
> reason is because I criticize ANS-Forth, and he makes his living
> selling an ANS-Forth compatible compiler.=20

It ain't about you. Now if Inigo Montoya can accept that, why can't you?

> then programmers are going to abandon MPE in favor of mine because :NAME =
is
> vastly better technology.

Still so not about you.

> This is why Mr. Pelc wants me to go away.

Not here either.

The below is so far the only bit that isn't contextually convoluted.

I'm surprised you managed to produce the paragraph below.

> Consider the library incident that I described. You said that you
> would present yourself to the police as an eyewitness and tell them
> what "really happened."

All investigations should begin with interviewing the primary parties.
Unfortunately eyewitness testimony is necessary.

> Did the man ask you to do this? Your testimony
> of what really happened would certainly include the statement: "The
> man shouted, 'Don't you flip me off!,' and he took a step toward the
> boy." That would pretty much seal the case for a charge of
> "threatening and intimidation," which is a misdemeanor. Considering
> the age of the victim however, the charge would certainly be upgraded
> to a felony.

Unintended consequences is why I would like so much to agree with you
except for the fact you base your arguments on your own hysterical
biases.

> Any testimony that you make in regard to extenuating
> circumstances is going to be left out of the arrest report --- only
> that one statement will be included.

They're employees of the corporate city. They make their rent by getting
stuff done.

> If you just vaguely believe "the truth will out,"

The sun always shines on TV.

> he is going to point out that he never asked for your help, and
> that you made the situation worse rather than better.

So right,

> This is what being a liberal is all about --- getting involved in
> situations that aren't any of your business and making them worse
> rather than better.

and so wrong. Sigh.

Name a politician, aside from Ron Paul, who doesn't do that.

Let's get back to the topic at hand.

John Passaniti <john.passaniti@gmail.com> writes:
>On Nov 24, 12:59=A0pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> > =A0And that's exactly what you did.
>>
>> Where did I compare apples to oranges? =A0Or if you think I don't know
>> what I am measuring, please enlighten me.
>
>If someone told you language X took 24k and language Y took 2400k,
>what *useful* conclusions could you make from that statement about the
>two languages?  Aside from the obvious and trivial (Y is bigger), you
>can't make any useful conclusions from knowing those sizes.  Language
>X could be hosted on a small 8-bit microcontroller and have only bare-
>minimum features while Language Y could be hosted on a 64-bit
>processor on top of Windows

Given that I compared the language implementations on the same
platform (actually the same machine), how is that relevant?  Looks
like another straw man to me.

>and have compiled-in support for operating
>system, sound, graphics, regular expressions, arbitrary precision
>math, HTTP, XML, bindings to databases, a full-featured debugger, a
>JIT compiler, compression and cryptology libraries, etc.

Features may be a reason that explains both size and popularity.  But
anyway, the question was about the footprint, not about features.

>And I'm going to bet that when Elizabeth asked about the
>size of Forth compared to scripting languages, she wasn't interested
>in meaningless numbers.

She can speak for herself.  She asked for the numbers, so I guess the
have some meaning for her.  If she needs more to make them meaningful,
she can ask.

>So I started there.  In the interest of comparing like to like, I
>started the an embedded system domain.  That's justified because the
>predominate domain for Forth is embedded systems.

The predominant domain of scripting languages is general-purpose
systems.  That's the domain where a number of scripting languages are
more popular than Forth, and if we want to know why, we have to look
there.  And looking at the results, being big is obviously no
hindrance to becoming popular.

>Because it's somewhere between meaningless and misleading.  Tell me,
>when you quoted the sizes of the scripting languages, did you
>download, configure, and compile each one?  If not, how much of the
>size of those languages' libraries comes from the defaults and how
>much comes from the package maintainers' choices when packaging the
>languages?

Who cares.  These are the versions that most Debian users actually
use.  If you think that the sizes for other platforms will be
substantially different, please post them.  Why would the size of some
hand-configured version be more relevant IYO?

>> >If you
>> >wanted a more meaningful comparison, you would have linked against
>> >something like uClibc, dietlibc, or other stripped down C library
>> >typically used in embedded systems.
>>
>> Why should such a comparison be more meaningful than the one I made?
>
>Because it's more representative.

Of what?  Of how people use Ruby, bash, Python and even Lua?  Hardly.

- 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.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

Hugh Aguilar <hugoaguilar@rosycrew.com> wrote:

> This thread started out by discussing continued fractions. These are
> absolutely necessary for integer arithmetic (for use in */ and M*/),
> and integer arithmetic is obviously the mainstay of embedded micro-
> controller work. The point I was making is that I normally have to use
> a 32-bit system to calculate rationals for a 16-bit system, or use a
> 64-bit system to calculate rationals for a 32-bit system. Forth would
> make a lot more sense if I could use the same system for calculating
> rationals as the system that I'm going to be using the rationals on.
> All we need is DUM/MOD. Even if it were slow this wouldn't bother me
> too much, as it is primarily used at compile-time. I can think of
> cases in which it would be used at run-time (implementing a Factor-
> like rational data type), but none of these cases involve embedded
> micro-controllers, so the inherent speed issue shouldn't be much of a
> practical problem.

You don't need it.

http://groups.google.co.jp/group/comp.lang.forth/msg/6fa4e33f552ca10a

Note that when you get a continued fraction for pi the issue is not that
you have a continued fraction for pi. What you will do with it is
multiply it by stuff. And the best continued fraction is the one that
gives you the right product the most times, with perhaps some other
properties like you might want the error to be low half the time and
high half the time. 

But ignoring all that, if you want to see how good n * a / b is, you can
take the original double-precision x and multiply it by the
single-precision n to get a triple-precision product. Then you divide by
the single-precision b to get a double-precision quotient. Then you take
the low cell and use it to decide whether to round the high cell up or
down. That single-precision result is what you compare n * a / b by to
see whether it's perfect or off by one. If it's off by more than one
then you don't have a very good continued fraction yet.

Check whether I got the details right, it's early for me and I could
have them all wrong. But the basic idea I'm sure is right. After you do
*/ you will have a single-precision result. Is that the best
single-precision result or is it off? To find out, you might as well
start with your high-precision "correct" form and calculate the best
single-precision result that you will compare against. I don't think
this needs DUM/MOD .

Note that */ does not round, it truncates. I think this will throw a
systematic bias into your results. Continued fraction methods give you
the best result with rounding, and this does not round. So something
other than the best continued fraction might be what you want. I could
be wrong about this too.

It seems to me that on average, you could hope for a continued fraction
pair that gives you the best single-precision result about half the
time, and gives you a result that is 1 bit low 1/4 the time and a result
that is 1 bit high 1/4 the time. Or, since there are so many continued
fraction pairs to choose from, maybe you could get one that gives you
the correct result much more than half the time and still makes the
errors high or low about equally. For 16 bits you can easily do an
exhaustive search and find the best pairs completely by brute force. For
32 bits it's harder....

Ian Osgood <iano@quirkster.com> writes:
>For the last few personal text-whacking tasks, I *did* reach for Forth
>after trying to learn AWK and regex, and I managed to get the job done
>without much effort.  The Forth string wordset is pretty much on par
>with the <string.h> C standard library, plus/minus a few things.  I
>find the addr-len abstraction to be a pretty convenient and efficient
>means to reference substrings in large text, compared to the null-
>termination requirement for handling C-strings, which often requires
>an unnecessary string copy.

Yes.  I actually know awk and regexps, and use them regularly, but
there are cases where I use Forth, e.g., in the repost program:
http://www.complang.tuwien.ac.at/forth/programs/repost.fs

Here I used Forth, because I don't know how to deal with sockets in
awk.

>Another convenience is using the
>dictionary space (or PAD) as a large anonymous text buffer for lines
>or entire files.

I don't do that.  Instead, for files I use SLURP-FILE, and for
constructing strings I use S+ and APPEND (which work with ALLOCATE).

>One of the factors I kept reinventing for text processing tasks was
>the SPLIT word (either by character, string, or "match" predicate).

Yes, I have a SPLIT-ARTICLE in the repost program and another case
that I did not factor out where I dealt with lines starting with ".".

>A big area which helps modern scripting languages succeed is their
>library integration. Perl has its module system and CPAN. Python has
>"batteries included". Shell scripting has the rich UNIX toolset and
>pipes to plug them together.  Forth would need a similar library
>system to really succeed as a scripting language. This is partially a
>technical problem but mostly a social problem.

Yes.

- 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.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

Elizabeth D Rather <erather@forth.com> writes:
>Anton Ertl wrote:
>> Elizabeth D Rather <erather@forth.com> writes:
>>> Uwe Klo� wrote:
>>>> What do other languages have, that Forth has not?
>>> An organization behind them that is either large, well-funded, or both.
>> 
>> I very much doubt that this is the decisive factor.  Ok, it made Java
>> widely known quickly, but that's rather the exception.  I am not aware
>> of particular organizational support for Python, Ruby, or Perl (just
>> to name a very few popular languages mentioned in this thread).
>
>Python: Originally developed at CWI (National Research Institute for 
>Mathematics and Computer Science) in the Netherlands by Guido van 
>Rossum.  This seems similar to Chuck Moore's early work on Forth at 
>NRAO, with the difference that CWI actively encouraged publication and 
>work on it, since its interests included computer science.  NRAO 
>regarded Forth as a distraction, and actively discouraged its promotion. 
>  Van Rossum subsequently moved to Corporation for National Research 
>Initiatives (CNRI) in Reston, VA, which continued to support his work. 
>Chuck became frustrated with NRAO, and he and I formed FORTH, Inc., 
>where we struggled with no corporate backing whatever, only what we 
>could earn with various programming projects.
>
>Perl: Larry Wall began work on Perl in 1987, while working as a 
>programmer at Unisys, which (like CWI) supported his work and 
>publications.  Any paper on a language or similar development from an 
>organization like Unisys (which at the time was well-known and highly 
>respected in the computer industry) will inevitably get more respect 
>than a paper from a microscopic company no one ever heard of (e.g. 
>FORTH, Inc.).
>
>Ruby: It's history is interesting, because it is more of an individual 
>effort without institutional backing in the early days.

They all seem very individual to me.  The "institutional backing" is
just that they let these people work on these languages, not more.

Anyway, Forth became quite popular in the 70s and 80s, and at some
point a number of people worked on Forth at big institutions with that
amount of backing.  E.g., John Hayes and Marty Fraeman at Johns
Hopkins University.  Or Mitch Bradley at Sun.  When Python started,
Forth had more of this kind of institutional support than Python.  If
that was the decisive Factor, Forth would have won.

>Matsumoto based 
>his work (in the 1990's) on existing popular languages (Perl, Smalltalk, 
>Eiffel, Ada, and Lisp), and was able to capitalize on both their 
>popularity & familiarity as well as the Internet (Japanese newsgroups). 

And we have had Forth newsgroup for a longer time than Ruby existed,
so that cannot be the decisive factor, either.

>  Here the contrast is that Forth was a *departure* from familiar and 
>popular programming paradigms.

I think that is a decisive factor.

>Instead of the Internet, Forth promotion 
>in the 80's relied on print publications such as Byte and Dr. Dobbs, 
>which editorially butchered programming examples, thus feeding the 
>perception of unreadability.

And yet, it became somewhat popular.

>> And if the size and funds of the supporting organization were the
>> decisive factor, everyone would program in Ada.  Yet, looking at the
>> popularity in Usenet, Ada is usually about as popular as Forth.
>
>It quickly became the perception that Ada projects required budgets of 
>$1M+, which tends to put a damper on acceptance!

Yes, but that's probably because of the institutional backing.  So
institutional backing of the kind that Ada got may be quite
counterproductive.  The fact that Ada compilers were hard to write
probably also contributed.

- 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.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

Anton Ertl wrote:
> John Passaniti <john.passaniti@gmail.com> writes:
>> On Nov 24, 12:59=A0pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>> wrote:
>>>> =A0And that's exactly what you did.
>>> Where did I compare apples to oranges? =A0Or if you think I don't know
>>> what I am measuring, please enlighten me.
>> If someone told you language X took 24k and language Y took 2400k,
>> what *useful* conclusions could you make from that statement about the
>> two languages?  Aside from the obvious and trivial (Y is bigger), you
>> can't make any useful conclusions from knowing those sizes.  Language
>> X could be hosted on a small 8-bit microcontroller and have only bare-
>> minimum features while Language Y could be hosted on a 64-bit
>> processor on top of Windows
> 
> Given that I compared the language implementations on the same
> platform (actually the same machine), how is that relevant?  Looks
> like another straw man to me.
> 
>> and have compiled-in support for operating
>> system, sound, graphics, regular expressions, arbitrary precision
>> math, HTTP, XML, bindings to databases, a full-featured debugger, a
>> JIT compiler, compression and cryptology libraries, etc.
> 
> Features may be a reason that explains both size and popularity.  But
> anyway, the question was about the footprint, not about features.
> 
>> And I'm going to bet that when Elizabeth asked about the
>> size of Forth compared to scripting languages, she wasn't interested
>> in meaningless numbers.
> 
> She can speak for herself.  She asked for the numbers, so I guess the
> have some meaning for her.  If she needs more to make them meaningful,
> she can ask.

The context of my question was that someone reported that his superiors 
rejected Forth in favor of a scripting language because they "didn't 
need all that stuff".  I was just looking for a quantitative measure of 
what "all that stuff" was.  I agree with John that there may be good 
functional reasons to prefer a tool specifically designed for scripting 
(or other special purposes) on functional grounds (FORTH, Inc.'s web 
site uses PHP and Javascript a lot), but "all that stuff" is a straw man 
argument.  I think that point was made sufficiently.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

On Nov 24, 8:34=A0pm, Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
> That's fine with me. I started another thread discussing my symtab
> program. I say that my algorithm is good original work, but John
> Passaniti says that it is neither. John Passaniti's supporters, both
> numerous and ardent, can go over there and pitch in --- but keep the
> thread focused on the technical merits (if any) of symtab.

Interesting how you conflate things.  I don't have "supporters" in
comp.lang.forth.  What you saw wasn't some great love, acceptance, or
even moderate concern for me, but rather a critical review of *your*
words and behavior.  I expect that everyone you consider a "supporter"
of mine would have written exactly the same thing to you regardless of
if I was swapped out for someone else.  Those people were reacting to
*you*, *your* undue sensitivity to incidental details of others, and
*your* feigning ignorance over a slur.  And it doesn't even have
anything to do with sexuality.  I could have incidentally and
indirectly referenced any number of other details about myself that
you had a bug up your ass about.  The result would have been the same.

John Passaniti <john.passaniti@gmail.com> wrote:
> Hugh Aguilar <hugoagui...@rosycrew.com> wrote:

> > That's fine with me. I started another thread discussing my symtab
> > program. I say that my algorithm is good original work, but John
> > Passaniti says that it is neither. John Passaniti's supporters, both
> > numerous and ardent, can go over there and pitch in --- but keep the
> > thread focused on the technical merits (if any) of symtab.
> 
> Interesting how you conflate things.  I don't have "supporters" in
> comp.lang.forth.  

Agreed.

> What you saw wasn't some great love, acceptance, or
> even moderate concern for me, but rather a critical review of *your*
> words and behavior.  

Strongly agreed.

> I expect that everyone you consider a "supporter"
> of mine would have written exactly the same thing to you regardless of
> if I was swapped out for someone else.  

Yes, definitely.

> Those people were reacting to
> *you*, *your* undue sensitivity to incidental details of others, and
> *your* feigning ignorance over a slur.  And it doesn't even have
> anything to do with sexuality.  I could have incidentally and
> indirectly referenced any number of other details about myself that
> you had a bug up your ass about.  The result would have been the same.

Yes. Though I think the sexuality thing made it more of a hot button
than many other issues would have been.

On Nov 25, 8:33=A0am, Jonah Thomas <jethom...@gmail.com> wrote:
> Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
> > All we need is DUM/MOD.
>
> You don't need it.
>
> http://groups.google.co.jp/group/comp.lang.forth/msg/6fa4e33f552ca10a

If there is a way to avoid introducing DUM/MOD then I'm definitely
interested. I'll read through this and get back to you on it later,
after Turkey Day.

I've noticed that division is truncated (toward negative infinity if
based on FM/MOD, or toward 0 if based on SM/REM). I've never
understood the rational for this. Rather than just discard the
remainder, why not use it to round the quotient up or down? This is a
quick and easy operation, so speed shouldn't be an issue. Why would
anybody not want their quotient rounded off?

Hugh Aguilar <hugoaguilar@rosycrew.com> wrote:
> Jonah Thomas <jethom...@gmail.com> wrote:
>
> > http://groups.google.co.jp/group/comp.lang.forth/msg/6fa4e33f552ca10a
> 
> If there is a way to avoid introducing DUM/MOD then I'm definitely
> interested. I'll read through this and get back to you on it later,
> after Turkey Day.

Thank you.
 
> I've noticed that division is truncated (toward negative infinity if
> based on FM/MOD, or toward 0 if based on SM/REM). I've never
> understood the rational for this. Rather than just discard the
> remainder, why not use it to round the quotient up or down? This is a
> quick and easy operation, so speed shouldn't be an issue. Why would
> anybody not want their quotient rounded off?

You can do that. They both give you a remainder. Just keep your original
numerator and use the remainder to round up or down.

FM/MOD and SM/REM provide two different ways to represent the quotient
and remainder. One way is useful when you want to treat negative numbers
just like positive numbers. The other way is useful when you don't want
a bump at zero. See, when you round toward zero, every number gets one
interval except zero which gets two intervals. If you're tracking
rotations or something where you want it even, you could get an annoying
bump at zero where its value will be twice as big as the others just
because of the way you divide.

Anton Ertl wrote:
[History of Perl, etc., snipped]

> They all seem very individual to me.  The "institutional backing" is
> just that they let these people work on these languages, not more.

Early on, being allowed to work on a language is significant.  Not 
everybody has that freedom!  And later on, being encouraged to publish 
is significant, too.

> Anyway, Forth became quite popular in the 70s and 80s, and at some
> point a number of people worked on Forth at big institutions with that
> amount of backing.  E.g., John Hayes and Marty Fraeman at Johns
> Hopkins University.  Or Mitch Bradley at Sun.  When Python started,
> Forth had more of this kind of institutional support than Python.  If
> that was the decisive Factor, Forth would have won.

Johns Hopkins allowed Forth to be used in some projects: openly in some, 
stealthily in others.  Although they made some contributions (notably 
the ANS Forth test suite) they were mostly users, not contributors.

Sun was the big opportunity.  Only Mitch knows why Sun elected not to 
promote OF the way they did Java later.  I assume the promotion of Java 
was due to the fact that its very purpose required it to be installed on 
PCs around the world, whereas the usefulness of OF was limited to the 
bring-up and maintenance of new computers and peripherals, a lower-level 
and les-glamorous function.

....
> 
>>  Here the contrast is that Forth was a *departure* from familiar and 
>> popular programming paradigms.
> 
> I think that is a decisive factor.

Probably.

>> Instead of the Internet, Forth promotion 
>> in the 80's relied on print publications such as Byte and Dr. Dobbs, 
>> which editorially butchered programming examples, thus feeding the 
>> perception of unreadability.
> 
> And yet, it became somewhat popular.

But only somewhat, and that mainly because it could run on platforms 
with no other HLL support.  For many years (roughly mid-80's to 
mid-90's) FORTH, Inc. and FIG would have booths at the Embedded Systems 
Conference, and the majority of people who came into the booth would say 
something like, "Oh, Forth, what a joke!  I've seen articles on that! 
Makes no sense whatever!" ...or words to that effect.  Of course, 
towards the end of that period, most people had just never heard of it 
at all.

>>> And if the size and funds of the supporting organization were the
>>> decisive factor, everyone would program in Ada.  Yet, looking at the
>>> popularity in Usenet, Ada is usually about as popular as Forth.
>> It quickly became the perception that Ada projects required budgets of 
>> $1M+, which tends to put a damper on acceptance!
> 
> Yes, but that's probably because of the institutional backing.  So
> institutional backing of the kind that Ada got may be quite
> counterproductive.  The fact that Ada compilers were hard to write
> probably also contributed.

Yeah, well, some "institutions" have special characteristics!

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

On Nov 26, 11:15=A0am, Elizabeth D Rather <erat...@forth.com> wrote:
> For many years (roughly mid-80's to
> mid-90's) FORTH, Inc. and FIG would have booths at the Embedded Systems
> Conference, and the majority of people who came into the booth would say
> something like, "Oh, Forth, what a joke! =A0I've seen articles on that!
> Makes no sense whatever!" ...or words to that effect. =A0Of course,
> towards the end of that period, most people had just never heard of it
> at all.
>
Are the companies that used to promote Forth in the mainstream just
burned out? Press releases are worth a try and they're free. Emphasize
benefits over features, because the benefits are going to have to be
worth it.

The problem with Forth could be a management issue. If you give a
monkey the keys to a Ferrari and he wrecks it, you might swear off
those damn Ferraris forever. Forth requires a more disciplined
approach to programming than the average company uses. So, the
language must play programming cop to keep the code monkeys from
trashing the place.

-Brad

Uwe Klo� <uwe.kloss@gmx.de> wrote:
 
> In that case we have to ask "why".
> What do other languages have, that Forth has not?

Having spent large chunks of the past year or so persevering with trying
to teach myself forth, I can offer the following extra insights:

Forth comprehension is an esoteric skill. Most people familiar with more
conventional computer languages, myself included, lack the underlying
skill base to achieve production goals or professional standards in a
reasonable amount of time while simultaneously getting up to speed in
forth from a standing start. (After having done that in other languages,
forth was a shock).

The kind of help available on the net is mostly knowledge and theory
based. It does little towards imparting skill in the use of the
language. That comes from fitting its various bits and pieces together
in a working environment.

Assigning a programmer lacking forth experience to something requiring
forth would be foolish unless you already have an experienced forth
programmer on staff to act as mentor. IOW, if you're not already using
forth, you would be naive expecting to see acceptable progress in a
project which opts to ignore industry folklore and bravely try using
forth.

I say all this in good grace. I have finally reached a stage where the
pieces are starting to fall into place, and forth is beginning to reveal
its inner strengths. That is a very satisfying feeling which is its own
reward. But it did take an unexpectedly long time, and I still have a
long way to go.

It is unfortunate that the commercial world cannot accommodate such a
drawn-out learning curve. While education fails to embrace forth, I
can't see it increasing its following anytime soon. (As much as I would
love people of my own or slightly higher level to compare notes with).

I might add that finding the necessary help using web searches has been
no breeze either. I don't know if that is because the remaining forth
shops deliberately keep their work practices under wraps; or is it a
consequence of those working with the language having nothing left to
tell each other beyond debating the finer points?

Sure, there are plenty of experts willing to answer newbies' questions.
But they are definitive answers refined to a point where the missing
imagery is fleshed out inside the writer's head and missing altogether
for the reader.

The atmosphere of a bunch of keen enthusiasts all heading in the same
direction, helping each other get there, is missing.

Tinkerer Atlarge wrote:
> Uwe Klo� <uwe.kloss@gmx.de> wrote:
>  
>> In that case we have to ask "why".
>> What do other languages have, that Forth has not?
> 
> Having spent large chunks of the past year or so persevering with trying
> to teach myself forth, I can offer the following extra insights:
> 
> Forth comprehension is an esoteric skill. Most people familiar with more
> conventional computer languages, myself included, lack the underlying
> skill base to achieve production goals or professional standards in a
> reasonable amount of time while simultaneously getting up to speed in
> forth from a standing start. (After having done that in other languages,
> forth was a shock).
> 
> The kind of help available on the net is mostly knowledge and theory
> based. It does little towards imparting skill in the use of the
> language. That comes from fitting its various bits and pieces together
> in a working environment.

You are omitting some crucial bits of information that would help us 
respond usefully.

* What version of Forth have you been using?

* What books on Forth (there are several available) have you consulted?

* Are you trying to assist with an existing Forth application, or 
starting from scratch?

* How are you hoping to use Forth?

I ask because, having taught a great many new Forth programmers in the 
last 30 years, it's my experience that it's possible with appropriate 
support to be productive in the language in about a week of intensive 
work.  But much depends on what kind of support (both technical and 
written) is available and how it's utilized.
....
> 
> The atmosphere of a bunch of keen enthusiasts all heading in the same
> direction, helping each other get there, is missing.

I may be wrong, but I think this is the first time you have been in this 
newsgroup.  We would love to help, if you can tell us a little more 
about your background and where you're heading.

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."
==================================================

Elizabeth D Rather wrote:
> Tinkerer Atlarge wrote:
>> Uwe Klo� <uwe.kloss@gmx.de> wrote:
>>  
>>> In that case we have to ask "why".
>>> What do other languages have, that Forth has not?
>>
>> Having spent large chunks of the past year or so persevering with trying
>> to teach myself forth, I can offer the following extra insights:
>>
>> Forth comprehension is an esoteric skill. Most people familiar with more
>> conventional computer languages, myself included, lack the underlying
>> skill base to achieve production goals or professional standards in a
>> reasonable amount of time while simultaneously getting up to speed in
>> forth from a standing start. (After having done that in other languages,
>> forth was a shock).
>>
>> The kind of help available on the net is mostly knowledge and theory
>> based. It does little towards imparting skill in the use of the
>> language. That comes from fitting its various bits and pieces together
>> in a working environment.
> 
> You are omitting some crucial bits of information that would help us 
> respond usefully.
> 
> * What version of Forth have you been using?
> 
> * What books on Forth (there are several available) have you consulted?
> 
> * Are you trying to assist with an existing Forth application, or 
> starting from scratch?
> 
> * How are you hoping to use Forth?
> 
> I ask because, having taught a great many new Forth programmers in the 
> last 30 years, it's my experience that it's possible with appropriate 
> support to be productive in the language in about a week of intensive 
> work.  But much depends on what kind of support (both technical and 
> written) is available and how it's utilized.
>

But isn't that a supporting argument to his point when he said:
  "Assigning a programmer lacking forth experience to something
   requiring forth would be foolish unless you already have an
   experienced forth programmer on staff to act as mentor."

On Nov 28, 12:13=A0am, tinke...@optusnet.com.au (Tinkerer Atlarge)
wrote:

> Having spent large chunks of the past year or so persevering with trying
> to teach myself forth, I can offer the following extra insights:
>
> Forth comprehension is an esoteric skill. Most people familiar with more
> conventional computer languages, myself included, lack the underlying
> skill base to achieve production goals or professional standards in a
> reasonable amount of time while simultaneously getting up to speed in
> forth from a standing start. (After having done that in other languages,
> forth was a shock).

Would you mind elaborating a bit on the specific aspect(s) of learning
Forth that you found to be most difficult?

For example:
- RPN arithmetic?
- Control flow (IF ELSE THEN and so forth)?
- Create Does> ?
- Postpone ?
- Lack of data typing?
- Missing language constructs that are typically present in other
languages?
- Other?

Thanks.

-Doug

Elizabeth D Rather <erather@forth.com> wrote:

> Tinkerer Atlarge wrote:
> > Uwe Klo� <uwe.kloss@gmx.de> wrote:
> >  
> >> In that case we have to ask "why".
> >> What do other languages have, that Forth has not?
> > 
> > Having spent large chunks of the past year or so persevering with trying
> > to teach myself forth, I can offer the following extra insights:
> > 
> > Forth comprehension is an esoteric skill. Most people familiar with more
> > conventional computer languages, myself included, lack the underlying
> > skill base to achieve production goals or professional standards in a
> > reasonable amount of time while simultaneously getting up to speed in
> > forth from a standing start. (After having done that in other languages,
> > forth was a shock).
> > 
> > The kind of help available on the net is mostly knowledge and theory
> > based. It does little towards imparting skill in the use of the
> > language. That comes from fitting its various bits and pieces together
> > in a working environment.
> 
> You are omitting some crucial bits of information that would help us 
> respond usefully.

I was not seeking help when I wrote that. I had just finished the
lengthy burst of forth learning referred to above. � thought I would
contribute some insights of my own while they were still fresh in my
mind.

> * What version of Forth have you been using?

I was writing forth to run in Open Firmware, using a text editor in Mac
OS X, rebooting into Open Firmware every time I needed to try it out. I
know there are easier ways to learn forth, but my use of forth was
incidental. However, as mentioned in my post, I greatly underestimated
the amount of time it would take getting forth to do the things I needed
it to do. A lot of the time it seemed like it was fighting me, or being
exasperatingly circuitous.

> * What books on Forth (there are several available) have you consulted?

I have both your Forth Inc books, Elizabeth, and recently discovered
Stephen Pelc's online (I am still reading it, in fact). There doesn't
seem to be much else available. I find them all very helpful. What I am
talking about is what happens between consulting such books, between one
time and the next. Sometimes they answer the questions I have, sometimes
they don't. If they don't, I have to keep searching, or resort to
unorthodox abuses of the way the language was meant to be used. 

It is the type of information that doesn't turn up anywhere which has
been the main stumbling block. Sometimes the information is good, but
its relevance eludes me until much later; until after I have come back
having since solved a problem in a different round-about way. One
example is, after all the info I got from this ng about text parsing
functions, I still had to resort to using 'h#', as the best means I
could find for limiting input to the type I needed from the user.

> * Are you trying to assist with an existing Forth application, or 
> starting from scratch?

I have written some tools for exploring Open Firmware via its command
line interface, tools which run in Open Firmware from the Open Firmware
prompt. My main interest was being able to interact directly with the
hardware, especially the cpu. I was surprised to find no one else
appears to have tried doing it that way before (except maybe
pre-internet, long, long ago).

> * How are you hoping to use Forth?

Years ago I wrote substantial programs in assembler on 8-bit micros and
was hoping to get back into doing similar things on more modern
hardware. More a hobby than anything else.  I like the immediacy of
writing code direct into the computer and getting immediate feedback.
Very similar to forth. It's therefore ironic I had to wait out a reboot
every time I authored a forth statement during my recent learning
marathon.

I am not complaining. I finally have a set of self-made tools including
a resident native ppc assembler and disassembler which now do exactly
what I want.

> I ask because, having taught a great many new Forth programmers in the
> last 30 years, it's my experience that it's possible with appropriate
> support to be productive in the language in about a week of intensive
> work.  But much depends on what kind of support (both technical and 
> written) is available and how it's utilized.

I don't doubt that at all. I would tend to put that under the type of
"mentoring" I lamented the lack of in my post. I expect your students
also get a lot out of being able to discuss things wiith you (in
addition to reading definitive statements from your books) and also from
the opportunity of discussing it, perhaps on an ongoing basis, with
people at a similar level to themselves.

> > The atmosphere of a bunch of keen enthusiasts all heading in the same
> > direction, helping each other get there, is missing.
> 
> I may be wrong, but I think this is the first time you have been in this
> newsgroup.  We would love to help, if you can tell us a little more 
> about your background and where you're heading.

I have posted a few questions here during the above-mentioned past year
or so. But mostly I use searches looking for previous discussions and
other sources, since most will have moved on from my own particular
focus of interest. The surprising lack of information on many closely
related sub-topics surprises me. There is endless repetition of a
certain core set of well-aired facts, but many angles never seem to get
mentioned at all.

Cheers

Tink

Doug Hoffman <glidedog@gmail.com> wrote:

> On Nov 28, 12:13 am, tinke...@optusnet.com.au (Tinkerer Atlarge)
> wrote:
> 
> > Having spent large chunks of the past year or so persevering with trying
> > to teach myself forth, I can offer the following extra insights:
> >
> > Forth comprehension is an esoteric skill. Most people familiar with more
> > conventional computer languages, myself included, lack the underlying
> > skill base to achieve production goals or professional standards in a
> > reasonable amount of time while simultaneously getting up to speed in
> > forth from a standing start. (After having done that in other languages,
> > forth was a shock).
> 
> Would you mind elaborating a bit on the specific aspect(s) of learning
> Forth that you found to be most difficult?

I am not sure I can be very helpful here, but I'll give it a try. The
problem is I am a bit of a maverick. There is a limit to how much theory
I can absorb without applying it. I have an aversion to contrived
textbook-style example "problems" which don't seem relevant to my
immediate goals. There are times when I puzzle over a book description
of something trying to figure it out. But what I mostly get out of
reading is occasional easy flashes of inspiration which allow me to get
back to work with a renewed conviction that I can see a clear path to
solving the problem. I can get a lot of mileage out of very primitive
languages (like assembler for example) and prefer having a large
repertoire of languages partly known to just a few thoroughly mastered.

Anyway, FWIW, here goes:

> For example:
> - RPN arithmetic?

The arithmetic itself is not the problem. The difficulty is in spotting
errors, such as when, out of habit, an operator is put before rather
than after its arg. I miss being able to spot such errors out of the
corner of my eye as opposed to having to laboriously uncover them
through a long drawn-out process of exhaustive elimination.

> - Control flow (IF ELSE THEN and so forth)?

Similar to the above. Putting the test expression after the IF is not
something I would spot unless I was specifically looking for it.

> - Create Does> ?

I have to admit I have yet to try it. I feel I need a more solid grasp
of the standard vocabulary before I start introducing complications of
my own.

> - Postpone ?

As above, I don't think I have yet had cause to use it.

> - Lack of data typing?

Not a problem for me, as I was once quite adept at assembler (even
without an assembler)

> - Missing language constructs that are typically present in other
> languages?

I have to admit that has slowed me down. I don't automatically know in
advance which of the forth looping constructs is likely to be the most
appropriate. I have to open a book and keep my finger on the place as I
nut through each one trying to figure out what I will end up with given
what I have to start with.  I expect practice will eventually take care
of it. In the meantime I have a strong tendency to try and use the same
looping construct over and over for everything, and only resort to
taking another look at the others when I can't figure out how to make
the most familiar one do what I want it to do.

For some reason, I don't have that problem with 'C'. Maybe because I
learned it when I was younger..  don't know.

> - Other?

I suspect the best forth programmers are the ones who know how it fits
together under the hood. There is compile time and runtime and input
buffers all mixed in together. I expect a lot of newbies have no
rational basis for guessing which combinations of operations make sense
and which do not

> Thanks.
> 
> -Doug

Cheers

Tink

tinkerer@optusnet.com.au (Tinkerer Atlarge) wrote:

> I was writing forth to run in Open Firmware, using a text editor in
> Mac OS X, rebooting into Open Firmware every time I needed to try it
> out. I know there are easier ways to learn forth, but my use of forth
> was incidental. However, as mentioned in my post, I greatly
> underestimated the amount of time it would take getting forth to do
> the things I needed it to do. A lot of the time it seemed like it was
> fighting me, or being exasperatingly circuitous.

If you are still interested in OF, you might find a way to edit text in
OF. That would save you the reboot cycle.

> I am not complaining. I finally have a set of self-made tools
> including a resident native ppc assembler and disassembler which now
> do exactly what I want.

If you're finished with Forth, thank you for explaining a little bit
about where the problems came. 

I vaguely remember that "exasperatingly circuitous" feeling from my
earliest days with Forth. What was worst was to realise that the Forth
compiler was already doing something that looked like what I needed, but
when I looked in detail at how it worked it was doing too much. Like, I
wanted to parse a word from the input buffer but WORD also moved it to
HERE as a counted string where it was very much in my way. I was pleased
that recent standards factored some of the things that were so annoying
back then.

tinkerer@optusnet.com.au (Tinkerer Atlarge) writes:
>Elizabeth D Rather <erather@forth.com> wrote:
>> * What books on Forth (there are several available) have you consulted?
>
>I have both your Forth Inc books, Elizabeth, and recently discovered
>Stephen Pelc's online (I am still reading it, in fact). There doesn't
>seem to be much else available.

There is also Gforth's Forth Tutorial
<http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Tutorial.html>
and "Starting Forth" <http://home.iae.nl/users/mhx/sf.html>.

- 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.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

On Sun, 29 Nov 2009 00:32:01 +1000, tinkerer@optusnet.com.au (Tinkerer
Atlarge) wrote:

>I have an aversion to contrived
>textbook-style example "problems" which don't seem relevant to my
>immediate goals. There are times when I puzzle over a book description
>of something trying to figure it out. But what I mostly get out of
>reading is occasional easy flashes of inspiration which allow me to get
>back to work with a renewed conviction that I can see a clear path to
>solving the problem.

I have always found that I need three books when learning a new
language. One gets discarded fairly soon, one is a quick reference,
and the third tells me more about how and why.

If and/or when I write another Forth book, and nobody has done
one, I would be tempted to write a very short K&R style book.

I'm one of those people who can only really learn a language by
having a job to do with it. I think it's a matter of focus.

>The arithmetic itself is not the problem. The difficulty is in spotting
>errors, such as when, out of habit, an operator is put before rather
>than after its arg. I miss being able to spot such errors out of the
>corner of my eye as opposed to having to laboriously uncover them
>through a long drawn-out process of exhaustive elimination.

When I teach a class to experienced programmers, I have to enforce
a discipline
1) Keep it short,
2) Test *everything* as you go.

In some ways, the parameter stack is both wonderful and a
problem. To use it well, keep it simple and short. Testing
simple things is easy. If you let the stack get complicated,
you are in trouble both in terms of your understanding and
for maintenance programmers.

>Similar to the above. Putting the test expression after the IF is not
>something I would spot unless I was specifically looking for it.

Test as you go is again the solution.

>I have to admit that has slowed me down. I don't automatically know in
>advance which of the forth looping constructs is likely to be the most
>appropriate. I have to open a book and keep my finger on the place as I
>nut through each one trying to figure out what I will end up with given
>what I have to start with.

You have basically three choices as in any language:
1) test at the top
  begin 
    <test>
   while
    <action>
  repeat

2) test at the bottom
  begin
    <action>
    <test>
  until

3) counted
  <limit> <start> do
    <action>
  loop

>I suspect the best forth programmers are the ones who know how it fits
>together under the hood. There is compile time and runtime and input
>buffers all mixed in together. I expect a lot of newbies have no
>rational basis for guessing which combinations of operations make sense
>and which do not

Because Forth is extensible, understanding when things happen is
very important for advanced Forth programming. You need to get
to the point where the basics feel natural first.

I shall be updating my book for 2010, so please feel free to
contact me directly with comments and questions.

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
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.mpeforth.com - free VFX Forth downloads

Richard Owlett wrote:
> Elizabeth D Rather wrote:
....
>> I ask because, having taught a great many new Forth programmers in the 
>> last 30 years, it's my experience that it's possible with appropriate 
>> support to be productive in the language in about a week of intensive 
>> work.  But much depends on what kind of support (both technical and 
>> written) is available and how it's utilized.
>>
> 
> But isn't that a supporting argument to his point when he said:
>  "Assigning a programmer lacking forth experience to something
>   requiring forth would be foolish unless you already have an
>   experienced forth programmer on staff to act as mentor."

I haven't been "on staff" for them, I just teach a one-week course. 
Sometimes it's at FORTH, Inc. and people from different companies come, 
other times it's on-site for several programmers at one company.

Of course, it's very helpful to have one or more experienced Forth 
programmers on staff to mentor a newbie, but a course (or a good book or 
two) is a great help for those who don't have that advantage.  It sounds 
like the OP is in that situation.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

Tinkerer Atlarge wrote:
> Elizabeth D Rather <erather@forth.com> wrote:
....
> 
>> * What version of Forth have you been using?
> 
> I was writing forth to run in Open Firmware, using a text editor in Mac
> OS X, rebooting into Open Firmware every time I needed to try it out. I
> know there are easier ways to learn forth, but my use of forth was
> incidental. However, as mentioned in my post, I greatly underestimated
> the amount of time it would take getting forth to do the things I needed
> it to do. A lot of the time it seemed like it was fighting me, or being
> exasperatingly circuitous.
> 
>> * What books on Forth (there are several available) have you consulted?
> 
> I have both your Forth Inc books, Elizabeth, and recently discovered
> Stephen Pelc's online (I am still reading it, in fact). There doesn't
> seem to be much else available. I find them all very helpful. 

Thank you!

> What I am
> talking about is what happens between consulting such books, between one
> time and the next. Sometimes they answer the questions I have, sometimes
> they don't. If they don't, I have to keep searching, or resort to
> unorthodox abuses of the way the language was meant to be used. 
> 
> It is the type of information that doesn't turn up anywhere which has
> been the main stumbling block. Sometimes the information is good, but
> its relevance eludes me until much later; until after I have come back
> having since solved a problem in a different round-about way. One
> example is, after all the info I got from this ng about text parsing
> functions, I still had to resort to using 'h#', as the best means I
> could find for limiting input to the type I needed from the user.

Open Firmware is a pretty large superset of standard Forth.  There are a 
few books on it (Google), which would be very helpful if you don't 
already have them.  I have taught OF courses, too.  h# is one example of 
a useful function in OF that isn't in generic Forth.  There are many! 
Firmworks used to sell some extremely helpful OF books, although they 
were pretty expensive.  I don't know if they're still available.

Unfortunately, Apple's implementation of OF isn't entirely compliant 
with the OF standard.  As I recall, its debugger doesn't work, nor does 
PATCH.

>> * Are you trying to assist with an existing Forth application, or 
>> starting from scratch?
> 
> I have written some tools for exploring Open Firmware via its command
> line interface, tools which run in Open Firmware from the Open Firmware
> prompt. My main interest was being able to interact directly with the
> hardware, especially the cpu. I was surprised to find no one else
> appears to have tried doing it that way before (except maybe
> pre-internet, long, long ago).

Interacting with "bare metal" is mostly a feature of embedded systems 
programming.  FORTH, Inc. offers a line of cross-target compilers called 
SwiftX that support interactive programming on most popular 
microcontrollers.

>> * How are you hoping to use Forth?
> 
> Years ago I wrote substantial programs in assembler on 8-bit micros and
> was hoping to get back into doing similar things on more modern
> hardware. More a hobby than anything else.  I like the immediacy of
> writing code direct into the computer and getting immediate feedback.
> Very similar to forth. It's therefore ironic I had to wait out a reboot
> every time I authored a forth statement during my recent learning
> marathon.
> 
> I am not complaining. I finally have a set of self-made tools including
> a resident native ppc assembler and disassembler which now do exactly
> what I want.

I agree that OF isn't a very good learning environment for Forth.  You 
might enjoy an evaluation version of SwiftX (limited only in that you 
can't make a ROMable target binary).  There are versions that can be 
hosted under Windows or Linux (no OSX, alas).  With it, you can 
interactively examine target memory, I/O ports, immediately write & test 
words, etc.

Unfortunately, PPC isn't on the list of supported targets.

....
> 
>>> The atmosphere of a bunch of keen enthusiasts all heading in the same
>>> direction, helping each other get there, is missing.
>> I may be wrong, but I think this is the first time you have been in this
>> newsgroup.  We would love to help, if you can tell us a little more 
>> about your background and where you're heading.
> 
> I have posted a few questions here during the above-mentioned past year
> or so. But mostly I use searches looking for previous discussions and
> other sources, since most will have moved on from my own particular
> focus of interest. The surprising lack of information on many closely
> related sub-topics surprises me. There is endless repetition of a
> certain core set of well-aired facts, but many angles never seem to get
> mentioned at all.

Questions are always welcome!  I'd be interested to know what particular 
kinds of information you've found lacking.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

Doug Hoffman wrote:
....
> 
> Would you mind elaborating a bit on the specific aspect(s) of learning
> Forth that you found to be most difficult?
> 
> For example:
> - RPN arithmetic?
> - Control flow (IF ELSE THEN and so forth)?
> - Create Does> ?
> - Postpone ?
> - Lack of data typing?
> - Missing language constructs that are typically present in other
> languages?
> - Other?

He's using Open Firmware.  CREATE ... DOES> isn't available in OF, and I 
don't think POSTPONE is, either.  On the other hand, there's a vast 
amount of additional functionality that isn't documented well except in 
OF-specific publications.  For example, structures like DO ... LOOP and 
IF ... ELSE ... THEN are available on the command line.

Support for editing and loading text files is limited and quite arcane. 
  OF on a delivered platform such as a Mac isn't intended as a 
programming environment except in a very limited sense, for testing 
purposes.  I don't blame the OP for feeling frustrated.  OF is really a 
very complex Forth application, not Forth itself.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

Jonah Thomas <jethomas5@gmail.com> wrote:
> Hugh Aguilar <hugoaguilar@rosycrew.com> wrote:
 
> http://groups.google.co.jp/group/comp.lang.forth/msg/6fa4e33f552ca10a
> 
> Note that when you get a continued fraction for pi the issue is not
> that you have a continued fraction for pi. What you will do with it is
> multiply it by stuff. And the best continued fraction is the one that
> gives you the right product the most times, with perhaps some other
> properties like you might want the error to be low half the time and
> high half the time. 
> 
> But ignoring all that, if you want to see how good n * a / b is, you
> can take the original double-precision x and multiply it by the
> single-precision n to get a triple-precision product. Then you divide
> by the single-precision b to get a double-precision quotient. Then you
> take the low cell and use it to decide whether to round the high cell
> up or down. That single-precision result is what you compare n * a / b
> by to see whether it's perfect or off by one. If it's off by more than
> one then you don't have a very good continued fraction yet.
> 
> Check whether I got the details right, it's early for me and I could
> have them all wrong. But the basic idea I'm sure is right. After you
> do*/ you will have a single-precision result. Is that the best
> single-precision result or is it off? To find out, you might as well
> start with your high-precision "correct" form and calculate the best
> single-precision result that you will compare against. I don't think
> this needs DUM/MOD .
> 
> Note that */ does not round, it truncates. I think this will throw a
> systematic bias into your results. Continued fraction methods give you
> the best result with rounding, and this does not round. So something
> other than the best continued fraction might be what you want. I could
> be wrong about this too.
> 
> It seems to me that on average, you could hope for a continued
> fraction pair that gives you the best single-precision result about
> half the time, and gives you a result that is 1 bit low 1/4 the time
> and a result that is 1 bit high 1/4 the time. Or, since there are so
> many continued fraction pairs to choose from, maybe you could get one
> that gives you the correct result much more than half the time and
> still makes the errors high or low about equally. For 16 bits you can
> easily do an exhaustive search and find the best pairs completely by
> brute force. For 32 bits it's harder....

I don't think I've ever gotten a response on this, but I got interested
in it one more time so I'll write about it again.

-----------
When people create continued fractions the usual approach is to try to
get a pair of numbers x y so that x/y is very close to some target. But
for fixed point math this is a red herring.

For fixed point math, there is a best fixed point approximation. For
example, if you want a 16-bit approximation for 10000*pi then you can't
get any better than 31416. 31415 is clearly not as good and 31417 is
worse. Never mind how close x/y would come to pi if you did an
infinite-precision x/y. When you finish your single-precision arithmetic
you will have a single-precision result and it will be off by however
much it's off. It might be the best possible single-precision
approximation or it might be off by one. If it's off by more than one
that's worse.

So for any x y pair, here's a brute-force method to see how good it is.
I'll talk about pi as an example. 

First you find the biggest number you can multiply by pi and still get a
valid result. For signed 16 bits that would be 10430. 10431*pi = 32769+
which is out of bounds.

Then, for every number z from zero to the biggest number, you do   x y
*/  and get a value. Then you convert z to floating point, multiply by
pi, round, subtract, and convert back to single-precisition fixed point.
If the result is zero then you have the best possible fixed point
approximation for z*pi. If the result is 1 or -1 then you don't have the
best approximation. 

So for every possible z you calculate how far off z x y */ puts you.
Ideally, you would get the best approximation every time. Failing that,
you'd like to have only a few errors and you'd like them to be high
about as often as they're low. The pattern of rounding errors will not
necessarily be smallest when x/y is closest to pi.

-----------

Second point. The Forth */ does not round. Its division truncates. This
is not wrong behavior. The routine would slow down and use more stack
space if it tracked the remainder and adjusted the last bit. If you want
a */ that rounds you can write one without a lot of trouble. I did that
and I never found an example where I really needed it.

However, the concept behind continued fractions and foley fractions
requires rounding. Would you expect to get the same rounding errors when
you truncate instead? There is no particular reason to expect continued
fractions to give you the x y pair that will most often give the best
result with */ .

-----------

I considered rethinking continued fractions to work with truncation. But
instead I tried for a brute force proof of concept. With today's
desktops it's fast to check all of the 16-bit possibilities.

\ -----------------------
\ test the rounding errors

2variable approx \ the current x/y pair
FVARIABLE OK     \ the correct value

\ compare single-precision approximation to best approximation
\ where "best" comes from floating point.
: test1 ( n -- -1|0|1)
   DUP approx 2@ */       \ n x
   SWAP
   S>D D>F OK F@ F* FROUND F>D DROP
   - ;

: ARRAY
   CREATE CELLS ALLOT
   DOES> SWAP CELLS + ;

\ I assume error will not be more than 1 bit.
2 ARRAY ERROR
: clear-errors
   3 0 do 0 i ERROR ! loop ;

\ test error for every possible multiplier.
\ with symmetric division the negative values will mirror positives.
: tests ( -- )
   clear-errors
   10431 0 DO
     I TEST1 1 SWAP 1+ 0 max 2 min ERROR +!
   LOOP ;
   
: t ( n d -- )
   approx 2! tests 0 error ? 1 error ? 2 error ? ;

\ -------------------

355 113 approx 2!
pi OK F!



\ -------------------
\ brute force testing

variable best

\ check whether a particular x y pair is good
\ if it works for one value then test it for all.
: bf
   10430 approx 2@ */ 32766 32769 within if
     tests 1 ERROR @ best @ > if
       1 ERROR @ best !
       0 ERROR ? 1 ERROR ? 2 ERROR ?
       approx 2@ . . ."    "
     then 
   then ;

bfs 5171 5259 0 113 355    1668 8255 507 120 377
    1958 8258 214 833 2617    1920 8266 244 953 2994
    1892 8270 268 1073 3371    1839 8271 320 1433 4502     ok

355 113 is low almost half the time. I believe this is because */
truncates. By the criteria I tested for, 4502 1433 does better -- it
gives the best possible result almost 80% of the time. But when it gives
the wrong result that result is almost 6 times as likely to be low as
high.

355 113 is wrong almost half the time and the error is highly biased.
4502 1433 is better.



I tried choosing a minimum percentage to be right and then seeing how
well I could balance the errors.

VARIABLE SIDES

: bf'
   10430 approx 2@ */ 32766 32769 within if
     tests 1 ERROR @ 8000 > if
       0 ERROR @ 2 ERROR @ - ABS DUP SIDES @ U< if
         SIDES !
         0 ERROR ? 1 ERROR ? 2 ERROR ?
         approx 2@ . . ."    " else
         drop
       then
     then 
   then ;
\ try all plausible 16-bit x y pairs.
\ sloppy but fast enough.

: bfs'  
   65535 SIDES !
   \ try every x value
   32767 4 DO
     \ try every plausible y value
     I DUP 3 / OVER 4 / ?DO
       dup I approx 2! bf' 
       key? if key 32 = if exit then then
     LOOP drop 
   LOOP ;

bfs' 1668 8255 507 120 377    1425 8029 976 607 1907    
     1413 8006 1011 1701 5344    1410 8002 1018 2795 8781
     1410 8001 1019 9479 29780     ok

I can get less bias on the error, but it results in somewhat bigger
errors. 


I instinctively wanted the error to be unbiased. But consider pi.
3141592.... If you did have errors up to half a bit out of 16 bits, that
would go from 3141542 to 3141642, which would round to 31416 92% of the
time and down to 31415 .08% of the time.

If the error was bigger it could go from 3141534 to 3141650 which would
round to 31416 86% of the time and down to 31415 close to 14%. With 8000
correct, we'd have around 7 instances rounding up to 31417 per 23
rounding down to 31415. So maybe that's more the ratio to aim for.

I'm still not completely clear about all this, but I'm clear on some
things. If you're looking for a pair of numbers x y so that z x y */ is
as close as possible to z * OK for real numbers, your criteria should be
about how often you get the best approximation and the bias of the
errors, not about how close z x y */ would come if they were all real
numbers. And */ truncates while continued fractions assume it will
round.

Stephen Pelc <stephenXXX@mpeforth.com> wrote:

> On Sun, 29 Nov 2009 00:32:01 +1000, tinkerer@optusnet.com.au (Tinkerer
> Atlarge) wrote:
> 
> >I have an aversion to contrived
> >textbook-style example "problems" which don't seem relevant to my
> >immediate goals. There are times when I puzzle over a book description
> >of something trying to figure it out. But what I mostly get out of
> >reading is occasional easy flashes of inspiration which allow me to get
> >back to work with a renewed conviction that I can see a clear path to
> >solving the problem.
> 
> I have always found that I need three books when learning a new
> language. One gets discarded fairly soon, one is a quick reference,
> and the third tells me more about how and why.

Yes, I dared not mention it in present company, but I doubt there is any
book or author who can say everything there is to say about a subject in
a single book without obscuring his own point of view. Thus, in the
absence of a human mentor or tutor, a spread of books from different
authors is vital to someone trying to teach themselves a tricky subject.
With forth, the critical mass is there, but only just. It would be nice
to see more titles on the subject.

> If and/or when I write another Forth book, and nobody has done
> one, I would be tempted to write a very short K&R style book.

That is the computer book which comes closest to being the exception
imv, but, even then, it also illustrates my above point. For exemplary
reasons of clarity, the authors skipped all the customary disclaimers to
focus on the essence of each principle they were using C code to
illustrate. Today their employment of simple text buffers without
digressing into buffer integrity issues is being cited for making many C
programmers careless regarding security. But, yes, I agree, K&R
thoroughly deserves its reputation as a classic and you would be doing
forth a great service if you could come up with a forth equivalent.

> I'm one of those people who can only really learn a language by
> having a job to do with it. I think it's a matter of focus.

Yes, without that, I find the incentive to grapple with a strange and
unfamiliar language simply isn't there. There is a large palette of
forth words to choose from. Initially, trying to winnow them down to a
small enough working set in order to set them in my mind without having
to look up their stack effects every time is the problem. With the
version of forth I was using, the documentation itself posed a similar
problem, being a cut'n'paste from various sources. As Elizabeth pointed
out in another post, Apple's version does not even comply wiith its
generic namesake and appears to have very little user documentation of
its own. (It has three interfaces, perhaps the client interface is
better serviced)

[ ... ]
> 
> You have basically three choices as in any language:
> 1) test at the top
>   begin 
>     <test>
>    while
>     <action>
>   repeat

IMV the way that construct is often presented to forth beginners tends
to place too much emphasis on the test section. That can act as a red
herring which obscures the point you just made. Going by some text
descriptions I have read (I can't remember which ones) the test clause
can too easily be assumed to be the main purpose of the loop. You can do
that with C 'while' loops too of course, but their layout IMHO does a
better job of assigning the test clause its theoretical place outside
the body of the loop. At least it makes it easier to understand when
learning how to use it.

> 2) test at the bottom
>   begin
>     <action>
>     <test>
>   until

Realizing its similarity to the "goto" loop was my breakthrough in
appreciating how simple 'begin:until' is beneath the surface.

> 3) counted
>   <limit> <start> do
>     <action>
>   loop

> >I suspect the best forth programmers are the ones who know how it fits
> >together under the hood. There is compile time and runtime and input
> >buffers all mixed in together. I expect a lot of newbies have no
> >rational basis for guessing which combinations of operations make sense
> >and which do not
> 
> Because Forth is extensible, understanding when things happen is
> very important for advanced Forth programming. You need to get
> to the point where the basics feel natural first.

This broaches a subject which is difficult to put into words because it
is more a vague feeling than anything else. The feeling is that I was
being increasingly taken over and steered by forth into places I didn't
necessarily want to go.

In addition to their straight-forward nominal function, some forth words
also seem to possess a "role" or "purpose" within the forth "scheme of
things". That role is non-obvious and is never mentioned, but
experienced forth programmers are aware of it intuitively it seems, even
if they never have cause to view it in such terms.

One of my recurring frustrations when learning forth was repeatedly (and
I felt undeservedly) finding myself painted into a corner. The symptoms
were that the going kept getting unaccountably harder, the further I
proceeded along a certain path. It was like I had unwittingly taken a
wrong turn which I could only realize further down the track. The "wrong
turn" had no symptoms of its own. However, if I had made a mistake
anywhere, that is where it happened.

I will try to draw an analogy with something more concrete from the real
world. Imagine you have just inherited millions of dollars and, having
been unhappy with the project managers building your dream home, you
decide to step in and direct the work yourself. It is obvious to you
what needs to be done. You direct one worker to take down the wallpaper
and put up something more appropriate. You tell another to collect all
the coffee cups littering the site, and another to replace the brass
taps with something more in line with your dreams. 

They do as instructed and all seems well. However what you failed to
notice was that the one you asked to change the wallpaper was the
plumber, the one you got to replace the taps was the cleaner, and the
paper-hanger is the one collecting the trash. They all perform those
tasks with reasonable aplomb and there is nothing to indicate you made a
mistake. But you have make a mistake, and, in increasingly graphic ways,
you will begin finding out about it further along the track.

Back to forth. Let's start with the project-specific words you define
early in a project yourself. If your earlier ones turn out to be not
quite what they otherwise might have been (which at that point seemed
entirely a matter for your own judgment and discretion), they will still
perform the most immediate tasks you have for them. But, further down
the track, you try to coerce them against some seemingly innate
reluctance into doing things they can eventually be made to do, even if
not quite the way you would have preferred. What has happened is that
you are trying to employ them contrary to some originally conceived role
or purpose.

Extrapolate that to the standard forth vocabulary. My suspicion is that
many common forth words do have an implicit 'role' within the forth
scheme of things which is "obvious" to those who have grown up with it,
but non-obvious and unexplained to anyone else unless how forth is
implemented is added to the start of their learning curve. 

I am sure I could recollect plenty of examples of being steered off
course by seemingly role-conscious forth words just by going back over
the source code of my recent marathon. Jonah Thomas mentions one in his
separate followup. Let me know if you would like to see more.

> I shall be updating my book for 2010, so please feel free to
> contact me directly with comments and questions.

If I find anything worth querying or remarking on while reading the
current edition I will gladly let you know.

Cheers

Tinkerer Atlarge wrote:
> Stephen Pelc <stephenXXX@mpeforth.com> wrote:
....
>> I'm one of those people who can only really learn a language by
>> having a job to do with it. I think it's a matter of focus.
> 
> Yes, without that, I find the incentive to grapple with a strange and
> unfamiliar language simply isn't there. There is a large palette of
> forth words to choose from. Initially, trying to winnow them down to a
> small enough working set in order to set them in my mind without having
> to look up their stack effects every time is the problem. With the
> version of forth I was using, the documentation itself posed a similar
> problem, being a cut'n'paste from various sources. As Elizabeth pointed
> out in another post, Apple's version does not even comply wiith its
> generic namesake and appears to have very little user documentation of
> its own. (It has three interfaces, perhaps the client interface is
> better serviced)

Indeed, you chose one of the most difficult paths for getting into 
Forth!  You have done well to get so far.  No useful documentation, no 
source, no one to talk to.  You were very brave.  In retrospect, you 
might have saved some time by learning on a friendlier system until you 
got the basics down, and then seeing how they apply in OF.

> [ ... ]
>> You have basically three choices as in any language:
>> 1) test at the top
>>   begin 
>>     <test>
>>    while
>>     <action>
>>   repeat
> 
> IMV the way that construct is often presented to forth beginners tends
> to place too much emphasis on the test section. That can act as a red
> herring which obscures the point you just made. Going by some text
> descriptions I have read (I can't remember which ones) the test clause
> can too easily be assumed to be the main purpose of the loop. You can do
> that with C 'while' loops too of course, but their layout IMHO does a
> better job of assigning the test clause its theoretical place outside
> the body of the loop. At least it makes it easier to understand when
> learning how to use it.

I have tried very hard to address this, mostly in Forth Application 
Techniques.  I'd be most grateful for any suggestions as to how to 
improve my discussion of the loops in general.

>> 2) test at the bottom
>>   begin
>>     <action>
>>     <test>
>>   until
> 
> Realizing its similarity to the "goto" loop was my breakthrough in
> appreciating how simple 'begin:until' is beneath the surface.
> 
>> 3) counted
>>   <limit> <start> do
>>     <action>
>>   loop
> 
>>> I suspect the best forth programmers are the ones who know how it fits
>>> together under the hood. There is compile time and runtime and input
>>> buffers all mixed in together. I expect a lot of newbies have no
>>> rational basis for guessing which combinations of operations make sense
>>> and which do not
>> Because Forth is extensible, understanding when things happen is
>> very important for advanced Forth programming. You need to get
>> to the point where the basics feel natural first.
> 
> This broaches a subject which is difficult to put into words because it
> is more a vague feeling than anything else. The feeling is that I was
> being increasingly taken over and steered by forth into places I didn't
> necessarily want to go.

Fascinating.  Can you think of some examples?

> In addition to their straight-forward nominal function, some forth words
> also seem to possess a "role" or "purpose" within the forth "scheme of
> things". That role is non-obvious and is never mentioned, but
> experienced forth programmers are aware of it intuitively it seems, even
> if they never have cause to view it in such terms.

That's very perceptive.  Most of Forth works the way it does because 
it's used in the internal implementation of the system, and is *also* 
available to the application programmer.

> One of my recurring frustrations when learning forth was repeatedly (and
> I felt undeservedly) finding myself painted into a corner. The symptoms
> were that the going kept getting unaccountably harder, the further I
> proceeded along a certain path. It was like I had unwittingly taken a
> wrong turn which I could only realize further down the track. The "wrong
> turn" had no symptoms of its own. However, if I had made a mistake
> anywhere, that is where it happened.
> 
> I will try to draw an analogy with something more concrete from the real
> world. ...

A Forth example would be a lot more helpful than an analogy, here!

> Back to forth. Let's start with the project-specific words you define
> early in a project yourself. If your earlier ones turn out to be not
> quite what they otherwise might have been (which at that point seemed
> entirely a matter for your own judgment and discretion), they will still
> perform the most immediate tasks you have for them. But, further down
> the track, you try to coerce them against some seemingly innate
> reluctance into doing things they can eventually be made to do, even if
> not quite the way you would have preferred. What has happened is that
> you are trying to employ them contrary to some originally conceived role
> or purpose.

Chuck Moore used to write programs three times.  The first time, he took 
a simple approach aiming to get the essence of the problem.  Then he 
tried to accommodate all the special cases, options, and added 
facilities, and the program became a mess.  Then he threw it all out and 
re-wrote the program from scratch, as he now fully understood it.  Most 
of us have gone through most of those steps... but it's necessary to 
have the courage to do step three, rather than continue to try to muddle 
through.  It usually saves time in the end.

> Extrapolate that to the standard forth vocabulary. My suspicion is that
> many common forth words do have an implicit 'role' within the forth
> scheme of things which is "obvious" to those who have grown up with it,
> but non-obvious and unexplained to anyone else unless how forth is
> implemented is added to the start of their learning curve. 

As I said above, most Forth words are used by the system at the lowest 
levels.  That is their primary purpose, and why they work the way they 
do.  This is one of the reasons that learning with OF is especially 
challenging, because although you can do SEE's to look at words, you 
don't really have any source.  We supply the source with all our 
products.  You can see lots of examples of how words are used.

I have tried to address much of this in my books, but would always 
appreciate any examples of something you find particularly opaque.

> I am sure I could recollect plenty of examples of being steered off
> course by seemingly role-conscious forth words just by going back over
> the source code of my recent marathon. Jonah Thomas mentions one in his
> separate followup. Let me know if you would like to see more.

Yes, I'd love that.

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."
==================================================

Jonah Thomas <jethomas5@gmail.com> writes:
>Second point. The Forth */ does not round. Its division truncates.

Or floors.  You can approximate a rounding */ as follows:

: */r ( n1 n2 n3 -- n4 )
  >r m* r@ 2/ m+ r> fm/mod nip ;

There will still be a little bias if the divisor is odd, though.  You
could correct for that by adding (or, for negative divisors,
subtracting) 1 about half of the time.

- 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.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

Elizabeth D Rather <erather@forth.com> writes:
>Chuck Moore used to write programs three times.  The first time, he took 
>a simple approach aiming to get the essence of the problem.  Then he 
>tried to accommodate all the special cases, options, and added 
>facilities, and the program became a mess.

Fred Brooks called this the "second-system effect".  The difference
was that already the simple approach was delivered as a product, and
then the same people are supposed to deliver an enhanced product, and
that becomes a mess.

> Then he threw it all out and 
>re-wrote the program from scratch, as he now fully understood it.  Most 
>of us have gone through most of those steps... but it's necessary to 
>have the courage to do step three, rather than continue to try to muddle 
>through.  It usually saves time in the end.

That's interesting.  Brooks also wrote "Plan to throw one away"; but
you suggest to plan to throw two away, doing the first and the second
system already during the development of the first product.

- 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.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

> > - Missing language constructs that are typically present in other
On Nov 28, 9:32=A0am, tinke...@optusnet.com.au (Tinkerer Atlarge) wrote:
> Doug Hoffman <glide...@gmail.com> wrote:
> > On Nov 28, 12:13 am, tinke...@optusnet.com.au (Tinkerer Atlarge)
> > wrote:

....

> > Would you mind elaborating a bit on the specific aspect(s) of learning
> > Forth that you found to be most difficult?

Wow.  Seeing the "development environment" you were using I'm hard
pressed to imagine worse conditions under which to learn Forth.  Maybe
submitting a deck of punch cards to be run overnight on a mainframe
(turn around cycle =3D one day, as I did it in college).  As others have
said, I'm amazed you got as far as you did/



> > - RPN arithmetic?
>
> The arithmetic itself is not the problem. The difficulty is in spotting
> errors, such as when, out of habit, an operator is put before rather
> than after its arg.

Yes.  The ability to write a word, run it, see the error, correct it
and run it again all in a matter of 5-10 seconds is incredibly
helpful.  Your learning curve in a normal environment would have been
far shorter and more productive.

A typical professional Forth allows for easy on-screen lookup of what
each word does in a fraction of a second.  I can't always remember
stack effects and so forth, but there is no need with a proper
development system.  Again, you did well to get as far as you did.

Appreciate the feedback.

-Doug

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Elizabeth D Rather <erather@forth.com> writes:
> >Chuck Moore used to write programs three times.  The first time, he took 
> >a simple approach aiming to get the essence of the problem.  Then he 
> >tried to accommodate all the special cases, options, and added 
> >facilities, and the program became a mess.

> Fred Brooks called this the "second-system effect".  The difference
> was that already the simple approach was delivered as a product, and
> then the same people are supposed to deliver an enhanced product, and
> that becomes a mess.

> > Then he threw it all out and 
> >re-wrote the program from scratch, as he now fully understood it.  Most 
> >of us have gone through most of those steps... but it's necessary to 
> >have the courage to do step three, rather than continue to try to muddle 
> >through.  It usually saves time in the end.

> That's interesting.  Brooks also wrote "Plan to throw one away"; but
> you suggest to plan to throw two away, doing the first and the second
> system already during the development of the first product.

Well, you could argue that Chuck's second implementation was really
the first correct and complete one, so there isn't really much of a
difference.

Andrew.

Thank you for replying! I think this is the first reply I've had on
these concepts.

anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> Jonah Thomas <jethomas5@gmail.com> writes:
> >Second point. The Forth */ does not round. Its division truncates.
> 
> Or floors.  You can approximate a rounding */ as follows:
> 
> : */r ( n1 n2 n3 -- n4 )
>   >r m* r@ 2/ m+ r> fm/mod nip ;
> 
> There will still be a little bias if the divisor is odd, though.  You
> could correct for that by adding (or, for negative divisors,
> subtracting) 1 about half of the time.

Yes, you can make a rounding version of */ . I've never heard of anybody
using one. I wrote one in Forth a long time ago and never used it except
for testing. It improved the result on average by half a bit. It was
written in Forth which at that time was considerably slower than */
written in assembler.

I'd expect the difference to be somewhat less important for 32-bit or
64-bit systems than for 16-bit. While you will on average use smaller
numbers more often than larger numbers, still you have the opportunity
to use larger numbers for which half a bit improvement is less important
than usual.

I claim that continued-fraction results will be less optimal for */ than
they would be for arithmetic that rounds, and so other solutions might
be better for */ . I gave some examples that I say give better results
for pi in 16-bits with */ .

Even for arithmetic that rounds, the continued fraction method is
designed to find the rational approximation which comes closest to the
actual value. I do not yet have a proof or a disproof of the idea that
some other rational approximation might give the best 16-bit value more
often, or the best 32-bit value etc. While a rational approximation that
is significantly worse than the best one cannot give good results, the
pattern of rounding errors might possibly be better for something that
isn't the continued-fraction best -- or possibly it's provable that this
can't happen.

On Sun, 29 Nov 2009 16:34:26 +1000, tinkerer@optusnet.com.au (Tinkerer
Atlarge) wrote:

>> Because Forth is extensible, understanding when things happen is
>> very important for advanced Forth programming. You need to get
>> to the point where the basics feel natural first.
>
>This broaches a subject which is difficult to put into words because it
>is more a vague feeling than anything else. The feeling is that I was
>being increasingly taken over and steered by forth into places I didn't
>necessarily want to go.
>
>In addition to their straight-forward nominal function, some forth words
>also seem to possess a "role" or "purpose" within the forth "scheme of
>things". That role is non-obvious and is never mentioned, but
>experienced forth programmers are aware of it intuitively it seems, even
>if they never have cause to view it in such terms.

This is a characteristic of extensible languages that fully expose
their kernels. I had a similar experience learning Smalltalk.
Historically, Forth systems were very compact, and every word
had to justify its existence. The resulting Forth kernel is
a collection of words that can be said to be greater than the
sum of its parts. I'm still learning Forth, and one conclusion is
that it's a very subtle language. Also, compared to C, you have
to learn a much larger number of "names of things" to be fluent.

The transition from a conventional "batch" language in the C and
Pasgol tradition to an interactive and extensible language is a
change of mindset, especially when taking an exposed RPN stack
into account.

The first Forth application I was paid for was a colour graphics
picture editor. The client wanted names for objects. Once I realised
that Forth already had namespaces (dictionary and vocabularies)
and that I could create simple classes (CREATE ... DOES>) the
job took five working days to delivery.

As Elizabeth has said, by learning on a system without fully
interactive development, you are throwing away most of the
nature of Forth. The interactivity is *essential*. There are
plenty of Forths available, and IMHO (with an axe to grind)
the evaluation versions of the commercial Forths have superior
documentation (dons flame-proof suit).

>> I shall be updating my book for 2010, so please feel free to
>> contact me directly with comments and questions.
>
>If I find anything worth querying or remarking on while reading the
>current edition I will gladly let you know.

Thank you.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
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.mpeforth.com - free VFX Forth downloads

Jonah Thomas <jethomas5@gmail.com> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> Jonah Thomas <jethomas5@gmail.com> writes:
>> >Second point. The Forth */ does not round. Its division truncates.
>> 
>> Or floors.  You can approximate a rounding */ as follows:
>> 
>> : */r ( n1 n2 n3 -- n4 )
>>   >r m* r@ 2/ m+ r> fm/mod nip ;
>> 
>> There will still be a little bias if the divisor is odd, though.  You
>> could correct for that by adding (or, for negative divisors,
>> subtracting) 1 about half of the time.
>
>Yes, you can make a rounding version of */ . I've never heard of anybody
>using one. I wrote one in Forth a long time ago and never used it except
>for testing. It improved the result on average by half a bit. It was
>written in Forth which at that time was considerably slower than */
>written in assembler.

Let's see how much the speed of */R suffers from being written in
Forth; results measured with a modified variant of contrib/divspeed.fs
on a 3Ghz Core 2 Duo E8400:

/       1512 ms
mod     1516 ms
/mod    1520 ms
*/      1748 ms
*/forth 2420 ms
*/r     2844 ms
*/mod   1876 ms
fm/mod  1824 ms
sm/rem  1493 ms
um/mod  1064 ms
m*/     7248 ms

So that's a slowdown by a factor of 1.38 of the */forth (written in
Forth) compared to the */ in native code (with the same
functionality), and a slowdown by a factor of 1.6 of the rounding */R
compared to */.  And if you want to determine whether you use flooring
or truncation, the simplest way is to define your own */ in Forth
anyway.

>I claim that continued-fraction results will be less optimal for */ than
>they would be for arithmetic that rounds, and so other solutions might
>be better for */ .

I also believe that you will generally get more accurate results with
*/R than with */, at least if you want a result that's nearest the
actual result.  That's because you will choose a fraction that's a
little bigger than the number you want to approximate in order to get
the same number of too-small and too-large results.  As a result, the
too-small results will be for smaller inputs (where the truncation
dominates over the too-large factor), and the too-large results will
be for the larger inputs.  With */R and an appropriate fraction, there
will be much less of this problem.

Of course, the fraction will still be a little larger or a little
smaller than the number you are approximating.  You can correct for
this by having a different offset instead of the 0 for */ or n3/2 for
*/R, leading to a word like

: *+/ ( n1 n2 n3 n4 -- n5 )
\ n5=(n1*n2+n3)/n4
  >r >r m* r> m+ r> fm/mod nip ;

The best offset depends on the input range; in particular, for the
full integer range you will use something n4/2 as offset (so negative
results are similar to positive results), whereas things get more
interesting if you are only interested in positive inputs.

My guess for a good offset would be:

n3 = (n1avg*r-floor(n1avg*n2/n4))*n4

where n2, n4 are as above, r is the number you are approximating, and
n1avg = (n1_max+n1_min)/2, i.e., the middle of the input range for n1.

- 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.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

On Nov 29, 12:27=A0am, Elizabeth D Rather <erat...@forth.com> wrote:
> Tinkerer Atlarge wrote:
> > Stephen Pelc <stephen...@mpeforth.com> wrote:
> ...
> >> I'm one of those people who can only really learn a language by
> >> having a job to do with it. I think it's a matter of focus.
>
> > Yes, without that, I find the incentive to grapple with a strange and
> > unfamiliar language simply isn't there. There is a large palette of
> > forth words to choose from. Initially, trying to winnow them down to a
> > small enough working set in order to set them in my mind without having
> > to look up their stack effects every time is the problem. With the
> > version of forth I was using, the documentation itself posed a similar
> > problem, being a cut'n'paste from various sources. As Elizabeth pointed
> > out in another post, Apple's version does not even comply wiith its
> > generic namesake and appears to have very little user documentation of
> > its own. (It has three interfaces, perhaps the client interface is
> > better serviced)
>
> Indeed, you chose one of the most difficult paths for getting into
> Forth! =A0You have done well to get so far. =A0No useful documentation, n=
o
> source, no one to talk to. =A0You were very brave. =A0In retrospect, you
> might have saved some time by learning on a friendlier system until you
> got the basics down, and then seeing how they apply in OF.

There are still a few of us OF gurus around, but few are doing OF any
more, except Mitch, who is doing the OLPC stuff.  Most of the OF
sites, even Mitch's, haven't been update in a long time, but many are
still there.  Mitch is at: http://www.firmworks.com/

Sun's OF documentation is at:

http://playground.sun.com/1275/home.html

DaR

Dennis <druffer@worldnet.att.net> writes:
>There are still a few of us OF gurus around, but few are doing OF any
>more, except Mitch, who is doing the OLPC stuff.

But SPARC and IBM p-series systems are still using Open Firmware,
right?  The only problem is that there are not many sold of them these
days, with Apple switching to Intel and much of the Sun product line
being based on AMD or Intel CPUs.

Does the Playstation 3 or the Xbox 360 use Open Firmware?  If so, I
guess it does not help, because they have have locked the hardware
down, and probably made the firmware interfaces unavailable to almost
everyone so it stays locked.

- 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.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

Jonah Thomas wrote:
> Yes, you can make a rounding version of */ . I've never heard of
> anybody using one.

I use rounding together with */ in a few places in MINOS.  The way it's 
done is basically something like

: r*/ ( a b c -- r )  rot 2* -rot */ 1+ 2/ ;

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> Jonah Thomas <jethomas5@gmail.com> writes:
> >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> >> Jonah Thomas <jethomas5@gmail.com> writes:

> >> >Second point. The Forth */ does not round. Its division truncates.
> >> 
> >> Or floors.  You can approximate a rounding */ as follows:
> >> 
> >> : */r ( n1 n2 n3 -- n4 )
> >>   >r m* r@ 2/ m+ r> fm/mod nip ;
> >> 
> >> There will still be a little bias if the divisor is odd, though. 
> >You> could correct for that by adding (or, for negative divisors,
> >> subtracting) 1 about half of the time.
> >
> >Yes, you can make a rounding version of */ . I've never heard of
> >anybody using one. I wrote one in Forth a long time ago and never
> >used it except for testing. It improved the result on average by half
> >a bit. It was written in Forth which at that time was considerably
> >slower than */ written in assembler.
> 
> Let's see how much the speed of */R suffers from being written in
> Forth; results measured with a modified variant of contrib/divspeed.fs
> on a 3Ghz Core 2 Duo E8400:
> 
> /       1512 ms
> mod     1516 ms
> /mod    1520 ms
> */      1748 ms
> */forth 2420 ms
> */r     2844 ms
> */mod   1876 ms
> fm/mod  1824 ms
> sm/rem  1493 ms
> um/mod  1064 ms
> m*/     7248 ms
> 
> So that's a slowdown by a factor of 1.38 of the */forth (written in
> Forth) compared to the */ in native code (with the same
> functionality), and a slowdown by a factor of 1.6 of the rounding */R
> compared to */.  And if you want to determine whether you use flooring
> or truncation, the simplest way is to define your own */ in Forth
> anyway.

So with a modern Forth there's little reason to continue to use */ . */R
gives better results. System developers can provide optimised */R if
they want. If not, */R written in Forth is not so slow and as you say it
provides exactly the results you choose.
 
> >I claim that continued-fraction results will be less optimal for */
> >than they would be for arithmetic that rounds, and so other solutions
> >might be better for */ .
> 
> I also believe that you will generally get more accurate results with
> */R than with */, at least if you want a result that's nearest the
> actual result.  That's because you will choose a fraction that's a
> little bigger than the number you want to approximate in order to get
> the same number of too-small and too-large results.  As a result, the
> too-small results will be for smaller inputs (where the truncation
> dominates over the too-large factor), and the too-large results will
> be for the larger inputs.  With */R and an appropriate fraction, there
> will be much less of this problem.
> 
> Of course, the fraction will still be a little larger or a little
> smaller than the number you are approximating.  You can correct for
> this by having a different offset instead of the 0 for */ or n3/2 for
> */R, leading to a word like
> 
> : *+/ ( n1 n2 n3 n4 -- n5 )
> \ n5=(n1*n2+n3)/n4
>   >r >r m* r> m+ r> fm/mod nip ;
>
> The best offset depends on the input range; in particular, for the
> full integer range you will use something n4/2 as offset (so negative
> results are similar to positive results), whereas things get more
> interesting if you are only interested in positive inputs.
> 
> My guess for a good offset would be:
> 
> n3 = (n1avg*r-floor(n1avg*n2/n4))*n4
> 
> where n2, n4 are as above, r is the number you are approximating, and
> n1avg = (n1_max+n1_min)/2, i.e., the middle of the input range for n1.
 
If your rational approximation gives a result that isn't off by more
than 1, it may be hard to find a good offset. n4/2 looks particularly
good if your division truncates, since that lets you round, right? Was
that your subtle way of telling me to go ahead and round with */ instead
of compute an alternate rational fraction?

Oh well. Forth programmers have gone a very long time multiplying things
by pi in a way that was one bit low nearly half the time, and it seems
to have worked for them. Maybe arranging real-time algorithms so that
some errors don't propagate is more important than minimising those
errors.

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Jonah Thomas wrote:

> > Yes, you can make a rounding version of */ . I've never heard of
> > anybody using one.
> 
> I use rounding together with */ in a few places in MINOS.  The way
> it's done is basically something like
> 
> : r*/ ( a b c -- r )  rot 2* -rot */ 1+ 2/ ;

Thank you. That looks workable. It does cut the range in half.

Like, in 16 bits for pi your largest a is 10430 . Larger than that and
multiplying by pi will give an overflow for its result. With your method
the largest will be 5215. But that isn't so important for 32-bit or
larger Forths, right?

Jonah Thomas <jethomas5@gmail.com> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>> I also believe that you will generally get more accurate results with
>> */R than with */, at least if you want a result that's nearest the
>> actual result.  That's because you will choose a fraction that's a
>> little bigger than the number you want to approximate in order to get
>> the same number of too-small and too-large results.  As a result, the
>> too-small results will be for smaller inputs (where the truncation
>> dominates over the too-large factor), and the too-large results will
>> be for the larger inputs.  With */R and an appropriate fraction, there
>> will be much less of this problem.
>> 
>> Of course, the fraction will still be a little larger or a little
>> smaller than the number you are approximating.  You can correct for
>> this by having a different offset instead of the 0 for */ or n3/2 for
>> */R, leading to a word like
>> 
>> : *+/ ( n1 n2 n3 n4 -- n5 )
>> \ n5=(n1*n2+n3)/n4
>>   >r >r m* r> m+ r> fm/mod nip ;
>>
>> The best offset depends on the input range; in particular, for the
>> full integer range you will use something n4/2 as offset (so negative
>> results are similar to positive results), whereas things get more
>> interesting if you are only interested in positive inputs.
>> 
>> My guess for a good offset would be:
>> 
>> n3 = (n1avg*r-floor(n1avg*n2/n4))*n4
>> 
>> where n2, n4 are as above, r is the number you are approximating, and
>> n1avg = (n1_max+n1_min)/2, i.e., the middle of the input range for n1.
> 
>If your rational approximation gives a result that isn't off by more
>than 1, it may be hard to find a good offset. n4/2 looks particularly
>good if your division truncates, since that lets you round, right? Was
>that your subtle way of telling me to go ahead and round with */ instead
>of compute an alternate rational fraction?

No, I just followed a line of thought that suggested itself when I
considered that n2/n4 is not the value that we actually want to
multiply with.  Maybe n3=n4/2 for interesting values of r, n2, n4,
n1min, and n1max anyway, but if you want to search for combinations of
n2 and n4 for a given r, you could also try improving the result with
a custom n3.

- 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.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

Jonah Thomas wrote:
> Thank you for replying! I think this is the first reply I've had on
> these concepts.
> 
> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> 
>> Jonah Thomas <jethomas5@gmail.com> writes:
>>> Second point. The Forth */ does not round. Its division truncates.
>> Or floors.  You can approximate a rounding */ as follows:
>>
>> : */r ( n1 n2 n3 -- n4 )
>>   >r m* r@ 2/ m+ r> fm/mod nip ;
>>
>> There will still be a little bias if the divisor is odd, though.  You
>> could correct for that by adding (or, for negative divisors,
>> subtracting) 1 about half of the time.
> 
> Yes, you can make a rounding version of */ . I've never heard of anybody
> using one. I wrote one in Forth a long time ago and never used it except
> for testing. It improved the result on average by half a bit. It was
> written in Forth which at that time was considerably slower than */
> written in assembler.

If you need more precision than */ provides (single-length arguments, 
double-length intermediate product), why not just use M*/ (double 
multiplied by ratio of singles, triple-precision intermediate product)? 
  That's what most people do, and why there hasn't been any demand for a 
rounding */.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

Jonah Thomas wrote:

> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> Jonah Thomas wrote:
> 
>> > Yes, you can make a rounding version of */ . I've never heard of
>> > anybody using one.
>> 
>> I use rounding together with */ in a few places in MINOS.  The way
>> it's done is basically something like
>> 
>> : r*/ ( a b c -- r )  rot 2* -rot */ 1+ 2/ ;
> 
> Thank you. That looks workable. It does cut the range in half.

Indeed.  You can choose which range you want to be cut in half:

swap 2* swap */ 1+ 2/

also works, but cuts the other range into half.  It's probably one 
reason why I haven't factored that out (choosing which range is cut to 
half each time is more appropriate given how rarely it's needed).  */r 
seems to be the more appropriate name, though.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

Elizabeth D Rather <erather@forth.com> wrote:
> Jonah Thomas wrote: 
> > anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> >> Jonah Thomas <jethomas5@gmail.com> writes:

> >>> Second point. The Forth */ does not round. Its division truncates.
> >> Or floors.  You can approximate a rounding */ as follows:
> >>
> >> : */r ( n1 n2 n3 -- n4 )
> >>   >r m* r@ 2/ m+ r> fm/mod nip ;
> >>
> >> There will still be a little bias if the divisor is odd, though. 
> >You> could correct for that by adding (or, for negative divisors,
> >> subtracting) 1 about half of the time.
> > 
> > Yes, you can make a rounding version of */ . I've never heard of
> > anybody using one. I wrote one in Forth a long time ago and never
> > used it except for testing. It improved the result on average by
> > half a bit. It was written in Forth which at that time was
> > considerably slower than */ written in assembler.
> 
> If you need more precision than */ provides (single-length arguments, 
> double-length intermediate product), why not just use M*/ (double 
> multiplied by ratio of singles, triple-precision intermediate
> product)? 
>   That's what most people do, and why there hasn't been any demand for
> a rounding */.
 
I may have this wrong since I haven't tested it, but it looks to me like
what M*/ gives you is an extended domain. With */ you need n1*n2 to
still be a double -- it can overflow. With M*/ I think the overflow goes
away.

But you are still multiplying by a single-length n2 and dividing by a
single-length n3 and you still aren't rounding. So I don't expect any
improvement over the range that */ gives you. All it does is increase
the domain for n1.

Jonah Thomas wrote:
> Elizabeth D Rather <erather@forth.com> wrote:
>> Jonah Thomas wrote: 
>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>>>> Jonah Thomas <jethomas5@gmail.com> writes:
> 
>>>>> Second point. The Forth */ does not round. Its division truncates.
>>>> Or floors.  You can approximate a rounding */ as follows:
>>>>
>>>> : */r ( n1 n2 n3 -- n4 )
>>>>   >r m* r@ 2/ m+ r> fm/mod nip ;
>>>>
>>>> There will still be a little bias if the divisor is odd, though. 
>>> You> could correct for that by adding (or, for negative divisors,
>>>> subtracting) 1 about half of the time.
>>> Yes, you can make a rounding version of */ . I've never heard of
>>> anybody using one. I wrote one in Forth a long time ago and never
>>> used it except for testing. It improved the result on average by
>>> half a bit. It was written in Forth which at that time was
>>> considerably slower than */ written in assembler.
>> If you need more precision than */ provides (single-length arguments, 
>> double-length intermediate product), why not just use M*/ (double 
>> multiplied by ratio of singles, triple-precision intermediate
>> product)? 
>>   That's what most people do, and why there hasn't been any demand for
>> a rounding */.
>  
> I may have this wrong since I haven't tested it, but it looks to me like
> what M*/ gives you is an extended domain. With */ you need n1*n2 to
> still be a double -- it can overflow. With M*/ I think the overflow goes
> away.
> 
> But you are still multiplying by a single-length n2 and dividing by a
> single-length n3 and you still aren't rounding. So I don't expect any
> improvement over the range that */ gives you. All it does is increase
> the domain for n1.

You're concerned about rounding because you want all the bits you can 
get.  Using one of your numbers as a double and M*/ (which gives a 
double result) you have lots of bits that you can reduce as appropriate.

To review:

*/ multiplies 2 singles and divides by a single, with a double 
intermediate product.

M*/ multiplies a double by a single, with a triple intermediate product, 
and divides by a single, giving a double result.  Adjust your scale 
factor (the denominator) to give you the precision you desire.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

Marcel Hendrix <mhx@iae.nl> wrote:

> tinkerer@optusnet.com.au (Tinkerer Atlarge) writes Re: acceptance of forth
> 
> >Stephen Pelc <stephenXXX@mpeforth.com> wrote:
> 
> > On Sun, 29 Nov 2009 00:32:01 +1000, tinkerer@optusnet.com.au (Tinkerer
> > Atlarge) wrote:
> >> You have basically three choices as in any language:
>
[order of choices switched]
> >>
> >> 2) test at the bottom
> >>   begin
> >>     <action>
> >>     <test>
> >>   until
> 
> > Realizing its similarity to the "goto" loop was my breakthrough in
> > appreciating how simple 'begin:until' is beneath the surface.
> 
> Can you remember what you thought before the breakthrough?

I didn't think anything about it because, prior to that, it had nothing
to differentiate itself in my mind from other constructs also starting
with BEGIN. Keeping my finger on the page while I copied it into the
computer was the only way I could be sure I didn't accidentally switch
templates halfway through.

What I am talking about has as much to do with how to make these things
stick in our minds as how they work.

> With "until" I always have the problem remembering if it continues
> when <test> is TRUE, or when <test> is FALSE.

You're way ahead of me if you can remember that much about it.

> >> 1) test at the top
> >>   begin 
> >>     <test>
> >>    while
> >>     <action>
> >>   repeat

> > One of my recurring frustrations when learning forth was repeatedly (and
> > I felt undeservedly) finding myself painted into a corner. The symptoms
> > were that the going kept getting unaccountably harder, the further I
> > proceeded along a certain path. It was like I had unwittingly taken a
> > wrong turn which I could only realize further down the track. The "wrong
> > turn" had no symptoms of its own. However, if I had made a mistake
> > anywhere, that is where it happened.
> 
> Although this reads very nicely and heightens the user's anticipation of
> revelation to almost unbearable heights, I still do not quite grasp what
> you mean by this. My hypothesis is that you think new users may interpret
> the construct as testing once, before entering an infinite loop (i.e.
> repeat jumps to after while instead of after begin?)

I haven't had a chance to form such an opinion yet. I was responding
positively to the clarity of Stephen's template as instantly conveying
what I assumed was its meaning. However, on consulting other books and
looking back over the source code which is the most accurate record of
my forth learning experience, I now see that

1) begin..while..repeat has multiple templates (which, overlooked as it
was, might be enough to account for my confusion)

2) the way I have used it myself is more lilke a FOR loop where the body
leads up to the test, all within the <test> section. All I have used the
<action> part for is to increment a count. The secret might be to forget
about constructs and consider the action of WHILE and REPEAT as entities
in their own right which only need BEGIN as an end-marker for their own
purposes. But that is just me thinking aloud. I don't claim to know yet.

To understand where I am coming from you need to visualize the
circumstances where I consulted the books. The first time I read them in
genuine book-reading mode. The Loops section came up, full of
hard-to-remember detail, right at the end of my attention span.

In subsequent readings I was using them as reference books, trying to
find the appropriate looping construct for what I needed as quickly as
possible. (All languages I have used in the past have them, and I have
never had difficulty finding the right one before). If I had someone
there to tell me which one to use I would gladly have taken their word
for it without being distracted by their theoretical implications.

> Although your analogies are very nice, like other readers of this thread
> I am dying to hear some concrete examples. Please!  

That will take a bit more time as I have a lot of code to sift through
first. I will try to answer it in another post.

Dennis <druffer@worldnet.att.net> wrote:

> There are still a few of us OF gurus around, but few are doing OF any
> more, except Mitch, who is doing the OLPC stuff.  Most of the OF
> sites, even Mitch's, haven't been update in a long time, but many are
> still there.  Mitch is at: http://www.firmworks.com/

I was interested in some of the OF publications I saw advertised on that
website, but their order form was dated 1997 and the latest date I could
find on the site was 2002, so I decided not to risk sending my credit
card details. (For all I knew the premises might have been taken over by
an escort agency or something). Are they still where they were in 2002,
and do you think it is worth a shot?
 

Tinkerer Atlarge wrote:
> Dennis <druffer@worldnet.att.net> wrote:
> 
>> There are still a few of us OF gurus around, but few are doing OF any
>> more, except Mitch, who is doing the OLPC stuff.  Most of the OF
>> sites, even Mitch's, haven't been update in a long time, but many are
>> still there.  Mitch is at: http://www.firmworks.com/
> 
> I was interested in some of the OF publications I saw advertised on that
> website, but their order form was dated 1997 and the latest date I could
> find on the site was 2002, so I decided not to risk sending my credit
> card details. (For all I knew the premises might have been taken over by
> an escort agency or something). Are they still where they were in 2002,
> and do you think it is worth a shot?
>  

They still exist and the site hasn't been taken over, but they're pretty 
inactive.  I'd advise sending an email to the address on the site, 
info@firmworks.com and ask if it's still possible to purchase a manual, 
and if so, which one they recommend (describe what you're doing). 
"Writing FCode Programs for PCI" is the most useful, IMO, but also quite 
expensive last time I bought some (for an OF course I was teaching).

My advice about getting a "normal" forth that runs on your platform 
still holds.  OF is a tortuous way to learn Forth.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

Tinkerer Atlarge wrote:
> Marcel Hendrix <mhx@iae.nl> wrote:
....
>> Can you remember what you thought before the breakthrough?
> 
> I didn't think anything about it because, prior to that, it had nothing
> to differentiate itself in my mind from other constructs also starting
> with BEGIN. Keeping my finger on the page while I copied it into the
> computer was the only way I could be sure I didn't accidentally switch
> templates halfway through.
> 
> What I am talking about has as much to do with how to make these things
> stick in our minds as how they work.
> 
>> With "until" I always have the problem remembering if it continues
>> when <test> is TRUE, or when <test> is FALSE.
> 
> You're way ahead of me if you can remember that much about it.
> 
>>>> 1) test at the top
>>>>   begin 
>>>>     <test>
>>>>    while
>>>>     <action>
>>>>   repeat

The way I remember the BEGIN structures is:

1. BEGIN. Test something.  WHILE it is 'true', do the stuff in the loop 
and REPEAT back to the BEGIN.  In other words, continue looping WHILE 
some condition exists.

2. BEGIN. Do the stuff in the loop and check something.  Continue UNTIL 
your test is 'true'.  In other words, continue looping UNTIL an event 
occurs.

When to use an indefinite loop (e.g. BEGIN stuff):

A. If you want to loop either *as long as* something is true, or *until* 
an event occurs.

B. If you don't need to know how many times you've done it.

When to use a finite loop (e.g. DO and friends):

A. If you know in advance the maximum number of times you want to do the 
stuff.

B. If you need access to the loop counter.

C. If you have a specific range of values you need to do it for.

> ...However, on consulting other books and
> looking back over the source code which is the most accurate record of
> my forth learning experience, I now see that
> 
> 1) begin..while..repeat has multiple templates (which, overlooked as it
> was, might be enough to account for my confusion)

Sorry, don't understand what "multiple templates" you mean.

> 2) the way I have used it myself is more lilke a FOR loop where the body
> leads up to the test, all within the <test> section. All I have used the
> <action> part for is to increment a count. The secret might be to forget
> about constructs and consider the action of WHILE and REPEAT as entities
> in their own right which only need BEGIN as an end-marker for their own
> purposes. But that is just me thinking aloud. I don't claim to know yet.

If you're incrementing a count, it sounds more like a DO structure would 
be appropriate.

> To understand where I am coming from you need to visualize the
> circumstances where I consulted the books. The first time I read them in
> genuine book-reading mode. The Loops section came up, full of
> hard-to-remember detail, right at the end of my attention span.

Yeah, it's really hard to learn a language without writing code.  Like 
learning to swim without getting wet.

> In subsequent readings I was using them as reference books, trying to
> find the appropriate looping construct for what I needed as quickly as
> possible. (All languages I have used in the past have them, and I have
> never had difficulty finding the right one before). If I had someone
> there to tell me which one to use I would gladly have taken their word
> for it without being distracted by their theoretical implications.

There are no "theoretical implications".  There are basically three loop 
forms, two "indefinite" loops (you don't know how many times you need to 
do it) and one "finite" loop (you *do* know at least the maximum number 
of repeats), and a few minor variations on each.  You use the one that 
yields the least code for what you're trying to do.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

Elizabeth D Rather <erather@forth.com> wrote:

> When to use a finite loop (e.g. DO and friends):
> 
> A. If you know in advance the maximum number of times you want to do the
> stuff.
> 
> B. If you need access to the loop counter.
> 
> C. If you have a specific range of values you need to do it for.

The DO loop was the one I initially tried to use for everything. The
reason, I guess, was old prejudices die hard. I tend to favour loops
with the loop count arithmetic built into the loop structure, forgetting
that forth can do arithmetic inside or outside a loop's control
mechanism just as fast.

One reason I ended up taking another look at the alternatives was
because the OF debugger crashed whenever it encountered a DO loop. Only
recently was I pleasantly surprised to find out that didn't happen with
the other loop constructs. (So there, in a very limited sense, is an
example of being steered along a path because of the computer's
preferences rather than my own. Not that I'm blaming "forth" this time,
of course ;-)

> > ...However, on consulting other books and
> > looking back over the source code which is the most accurate record of
> > my forth learning experience, I now see that
> > 
> > 1) begin..while..repeat has multiple templates (which, overlooked as it
> > was, might be enough to account for my confusion)
> 
> Sorry, don't understand what "multiple templates" you mean.

Take a look at page 56 of Forth Application Techniques (sect 3.7). To my
mind, each line in bold type is a template in the sense that all you
need to do (even if you're a computer) is fill in the blanks. When I was
writing for Z80 and 6502, all I needed in the way of help was a
laminated cheat sheet with skeleton hints like that on both sides. In
fact my first Z80 assembler was nothing more than a computerised version
of one of those cheat-sheets. (That was after I had done lots of reading
getting to the point where a memory jog or a key detail was all I ever
needed to look at, of course).

I thank you and everyone else for all your help. It has all been taken
on board and has satisfied most of the unresolved issues I had with
forth when I first joined this thread. I will still try to come back
with the forth example or two I was talking about and which I promised.

Kindest regards,

Tink

Tinkerer Atlarge wrote: <1j9zm4j.qzwbt6zit6moN%tinkerer@optusnet.com.au>
> The secret might be to forget about constructs and consider the action
> of WHILE and REPEAT as entities in their own right which only need
> BEGIN as an end-marker for their own purposes. But that is just me
> thinking aloud. I don't claim to know yet.

You could do that.  It's probably better to start by just using the
basic three constructions, but I do somewhat think of them as individual
pieces.

My understanding goes something like this:

Forth has an unconditional branch and a branch-if-false.  It also
differentiates between forward and backward branches.  So we have six
basic words to compile these branches, and three convenience words which
combine the basic operations.  These words use a stack at compile-time:


Forward Branches
----------------

IF/AHEAD ( -- branch )

	Compile a forward (conditional?) branch, leaving a reference so we
	can point it to the right place later.

THEN ( branch -- )

	Resolve `branch` to jump here.

ELSE ( branch1 -- branch2 )  AHEAD SWAP THEN ; IMMEDIATE

	                          -------------------->
	Usually `IF <true-action> ELSE <false-action> THEN`.
	         ---------------------->

	It ends the <true-action> section with an unconditional `branch2`
	which skips over the <false-action>, and then resolves the
	branch-if-false from the IF (so that it jumps here to begin the
	<false-action> section).


Backward Branches
-----------------

BEGIN ( -- addr )

	Push a marker so that we can branch (loop) back to it.

UNTIL/AGAIN ( addr -- )

	Loop (conditially?) back to the most recent BEGIN.

WHILE ( addr -- branch addr )  IF SWAP ; IMMEDIATE

	                      --------------------->
	Usually `BEGIN <test> WHILE <action> REPEAT`
	             <-----------------------

	Branch forward out of a loop (putting the branch *under* the BEGIN
	addr).

: REPEAT ( branch addr -- )  AGAIN THEN ;  IMMEDIATE

	loop back to the most recent BEGIN, then resolve the WHILE branch to
	jump just outside the loop.


Then you can do crazy things like:

	BEGIN <test1> WHILE <test2> WHILE
		<action>
	REPEAT <failed-test2> ELSE <failed-test1> THEN

:-)

--Josh

On Nov 29, 7:41=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> Dennis <druf...@worldnet.att.net> writes:
> >There are still a few of us OF gurus around, but few are doing OF any
> >more, except Mitch, who is doing the OLPC stuff.
>
> But SPARC and IBM p-series systems are still using Open Firmware,
> right? =A0The only problem is that there are not many sold of them these
> days, with Apple switching to Intel and much of the Sun product line
> being based on AMD or Intel CPUs.
>
> Does the Playstation 3 or the Xbox 360 use Open Firmware? =A0If so, I
> guess it does not help, because they have have locked the hardware
> down, and probably made the firmware interfaces unavailable to almost
> everyone so it stays locked.

No OF there.  The OLPC systems are the only new systems I'm aware of.

DaR

> - anton
> --
> M. Anton Ertl =A0http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs:http://www.complang.tuwien.ac.at/forth/faq/toc.html
> =A0 =A0 =A0New standard:http://www.forth200x.org/forth200x.html
> =A0 =A0EuroForth 2009:http://www.euroforth.org/ef09/

On Nov 29, 4:51=A0pm, tinke...@optusnet.com.au (Tinkerer Atlarge) wrote:
> Dennis <druf...@worldnet.att.net> wrote:
> > There are still a few of us OF gurus around, but few are doing OF any
> > more, except Mitch, who is doing the OLPC stuff. =A0Most of the OF
> > sites, even Mitch's, haven't been update in a long time, but many are
> > still there. =A0Mitch is at:http://www.firmworks.com/
>
> I was interested in some of the OF publications I saw advertised on that
> website, but their order form was dated 1997 and the latest date I could
> find on the site was 2002, so I decided not to risk sending my credit
> card details. (For all I knew the premises might have been taken over by
> an escort agency or something). Are they still where they were in 2002,
> and do you think it is worth a shot?

I would call them before sending money.  Not sure what you are trying
to buy.  The IEEE specs can be gotten directly from IEEE.  I always
had access to the docs from Apple, so I never had to pay for them, but
I no longer have that access.

DaR

Elizabeth D Rather <erather@forth.com> writes:
>Jonah Thomas wrote:
>> Thank you for replying! I think this is the first reply I've had on
>> these concepts.
>> 
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>> 
>>> Jonah Thomas <jethomas5@gmail.com> writes:
>>>> Second point. The Forth */ does not round. Its division truncates.
>>> Or floors.  You can approximate a rounding */ as follows:
>>>
>>> : */r ( n1 n2 n3 -- n4 )
>>>   >r m* r@ 2/ m+ r> fm/mod nip ;
>>>
>>> There will still be a little bias if the divisor is odd, though.  You
>>> could correct for that by adding (or, for negative divisors,
>>> subtracting) 1 about half of the time.
>> 
>> Yes, you can make a rounding version of */ . I've never heard of anybody
>> using one. I wrote one in Forth a long time ago and never used it except
>> for testing. It improved the result on average by half a bit. It was
>> written in Forth which at that time was considerably slower than */
>> written in assembler.
>
>If you need more precision than */ provides (single-length arguments, 
>double-length intermediate product), why not just use M*/ (double 
>multiplied by ratio of singles, triple-precision intermediate product)? 
>  That's what most people do, and why there hasn't been any demand for a 
>rounding */.

If I understand you correctly, you suggest changing the scale factor
for the fixed-point arithmetic, so the systematic error of the
flooring/truncating in */ is reduced; and this scale factor requires
representing the fixed-point numbers as doubles instead of as singles.

I don't think this is the best answer to the problem, because:

1) There will still be a bias, even though it will be smaller after
scaling.

2) The performance of this approach will be worse.  Not only is M*/
much slower than */R (2.5 times for Gforth on a Core 2 Duo E8400):

*/r     2844 ms
m*/     7248 ms

you also have the overhead of doubles instead of singles for the
fixed-point numbers everywhere, or at least of converting to and from the
double-based fixed-point representation around M*/.

There may be good reasons for using a scale factor that requires
doubles, but avoiding */R is not one of them.

- 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.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

Anton Ertl wrote:
> Elizabeth D Rather <erather@forth.com> writes:
....
>> If you need more precision than */ provides (single-length arguments, 
>> double-length intermediate product), why not just use M*/ (double 
>> multiplied by ratio of singles, triple-precision intermediate product)? 
>>  That's what most people do, and why there hasn't been any demand for a 
>> rounding */.
> 
> If I understand you correctly, you suggest changing the scale factor
> for the fixed-point arithmetic, so the systematic error of the
> flooring/truncating in */ is reduced; and this scale factor requires
> representing the fixed-point numbers as doubles instead of as singles.
> 
> I don't think this is the best answer to the problem, because:
> 
> 1) There will still be a bias, even though it will be smaller after
> scaling.
> 
> 2) The performance of this approach will be worse.  Not only is M*/
> much slower than */R (2.5 times for Gforth on a Core 2 Duo E8400):
> 
> */r     2844 ms
> m*/     7248 ms
> 
> you also have the overhead of doubles instead of singles for the
> fixed-point numbers everywhere, or at least of converting to and from the
> double-based fixed-point representation around M*/.
> 
> There may be good reasons for using a scale factor that requires
> doubles, but avoiding */R is not one of them.

I thought the whole point was to find good approximations for continuing 
fractions.  Surely that isn't something you do in real-time (more like 
getting the ratio you need on a one-time basis)?  Why would performance 
be an issue?

The objection to a rounding */ being added to the language is based on 
the assumption that folks would use it in preference to */, in which 
case the performance hit would be significant, but I can't think that's 
much of an issue in continued fractions.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

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

Elizabeth D Rather <erather@forth.com> writes:
>Anton Ertl wrote:
>> 2) The performance of this approach will be worse.  Not only is M*/
>> much slower than */R (2.5 times for Gforth on a Core 2 Duo E8400):
>> 
>> */r     2844 ms
>> m*/     7248 ms
>> 
>> you also have the overhead of doubles instead of singles for the
>> fixed-point numbers everywhere, or at least of converting to and from the
>> double-based fixed-point representation around M*/.
>> 
>> There may be good reasons for using a scale factor that requires
>> doubles, but avoiding */R is not one of them.
>
>I thought the whole point was to find good approximations for continuing 
>fractions.

The question was how to use the approximation (*/, */R, M*/ or maybe
*+/?).  And what's the best approximation for a given way of using it.

The way that Jonah Thomas finds the approximations is AFAIK with
floating point computations.

>Surely that isn't something you do in real-time (more like 
>getting the ratio you need on a one-time basis)?  Why would performance 
>be an issue?

The use will happen at run-time.

>The objection to a rounding */ being added to the language is based on 
>the assumption that folks would use it in preference to */, in which 
>case the performance hit would be significant,

But it would give a different result.  If you want the closest integer
to the true result, */R is superior to */ (even if */ is used an
approximation tuned to correct for the flooring of */).  If being 1/2
ulp low is no problem, then */ is fine; but if you need more
precision, */R is one of the options.

- 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.forth200x.org/forth200x.html
   EuroForth 2009: http://www.euroforth.org/ef09/

anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> Elizabeth D Rather <erather@forth.com> writes:
> >Jonah Thomas wrote:
> >> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> >>> Jonah Thomas <jethomas5@gmail.com> writes:

> >>>> Second point. The Forth */ does not round. Its division
> >truncates.>> Or floors.  You can approximate a rounding */ as
> >follows:>>
> >>> : */r ( n1 n2 n3 -- n4 )
> >>>   >r m* r@ 2/ m+ r> fm/mod nip ;
> >>>
> >>> There will still be a little bias if the divisor is odd, though. 
> >You>> could correct for that by adding (or, for negative divisors,
> >>> subtracting) 1 about half of the time.
> >> 
> >> Yes, you can make a rounding version of */ . I've never heard of
> >anybody> using one. I wrote one in Forth a long time ago and never
> >used it except> for testing. It improved the result on average by
> >half a bit. It was> written in Forth which at that time was
> >considerably slower than */> written in assembler.
> >
> >If you need more precision than */ provides (single-length arguments,
> >
> >double-length intermediate product), why not just use M*/ (double 
> >multiplied by ratio of singles, triple-precision intermediate
> >product)? 
> >  That's what most people do, and why there hasn't been any demand
> >  for a 
> >rounding */.
> 
> If I understand you correctly, you suggest changing the scale factor
> for the fixed-point arithmetic, so the systematic error of the
> flooring/truncating in */ is reduced; and this scale factor requires
> representing the fixed-point numbers as doubles instead of as singles.
> 
> I don't think this is the best answer to the problem, because:
> 
> 1) There will still be a bias, even though it will be smaller after
> scaling.
> 
> 2) The performance of this approach will be worse.  Not only is M*/
> much slower than */R (2.5 times for Gforth on a Core 2 Duo E8400):
> 
> */r     2844 ms
> m*/     7248 ms
> 
> you also have the overhead of doubles instead of singles for the
> fixed-point numbers everywhere, or at least of converting to and from
> the double-based fixed-point representation around M*/.
> 
> There may be good reasons for using a scale factor that requires
> doubles, but avoiding */R is not one of them.
 
I may have misunderstood what Elizabeth was saying, but what I thought
she meant (the second time around after I misunderstood the first time)
was something like this:

: */r
   >R 0 -ROT R>
   M*/
   SWAP 0< 1 AND + ;

I haven't tested this code but as written it's clearly only for positive
numbers and there may be other gotchas.

The idea is, to do the equivalent of x n r */r you can make x and only x
double with the x part in the high word (which should be done before the
routine starts and before n r are put on the stack). Then you do M*/ and
something like a remainder is left in the low word. Use that to round
and you're done. I wasn't going to respond until I was sure I understood
it, but here I am responding early anyway.

anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> Elizabeth D Rather <erather@forth.com> writes:
> >Jonah Thomas wrote:
> >> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> >>> Jonah Thomas <jethomas5@gmail.com> writes:

> >>>> Second point. The Forth */ does not round. Its division
> >truncates.>> Or floors.  You can approximate a rounding */ as
> >follows:>>
> >>> : */r ( n1 n2 n3 -- n4 )
> >>>   >r m* r@ 2/ m+ r> fm/mod nip ;
> >>>
> >>> There will still be a little bias if the divisor is odd, though. 
> >You>> could correct for that by adding (or, for negative divisors,
> >>> subtracting) 1 about half of the time.
> >> 
> >> Yes, you can make a rounding version of */ . I've never heard of
> >anybody> using one. I wrote one in Forth a long time ago and never
> >used it except> for testing. It improved the result on average by
> >half a bit. It was> written in Forth which at that time was
> >considerably slower than */> written in assembler.
> >
> >If you need more precision than */ provides (single-length arguments,
> >
> >double-length intermediate product), why not just use M*/ (double 
> >multiplied by ratio of singles, triple-precision intermediate
> >product)? 
> >  That's what most people do, and why there hasn't been any demand
> >  for a 
> >rounding */.
> 
> If I understand you correctly, you suggest changing the scale factor
> for the fixed-point arithmetic, so the systematic error of the
> flooring/truncating in */ is reduced; and this scale factor requires
> representing the fixed-point numbers as doubles instead of as singles.
> 
> I don't think this is the best answer to the problem, because:
> 
> 1) There will still be a bias, even though it will be smaller after
> scaling.
> 
> 2) The performance of this approach will be worse.  Not only is M*/
> much slower than */R (2.5 times for Gforth on a Core 2 Duo E8400):
> 
> */r     2844 ms
> m*/     7248 ms
> 
> you also have the overhead of doubles instead of singles for the
> fixed-point numbers everywhere, or at least of converting to and from
> the double-based fixed-point representation around M*/.
> 
> There may be good reasons for using a scale factor that requires
> doubles, but avoiding */R is not one of them.
 
I may have misunderstood what Elizabeth was saying, but what I thought
she meant (the second time around after I misunderstood the first time)
was something like this:

: */r
   >R 0 -ROT R>
   M*/
   SWAP 0< 1 AND + ;

I haven't tested this code but as written it's clearly only for positive
numbers and there may be other gotchas.

The idea is, to do the equivalent of x n r */r you can make x and only x
double with the x part in the high word (which should be done before the
routine starts and before n r are put on the stack). Then you do M*/ and
something like a remainder is left in the low word. Use that to round
and you're done. I wasn't going to respond until I was sure I understood
it, but here I am responding early anyway.

On Nov 30, 4:06=A0pm, Jonah Thomas <jethom...@gmail.com> wrote:

....

> Then you do M*/ and
> something like a remainder is left in the low word. Use that to round
> and you're done.

This is off topic but perhaps related.  The general issue being how to
round off data such that a bias is not introduced.

I run into this when there is a legal "pass/fail" decision to be made
on the performance of a product.

Consider the case when we have decided that the output from our
measuring instrument is accurate to a certain number of digits.  For
discussion let's say that is 5 decimal digits to the right of the
decimal point.  The raw data is then rounded to the legal number of
places and compared to the pass/fail standard.  Let's say the number
must be rounded to 3 decimal places.  The question becomes how to
round the raw data?

There is an ASTM rounding procedure that is often specified in the
law, I forget the ASTM number but one could google for it.  I was
always taught that when the right-most digit is 5 or greater round up,
4 or less round down.  This is the way your pocket calculator and
Excel spreadsheet will do it as well.  *But*, that will introduce an
upward bias, given normally distributed data (usually a safe
assumption).  Since a 5, 6, 7, 8, or 9 will cause a round up, and a 4,
3, 2, or 1 will round down, then there will be a bias towards rounding
up (5 digits round up, but only 4 digits round down).  What is needed
is a way to evenly split the rounding when the last digit is a 5.

The ASTM procedure specifies that the next-least-significant digit be
inspected, in this case the 3rd digit to the right of the decimal.  If
it is even (0,2,4 etc) then round down to the even digit.  This is
*not* how your calculator does it.  If it is odd (1,3,5 etc) then
round up.  This *is* how your calculator does it.

Example:

0.12850  rounds to  0.128  ( not 0.129 )
0.12851  rounds to  0.129

0.12350  rounds to  0.124
0.12349  rounds to  0.123

Hope this wasn't too far off topic and of some interest related to the
general topic of rounding.  My explanation is not the best, but you
should get the idea.

-Doug

Doug Hoffman wrote:
> On Nov 30, 4:06 pm, Jonah Thomas <jethom...@gmail.com> wrote:
> 
> ...
> 
>> Then you do M*/ and
>> something like a remainder is left in the low word. Use that to round
>> and you're done.
> 
> This is off topic but perhaps related.  The general issue being how to
> round off data such that a bias is not introduced.
> 
> I run into this when there is a legal "pass/fail" decision to be made
> on the performance of a product.
> 
> Consider the case when we have decided that the output from our
> measuring instrument is accurate to a certain number of digits.  For
> discussion let's say that is 5 decimal digits to the right of the
> decimal point.  The raw data is then rounded to the legal number of
> places and compared to the pass/fail standard.  Let's say the number
> must be rounded to 3 decimal places.  The question becomes how to
> round the raw data?
> 
> There is an ASTM rounding procedure that is often specified in the
> law, I forget the ASTM number but one could google for it.  I was
> always taught that when the right-most digit is 5 or greater round up,
> 4 or less round down.  This is the way your pocket calculator and
> Excel spreadsheet will do it as well.  *But*, that will introduce an
> upward bias, given normally distributed data (usually a safe
> assumption).  Since a 5, 6, 7, 8, or 9 will cause a round up, and a 4,
> 3, 2, or 1 will round down, then there will be a bias towards rounding
> up (5 digits round up, but only 4 digits round down).  What is needed
> is a way to evenly split the rounding when the last digit is a 5.
> 
> The ASTM procedure specifies that the next-least-significant digit be
> inspected, in this case the 3rd digit to the right of the decimal.  If
> it is even (0,2,4 etc) then round down to the even digit.  This is
> *not* how your calculator does it.  If it is odd (1,3,5 etc) then
> round up.  This *is* how your calculator does it.
> 
> Example:
> 
> 0.12850  rounds to  0.128  ( not 0.129 )
> 0.12851  rounds to  0.129
> 
> 0.12350  rounds to  0.124
> 0.12349  rounds to  0.123
> 
> Hope this wasn't too far off topic and of some interest related to the
> general topic of rounding.  My explanation is not the best, but you
> should get the idea.

Another common method is rounding .wx5y to the nearest even number. If x 
is odd, round up. If it is even, round down. That's also free of bias.

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

Doug Hoffman <glidedog@gmail.com> wrote:

> This is off topic but perhaps related.  The general issue being how to
> round off data such that a bias is not introduced.
> 
> I run into this when there is a legal "pass/fail" decision to be made
> on the performance of a product.
> 
> Consider the case when we have decided that the output from our
> measuring instrument is accurate to a certain number of digits.  For
> discussion let's say that is 5 decimal digits to the right of the
> decimal point.  The raw data is then rounded to the legal number of
> places and compared to the pass/fail standard.  Let's say the number
> must be rounded to 3 decimal places.  The question becomes how to
> round the raw data?
> 
> There is an ASTM rounding procedure that is often specified in the
> law, I forget the ASTM number but one could google for it.  I was
> always taught that when the right-most digit is 5 or greater round up,
> 4 or less round down.  This is the way your pocket calculator and
> Excel spreadsheet will do it as well.  *But*, that will introduce an
> upward bias, given normally distributed data (usually a safe
> assumption).  Since a 5, 6, 7, 8, or 9 will cause a round up, and a 4,
> 3, 2, or 1 will round down, then there will be a bias towards rounding
> up (5 digits round up, but only 4 digits round down).  

I'm sure I've taken classes on this topic and I don't remember anything.
But common sense says this is wrong.

5 6 7 8 9 cause a round up.
0 1 2 3 4 cause a round down.

How is this unbalanced?

> What is needed
> is a way to evenly split the rounding when the last digit is a 5.
> 
> The ASTM procedure specifies that the next-least-significant digit be
> inspected, in this case the 3rd digit to the right of the decimal.  If
> it is even (0,2,4 etc) then round down to the even digit.  This is
> *not* how your calculator does it.  If it is odd (1,3,5 etc) then
> round up.  This *is* how your calculator does it.
> 
> Example:
> 
> 0.12850  rounds to  0.128  ( not 0.129 )
> 0.12851  rounds to  0.129
> 
> 0.12350  rounds to  0.124
> 0.12349  rounds to  0.123
> 
> Hope this wasn't too far off topic and of some interest related to the
> general topic of rounding.  My explanation is not the best, but you
> should get the idea.

So 49 always rounds down and 51 always rounds up. 50 is set to round
down for odd numbers and round up for even numbers. that will affect 1%
of the cases. If the regular rounding was off by 1% because 50 did the
wrong thing half the time, then this would change the result one time in
200 to undo that error. Does this seem plausible?

What seems more plausible to me is for rounding just the last digit. If
it's true that 1 2 3 4 doesn't balance 5 6 7 8 9 then you have an error
of 1/10 which can be corrected by  having 5 round down half the time,
when there is no less-significant digit available to help you decide. 

And could we figure it that way? If we figure that when the last digit
is 0 then we aren't rounding at all but the digit is correct, that giges
us nine cases where we do round. Similarly, when the last two digits are
rounded and they come out 00 then we aren't rounding at all because the
result is correct, leaving us with 99 cases where we do round. I can
sort of imagine the reasoning. But does it seem plausible to you?

Jonah Thomas wrote:

   ...

> I'm sure I've taken classes on this topic and I don't remember anything.
> But common sense says this is wrong.
> 
> 5 6 7 8 9 cause a round up.
> 0 1 2 3 4 cause a round down.
> 
> How is this unbalanced?

Because rounding 0 to zero is no change. Four non-zero digits round 
down, while five round up. The explanation left something to be desired.

5 6 7 8 9 round up.
1 2 3 4 round down.
0 remains unchanged.

   ...

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

Jerry Avins <jya@ieee.org> wrote:
> Jonah Thomas wrote:
> 
>    ...
> 
> > I'm sure I've taken classes on this topic and I don't remember
> > anything. But common sense says this is wrong.
> > 
> > 5 6 7 8 9 cause a round up.
> > 0 1 2 3 4 cause a round down.
> > 
> > How is this unbalanced?
> 
> Because rounding 0 to zero is no change. Four non-zero digits round 
> down, while five round up. The explanation left something to be
> desired.
> 
> 5 6 7 8 9 round up.
> 1 2 3 4 round down.
> 0 remains unchanged.

Agreed, this explanation leaves something to be desired.

If the range  [0..1) rounds to zero, how is that no change?

Meanwhile the range [1..5) also rounds down, while the range [5..0)
rounds up.

[5..0) looks just about the size of (0..5) to me, and it's only [0..0]
that's unchanged.


If I was going to worry about this bias, I'd probably be more concerned
about Benford's Law.

http://www.ams.org/featurecolumn/archive/newcomb.html

What's going on with that is that very often -- more often than you'd
think -- numbers arrive in a logarithmic distribution, and that leaves
you with a logarithmic distribution for the first digit. But if it's a
logarithmic distribution, digits beyond the first will also be affected.

Jonah Thomas wrote:
> Jerry Avins <jya@ieee.org> wrote:
>> Jonah Thomas wrote:
>>
>>    ...
>>
>>> I'm sure I've taken classes on this topic and I don't remember
>>> anything. But common sense says this is wrong.
>>>
>>> 5 6 7 8 9 cause a round up.
>>> 0 1 2 3 4 cause a round down.
>>>
>>> How is this unbalanced?
>> Because rounding 0 to zero is no change. Four non-zero digits round 
>> down, while five round up. The explanation left something to be
>> desired.
>>
>> 5 6 7 8 9 round up.
>> 1 2 3 4 round down.
>> 0 remains unchanged.
> 
> Agreed, this explanation leaves something to be desired.
> 
> If the range  [0..1) rounds to zero, how is that no change?
> 
> Meanwhile the range [1..5) also rounds down, while the range [5..0)
> rounds up.
> 
> [5..0) looks just about the size of (0..5) to me, and it's only [0..0]
> that's unchanged.


You are looking at ranges, not digits. Even with ranges, you need to 
understand the difference between open and closed intervals. The biggest 
bias occurs when rounding off one digit. With "calculator" rounding, it 
is so:

0 no change
1 down
2 down
3 down
4 down
5 up
6 up
7 up
8 up
9 up.

That's 5 up, 4 down, a bias of 1/9.

> If I was going to worry about this bias, I'd probably be more concerned
> about Benford's Law.
> 
> http://www.ams.org/featurecolumn/archive/newcomb.html
> 
> What's going on with that is that very often -- more often than you'd
> think -- numbers arrive in a logarithmic distribution, and that leaves
> you with a logarithmic distribution for the first digit. But if it's a
> logarithmic distribution, digits beyond the first will also be affected.

I don't see that Benford's Law is re;lated to bias in rounding.

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

Jerry Avins <jya@ieee.org> wrote:
> Jonah Thomas wrote:
> > Jerry Avins <jya@ieee.org> wrote:
> >> Jonah Thomas wrote:

> >>> 5 6 7 8 9 cause a round up.
> >>> 0 1 2 3 4 cause a round down.
> >>>
> >>> How is this unbalanced?
> >> Because rounding 0 to zero is no change. Four non-zero digits round
> >
> >> down, while five round up. The explanation left something to be
> >> desired.
> >>
> >> 5 6 7 8 9 round up.
> >> 1 2 3 4 round down.
> >> 0 remains unchanged.
> > 
> > Agreed, this explanation leaves something to be desired.
> > 
> > If the range  [0..1) rounds to zero, how is that no change?
> > 
> > Meanwhile the range [1..5) also rounds down, while the range [5..0)
> > rounds up.
> > 
> > [5..0) looks just about the size of (0..5) to me, and it's only
> > [0..0] that's unchanged.
> 
> You are looking at ranges, not digits. 

And isn't that appropriate?

> Even with ranges, you need to 
> understand the difference between open and closed intervals. 

If you add one point to an open interval the measure is the same.

> The biggest 
> bias occurs when rounding off one digit. With "calculator" rounding,
> it is so:
> 
> 0 no change
> 1 down
> 2 down
> 3 down
> 4 down
> 5 up
> 6 up
> 7 up
> 8 up
> 9 up.
> 
> That's 5 up, 4 down, a bias of 1/9.

Mmmm. The values in that digit will on average go up a little compared
to the values in that digit before rounding. The question is whether
that is inappropriate. 

It's testable. Start with a uniform random number generator. Generate
uniform numbers and take just the top 7 bits. If the number is outside
the range [0..100] discard it. So the expected mean of a large sample
from this distribution is 50 . 

Take a large sample and see what the mean is. Then round each item to
the nearest 10. 

[0..4] go to 0.
[5..14] go to 10.
.....
[85..94] go to 90.
[95..100] to go 100.

The expected mean of a large sample from the rounded distribution is 50
+ 50/101 . Almost 1% high. 

Rounding the other way we get

[0..5] go to 0.            6 items
[6..14] go to 10.          9 items
[15..25] go to 20.        11 items
[26..34] go to 30.         9 items
[35..45] go to 40.        11 items
[46..54] go to 50.         9 items
[55..65] go to 60.        11 items
[66..74] go to 70.         9 items
[75..85] go to 80.        11 items
[86..94] go to 90.         9 items
[95..100] go to 100.       6 items

Complete symmetry around 50, the expected mean will be 50 as it should
be.

You were right. I was wrong.

> > If I was going to worry about this bias, I'd probably be more
> > concerned about Benford's Law.
> > 
> > http://www.ams.org/featurecolumn/archive/newcomb.html
> > 
> > What's going on with that is that very often -- more often than
> > you'd think -- numbers arrive in a logarithmic distribution, and
> > that leaves you with a logarithmic distribution for the first digit.
> > But if it's a logarithmic distribution, digits beyond the first will
> > also be affected.
> 
> I don't see that Benford's Law is related to bias in rounding.
 
It might not be. If you look at the first digits of a sample that fits
Benford's Law, they will fit a logarithmic distribution. The first digit
is special because it cannot be zero. Could that same logarithmic
distribution give you a bias in the third digit when the first two
digits are the same? (Easier to see if you look only at 1..9 at that
digit.) Could it be a bigger bias than you get from calculator-rounding?
If so, it would still only apply to samples that fit Benford's Law.

Jonah Thomas wrote:
> Jerry Avins <jya@ieee.org> wrote:
>> Jonah Thomas wrote:
>>> Jerry Avins <jya@ieee.org> wrote:
>>>> Jonah Thomas wrote:
> 
>>>>> 5 6 7 8 9 cause a round up.
>>>>> 0 1 2 3 4 cause a round down.
>>>>>
>>>>> How is this unbalanced?
>>>> Because rounding 0 to zero is no change. Four non-zero digits round
>>>> down, while five round up. The explanation left something to be
>>>> desired.
>>>>
>>>> 5 6 7 8 9 round up.
>>>> 1 2 3 4 round down.
>>>> 0 remains unchanged.
>>> Agreed, this explanation leaves something to be desired.
>>>
>>> If the range  [0..1) rounds to zero, how is that no change?
>>>
>>> Meanwhile the range [1..5) also rounds down, while the range [5..0)
>>> rounds up.
>>>
>>> [5..0) looks just about the size of (0..5) to me, and it's only
>>> [0..0] that's unchanged.
>> You are looking at ranges, not digits. 
> 
> And isn't that appropriate?
> 
>> Even with ranges, you need to 
>> understand the difference between open and closed intervals. 
> 
> If you add one point to an open interval the measure is the same.
> 
>> The biggest 
>> bias occurs when rounding off one digit. With "calculator" rounding,
>> it is so:
>>
>> 0 no change
>> 1 down
>> 2 down
>> 3 down
>> 4 down
>> 5 up
>> 6 up
>> 7 up
>> 8 up
>> 9 up.
>>
>> That's 5 up, 4 down, a bias of 1/9.
> 
> Mmmm. The values in that digit will on average go up a little compared
> to the values in that digit before rounding. The question is whether
> that is inappropriate. 
> 
> It's testable. Start with a uniform random number generator. Generate
> uniform numbers and take just the top 7 bits. If the number is outside
> the range [0..100] discard it. So the expected mean of a large sample
> from this distribution is 50 . 
> 
> Take a large sample and see what the mean is. Then round each item to
> the nearest 10. 
> 
> [0..4] go to 0.
> [5..14] go to 10.
> ....
> [85..94] go to 90.
> [95..100] to go 100.
> 
> The expected mean of a large sample from the rounded distribution is 50
> + 50/101 . Almost 1% high. 
> 
> Rounding the other way we get
> 
> [0..5] go to 0.            6 items
> [6..14] go to 10.          9 items
> [15..25] go to 20.        11 items
> [26..34] go to 30.         9 items
> [35..45] go to 40.        11 items
> [46..54] go to 50.         9 items
> [55..65] go to 60.        11 items
> [66..74] go to 70.         9 items
> [75..85] go to 80.        11 items
> [86..94] go to 90.         9 items
> [95..100] go to 100.       6 items
> 
> Complete symmetry around 50, the expected mean will be 50 as it should
> be.

The bias is not nearly as great as that found in sub-dollar sakes-tax 
tables. :-(

   ...

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

On Nov 30, 7:18=A0pm, Jerry Avins <j...@ieee.org> wrote:

....

> Because rounding 0 to zero is no change. Four non-zero digits round
> down, while five round up. The explanation left something to be desired.
>
> 5 6 7 8 9 round up.
> 1 2 3 4 round down.
> 0 remains unchanged.

You are right.  I guess I'm too close to it to be able to explain it
well.  Thanks for filling in the gaps.

-Doug

p.s. Writing an Excel formula to handle this is an extreme pain.
Using Forth it is pretty simple.

In article <eJadnXDNFYeCjYnWnZ2dnUVZ_vmdnZ2d@supernews.com>,
Elizabeth D Rather  <erather@forth.com> wrote:
>Anton Ertl wrote:
>> Elizabeth D Rather <erather@forth.com> writes:
>...
>>> If you need more precision than */ provides (single-length arguments,
>>> double-length intermediate product), why not just use M*/ (double
>>> multiplied by ratio of singles, triple-precision intermediate product)?
>>>  That's what most people do, and why there hasn't been any demand for a
>>> rounding */.
>>
>> If I understand you correctly, you suggest changing the scale factor
>> for the fixed-point arithmetic, so the systematic error of the
>> flooring/truncating in */ is reduced; and this scale factor requires
>> representing the fixed-point numbers as doubles instead of as singles.
>>
>> I don't think this is the best answer to the problem, because:
>>
>> 1) There will still be a bias, even though it will be smaller after
>> scaling.
>>
>> 2) The performance of this approach will be worse.  Not only is M*/
>> much slower than */R (2.5 times for Gforth on a Core 2 Duo E8400):
>>
>> */r     2844 ms
>> m*/     7248 ms
>>
>> you also have the overhead of doubles instead of singles for the
>> fixed-point numbers everywhere, or at least of converting to and from the
>> double-based fixed-point representation around M*/.
>>
>> There may be good reasons for using a scale factor that requires
>> doubles, but avoiding */R is not one of them.
>
>I thought the whole point was to find good approximations for continuing
>fractions.  Surely that isn't something you do in real-time (more like
>getting the ratio you need on a one-time basis)?  Why would performance
>be an issue?

That is related to another point that makes this whole subject a but
silly.
If you want a continued fraction for pi, you have to base it on
something. Probably that is a good decimal approximation that you
have to look up, but then you might as well look up a continued
fraction directly.

>
>Cheers,
>Elizabeth

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

In article <4VPQm.34975$cd7.19549@newsfe04.iad>,
Josh Grams  <josh@qualdan.com> wrote:
>Tinkerer Atlarge wrote: <1j9zm4j.qzwbt6zit6moN%tinkerer@optusnet.com.au>
>> The secret might be to forget about constructs and consider the action
>> of WHILE and REPEAT as entities in their own right which only need
>> BEGIN as an end-marker for their own purposes. But that is just me
>> thinking aloud. I don't claim to know yet.
>
>You could do that.  It's probably better to start by just using the
>basic three constructions, but I do somewhat think of them as individual
>pieces.
>
>My understanding goes something like this:
>
>Forth has an unconditional branch and a branch-if-false.  It also
>differentiates between forward and backward branches.  So we have six
>basic words to compile these branches, and three convenience words which
>combine the basic operations.  These words use a stack at compile-time:

In ciforth I have made this layer explicit.
So there is : BRANCH 0BRANCH (FORWARD FORWARD) (BACK BACK)

Then the compiling words add the security warning mechanism,
I have commented it out in the following:

: IF POSTPONE 0BRANCH  (FORWARD  ( 2 ) ; IMMEDIATE
: THEN ( 2 ?PAIRS ) FORWARD) ; IMMEDIATE

FORWARD) patches up the jump offset at the address left by (FORWARD
Similarly BACK) stores an offset to the address left by (BACK

Despite Chuck Moore's warning not to layer software, I find this
helpful.

<Nice explicit overview deleted>

>
>--Josh


--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Anton Ertl wrote:
> There may be good reasons for using a scale factor that requires
> doubles, but avoiding */R is not one of them.

Suggestion for a */R which preserves the full input range:

: */r dup >r */mod swap r> 2/ > - ;

This should not be much slower than

: */r' swap 2* swap */ 1+ 2/ ;

but note that both depend on floored division.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/