continued fractions
Hugh Aguilar
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?
Albert van der Horst
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
Hugh Aguilar
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.
Coos Haak
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
Hugh Aguilar
> > 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/ :-)
Coos Haak
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.
Hugh Aguilar
> 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.
Albert van der Horst
Hugh Aguilar <hugoa...@rosycrew.com> wrote:
>On Nov 17, 6:54=A0am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
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.
Hugh Aguilar
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
Andrew Haley
> 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.
P.M.Lawrence
> 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.
Brad
> 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
Albert van der Horst
Hugh Aguilar <hugoa...@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>
Albert van der Horst
Hugh Aguilar <hugoa...@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?
Hugh Aguilar
> 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
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.
Hugh Aguilar
wrote:
I don't have Knuth's books --- can you describe the algorithm?
Andrew Haley
> 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.
> >
> 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.
Thomas Pornin
> 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
Albert van der Horst
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.
P.M.Lawrence
Hugh Aguilar wrote:
> On Nov 18, 6:03 am, "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) = 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.
Hugh Aguilar
> > > x(n+1) = 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.
P.M.Lawrence
> On Nov 19, 9:11 am, "P.M.Lawrence" <pml540...@gmail.com> wrote:
> > > > x(n+1) = 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.
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.
Elizabeth D Rather
...
> 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."
==================================================
Albert van der Horst
Hugh Aguilar <hugoa...@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.
idknow
> On Nov 17, 6:56 pm, Coos Haak <chfo...@hccnet.nl> wrote:
>
> 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.
Andrew Haley
> 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.
Bernd Paysan
> 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
> 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"
Marcel Hendrix
> Andrew Haley wrote:
>>> 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).
The problem is not in saving it to an executable, the problem is in what
users expect when they start that thing. Will open files be open, dynamically
linked code still be executable, allocated memory still be allocated, transient
information (like input buffers and window handles) still be available?
iForth has gotten lots of DWIMmy link chains lately, but I'm not completely
comfortable with them yet. Has it ever been discussed how a "Forth executable"
should behave?
-marcel
Coos Haak
I didn't write anything of the above. Please quote properly.
Elizabeth D Rather
...
> 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.
Marcel Hendrix
[..]
> Algo D is available in Forth, i.a. via the link below.
> 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.
I vastly prefer the below Forth code over MIX or assembler!
Of course it is not understandable as such, but even Knuth does
not provide MIX code without extensive pre- and post comments.
For the Forth version you would need Knuth's book at your side
for in-depth explanation. In the next iteration of technology we
can do this by embedding freely available on-line bibliographic
references for anything, something I have wanted to for my
programming since at least 1985.
-marcel
-- Algorithm D, words MUL&SUB and ADDBACK not shown ----------------------------
-- warning: linewidth 80 -------------------------------------------------------
MAX.DIGITS BIGNUM U
MAX.DIGITS BIGNUM V
: (VV/MOD) TO V TO U \ ( Um+n Vn -- )
0 LOCAL qhat 0 LOCAL rhat /OF V LOCAL n
/OF U n - 1+ LOCAL m+1
CLEAR QQ QQ m+1 Vextend
V VNORMALIZE LOCAL exp \ normalize V
0 HEAD V LOCAL V1 1 HEAD V LOCAL V2 \ highest digits of V
( D1. ) U /OF U 1+ Vextend U exp V<< \ normalize U
( D2. ) m+1 0 ?DO
( D3. ) I HEAD U V1 =
IF -1 TO qhat
ELSE I 1+ HEAD U I HEAD U V1 UM/MOD TO qhat TO rhat
ENDIF
BEGIN I 2+ HEAD U rhat \ remainder*b + Uj+2
V2 qhat UM*
DU<
WHILE -1 +TO qhat
V1 rhat U+cy SWAP TO rhat
UNTIL ( overflow) THEN
( D4. ) I '[] HEAD U 0 '[] HEAD V n qhat MUL&SUB ( borrow)
( D5. ) qhat TO I HEAD QQ
( D6. ) IF -1 +TO I HEAD QQ
I '[] HEAD U 0 '[] HEAD V n ADDBACK
ENDIF
( D7. ) LOOP
( D8. ) U TO RR n TO #DIGITS RR \ lower n digs of Un+m
RR exp VUNNORMALIZE
QQ REPACK RR REPACK ;
Uwe Kloß
> 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
Jonah Thomas
> 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
> > 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?
> 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.
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?
Anton Ertl
>The problem is not in saving it to an executable, the problem is in what
>users expect when they start that thing. Will open files be open, dynamically
>linked code still be executable, allocated memory still be allocated, transient
>information (like input buffers and window handles) still be available?
>Has it ever been discussed how a "Forth executable"
>should behave?
There have been some discussions about whether ALLOTed and/or
ALLOCATEd memory should be preserved; a number of people think that
ALLOTed memory should be preserved, but ALLOCATEd memory should not.
They did not give a reason for this position that convinced me, but I
think that a number of systems do image or executable generation this
way (including Gforth).
- 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
>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.
Uwe Kloß
> 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.
Hugh Aguilar
> 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.
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.
Coos Haak
<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
Hugh Aguilar
> 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.
Elizabeth D Rather
> 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.
Elizabeth D Rather
> 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.
Uwe Kloß
> 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
Elizabeth D Rather
What is the actual footprint of a typical Forth vs. other scripting
languages?
Uwe Kloß
> 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?
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
Anton Ertl
>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:-(.
Wayne
> 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)
Ian Osgood
wrote:
>
> 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
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
Elizabeth D Rather
> Elizabeth D Rather <era...@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.
Marcel Hendrix
[..]
> One of the factors I kept reinventing for text processing tasks was
> the SPLIT word (either by character, string, or "match" predicate).
Interesting. Lately I also need this word (IIRC invented by Wil Baden)
very frequently. I call it Split-At-Char. Split-At-Word and Split-At-WS
(white space) are occasionally useful. Together with string concatenation
( $+ ), /PARSE, <WORD>, PLACE, PLACE+, CHAR-APPEND CHAR-PREPEND, -TRAILING
-LEADING, SEARCH, COMPARE, COMPARE-NC, and /STRING they leave not much
to be desired. I hardly ever use SKIP and SCAN. It is very handy when your
Forth has string output primitives for its number formatting ( 998 (.)
TYPE etc. ), and when KEY, EMIT etc. can be redirected to file easily.
-marcel
Josh Grams
> 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
Hugh Aguilar
> 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.
John Passaniti
> 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.
Elizabeth D Rather
>> 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.
Hugh Aguilar
> So what would a Forth-based scripting language look like?
It would look like Factor.
I think Forth needs to focus on micro-controller code. Leave scripting
to Factor.
> 1. The Forth dictionary is scrapped for an associative array. This
> 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. 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.
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. 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:
This has been in Forth since the 1970s. Lua doesn't have anything on
Forth in this regard.
> 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
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?
Jerry Avins
...
> 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.
�����������������������������������������������������������������������
Elizabeth D Rather
...
> 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.
John Passaniti
> 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.
Jonah Thomas
> > 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.
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.
> 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.
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.
Anton Ertl
>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*
Stephen Pelc
<hugoa...@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, steph...@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
Bernd Paysan
> 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/
MarkWills
: ASSHOLE? ANTI-GAY? IF GO-AWAY THEN ;
Jonah Thomas
> 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.
Anton Ertl
>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.
Hugh Aguilar
> 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.
Hugh Aguilar
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. 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.
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?
Elizabeth D Rather
...
> 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.
Hugh Aguilar
> 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.
Hugh Aguilar
> 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.
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.
Jonah Thomas
Hugh Aguilar <hugoa...@rosycrew.com> wrote:
> On Nov 23, 7:39 am, 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 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.
> 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.
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.
> 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).
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.
Hugh Aguilar
> ... 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.
Stephen Pelc
<hugoa...@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.
Elizabeth D Rather
> 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 D Rather
> 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.
Bernd Paysan
>>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.
Marcel Hendrix
> 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
[..]
> 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.
That second approximation was done especially for the SF Web release,
on a 32-bit Forth, using Greg Bailey's CF wordset (published on CLF,
long ago:
From: g...@med3.minerva.com
Subject: Rational Approximations
Date: 21 Apr 1993 04:44:23 -0500
Organization: UTexas Mail-to-News Gateway
Lines: 152
NNTP-Posting-Host: cs.utexas.edu
... ).
[..]
-marcel
Elizabeth D Rather
> Elizabeth D Rather <era...@forth.com> writes Re: continued fractions
>
>> From Starting Forth:
>
>> Handy Table of Rational Approximations to Various Constants
>
>> Number Approximation Error
>
>
>> pi = 3.141 ... 1068966896 / 340262731 3.0 x 10-18
> [..]
>> 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.
>
> That second approximation was done especially for the SF Web release,
> on a 32-bit Forth, using Greg Bailey's CF wordset (published on CLF,
> long ago:
> From: g...@med3.minerva.com
> Subject: Rational Approximations
> Date: 21 Apr 1993 04:44:23 -0500
> Organization: UTexas Mail-to-News Gateway
> Lines: 152
> NNTP-Posting-Host: cs.utexas.edu
> ... ).
>
Thanks, Marcel. Greg may still have that code somewhere. He might be
reachable at gr...@GreenArrayChips.com
Hugh Aguilar
> Elizabeth D Rather <erat...@forth.com> writes Re: continued fractions
> > 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
> on a 32-bit Forth, using Greg Bailey's CF wordset (published on CLF,
> long ago:
It seems very unlikely that the second rational could have been done
on a 16-bit computer, considering that the numbers are 32-bit, whereas
Forth in Brodie's day was 16-bit. I use 355/113 on five-function
pocket calculators that don't have a PI constant; it is easy to
memorize. Grossman's article provides us with the 16-bit rational:
52174/33215. Using this rational involves the introduction of the word
U*/, but that is trivial to implement given that we already have UM*
and UM/MOD.
What about rationals that aren't in Brodie's list? Is the programmer
supposed to tell his boss: "I can't complete this program until we
locate Leo Brodie and convince him to update his list of rationals to
include the one that I need." Convincing Mr. Brodie to do this might
be difficult, as he seems to be pursuing other interests nowadays:
http://punchandbrodie.com/leo/puppets.html
Hugh Aguilar
> On Mon, 23 Nov 2009 09:54:35 -0800 (PST), 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.
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?"). 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.
> 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.
Elizabeth D Rather
>> 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.
Jonah Thomas
> 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?"). 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.
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.
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.
John Passaniti
> 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. The language would use a typed stack. [...]
>
> 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. 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:
>
> 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.
John Passaniti
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. Looks 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.
John Passaniti
> 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.
John Passaniti
> 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.
John Passaniti
> 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?
MarkWills
Personally, I'm on the edge of my seat! You'll be telling us you
washed the dishes next!
I can't stand it ;-)
MarkWills
Personally, I'm on the edge of my seat! You'll be telling us you
Wayne
wrote:
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/
Wayne
<john.pa...@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.
Marc Olschok
The programmer is supposed to lookup
<http://en.wikipedia.org/wiki/Stern%E2%80%93Brocot_tree>
by himself.
--
Marc
Anton Ertl
>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.
>>
>
>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/
Marc Olschok
> 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
John Passaniti
wrote:
> > 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.
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. But
> 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.
Hugh Aguilar
> 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.
Elizabeth D Rather
> 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.
Hugh Aguilar
> 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.
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?
Elizabeth D Rather
...
> 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,
Anti Vigilante
> they always want to fight other people's battles for them, and they
> 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.
Er, no.
> The minority people
Where do they live? Minority city?
> 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.
Translation: If you need help you are incapable. Sounds to me like
you're the one with associative biases.
> In my estimation,
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.
> "you would be a field laborer, because that is the only work you are
> qualified to do."
No dumbass. It's "because that is the only
BEGIN INSERTION -
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
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?
>
> 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.
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.