Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #49233 > unrolled thread

Re: Jazelle?

Back to article view | Back to comp.lang.forth

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Jazelle? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-20 10:31 +0100
    Re: Jazelle? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-20 10:14 +0000
      Re: Jazelle? Chris Curl <ccurl609@gmail.com> - 2016-07-20 05:37 -0700
        Re: Jazelle? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-20 13:36 +0000
      Re: Jazelle? "WJ" <w_a_x_man@yahoo.com> - 2016-07-20 13:06 +0000
      Re: Jazelle? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-20 14:49 +0100
        Re: Jazelle? hughaguilar96@gmail.com - 2016-07-20 08:48 -0700
        Re: Jazelle? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-20 14:35 +0000
          Re: Jazelle? mm0fmf <none@invalid.com> - 2016-07-20 17:39 +0100
          Re: Jazelle? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-20 20:30 +0100
            Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 15:35 -0400
              Re: Jazelle? mhx@iae.nl - 2016-07-20 13:27 -0700
                Re: Jazelle? "WJ" <w_a_x_man@yahoo.com> - 2016-07-21 09:41 +0000
              Re: Jazelle? hughaguilar96@gmail.com - 2016-07-21 17:24 -0700
          Re: Jazelle? "WJ" <w_a_x_man@yahoo.com> - 2016-07-21 10:43 +0000
            Re: Jazelle? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-21 12:44 +0000
              Re: Jazelle? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-21 22:59 +0100
                Re: Jazelle? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-22 06:42 +0000
                  Re: Jazelle? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-22 12:03 +0100
                    Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-22 09:05 -0400
                      Re: Jazelle? Cecil Bayona <cbayona@cbayona.com> - 2016-07-22 10:09 -0500
                      Re: Jazelle? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2016-07-22 19:20 +0300
                    Re: Jazelle? Brad Eckert <hwfwguy@gmail.com> - 2016-07-22 09:35 -0700
            Re: Jazelle? "WJ" <w_a_x_man@yahoo.com> - 2016-07-25 10:43 +0000
              Re: Jazelle? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-26 11:41 +0100
                Re: Jazelle? Julian Fondren <julian.fondren@gmail.com> - 2016-07-26 04:26 -0700
                  Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-26 11:20 -0400
    Re: Jazelle? Doug Hoffman <glidedog@gmail.com> - 2016-07-20 06:44 -0400
      Re: Jazelle? "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> - 2016-07-20 14:52 +0100
        Re: Jazelle? "WJ" <w_a_x_man@yahoo.com> - 2016-07-20 14:33 +0000
        Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 10:52 -0400
          Re: Jazelle? alister <alister.ware@ntlworld.com> - 2016-07-20 15:40 +0000
            Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 11:46 -0400
            Re: Jazelle? hughaguilar96@gmail.com - 2016-07-20 09:25 -0700
      Re: Jazelle? hughaguilar96@gmail.com - 2016-07-20 09:22 -0700
        Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 13:14 -0400
          Re: Jazelle? hughaguilar96@gmail.com - 2016-07-20 21:44 -0700
            Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-21 01:32 -0400
              Re: Jazelle? Cecil Bayona <cbayona@cbayona.com> - 2016-07-21 02:21 -0500
            Re: Jazelle? Brad Eckert <hwfwguy@gmail.com> - 2016-07-21 17:13 -0700
              Re: Jazelle? hughaguilar96@gmail.com - 2016-07-21 17:42 -0700
              Re: Jazelle? humptydumpty <ouatubi@gmail.com> - 2016-07-23 10:08 -0700
                Re: Jazelle? hughaguilar96@gmail.com - 2016-07-23 13:55 -0700
                  Re: Jazelle? humptydumpty <ouatubi@gmail.com> - 2016-07-24 02:22 -0700
    Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 10:56 -0400
    Re: Jazelle? Brad Eckert <hwfwguy@gmail.com> - 2016-07-20 10:54 -0700
      Re: Jazelle? Cecil Bayona <cbayona@cbayona.com> - 2016-07-20 13:33 -0500
        Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 16:51 -0400
          Re: Jazelle? Cecil Bayona <cbayona@cbayona.com> - 2016-07-20 17:09 -0500
            Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 18:12 -0400
              Re: Jazelle? Cecil Bayona <cbayona@cbayona.com> - 2016-07-20 18:41 -0500
                Re: Jazelle? rickman <gnuarm@gmail.com> - 2016-07-20 21:01 -0400

Page 1 of 3  [1] 2 3  Next page →

#49233 — Re: Jazelle?

"Paul" <paul@pcserviceselectronics.co.uk> wrote in message 
news:MPG.31f93e8b429c8383989804@172.16.0.1...
> In article <nmn4gf$p1o$2@news.albasani.net>, tnp@invalid.invalid says...
>> On 20/07/16 01:25, rickman wrote:
>> > On 7/18/2016 5:50 AM, gareth G4SDW GQRP #3339 wrote:
>> >> I wonder if anyone has done any experiments to determine what the
>> >> Jazelle byte codes are, for use of such things should produce code
>> >> that is even more compact than Thumb?
>> >>
>> >> e.g single steppint code and then examining the changes that have
>> >> been wrought by each code, allowing for some extra bytes as
>> >> addresses or immediate data.
>> >
>> > If you want high code density, you should learn Forth.  It can support 
>> > a
>> > complete Forth compiler in as little as 16 kB.
>> >
>> Indeed. More compact than assembler really!

But Forth _IS_ assembler, for it is based on the prior published
art of the KDF9 computer architecture along with its drop, dup, data and 
return stacks.

Interpreting another assembly language must be the height of nuttiness!

Consider the solution of the quadratic equation expressed in
a HLL ...

X = (-B + SQRT ( B**2 - 4*A*C))?2*A

... then consider what you have to do in Forth to achieve the same end.
of pushing variables onto the stack and manipulating that stack to
realise that Forth is, indeed, assembly language!

[toc] | [next] | [standalone]

#49234

"gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> writes:
>Consider the solution of the quadratic equation expressed in
>a HLL ...
>
>X = (-B + SQRT ( B**2 - 4*A*C))?2*A

Which HLL uses "?" as division operator that has lower priority than
"*"; actually, which HLL has a division operator with lower priority
than "*"?

Anyway, this way of computing one of the solutions for a quadratic
equation is bad because it introduces more numerical instability than
is coming from the problem itself.  Read more about how to do it
better in

<http://home.pipeline.com/~hbaker1/sigplannotices/sigcol05.pdf>
<http://home.pipeline.com/~hbaker1/sigplannotices/sigcol06.pdf>

>... then consider what you have to do in Forth to achieve the same end.
>of pushing variables onto the stack and manipulating that stack to
>realise that Forth is, indeed, assembly language!

Yes.  Forth has the benefits of assembly language (stability,
performance) as well as some of the benefits of higher-level languages
(in particular, portability), mitigating the drawbacks of assembly
language (non-portability) and higher-level languages (instability for
C, low performance for, e.g., Python).

- 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 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#49237

On Wednesday, July 20, 2016 at 6:31:49 AM UTC-4, Anton Ertl wrote:
> "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> writes:
> >Consider the solution of the quadratic equation expressed in
> >a HLL ...
> >
> >X = (-B + SQRT ( B**2 - 4*A*C))?2*A
> 
> Which HLL uses "?" as division operator that has lower priority than
> "*"; actually, which HLL has a division operator with lower priority
> than "*"?
> 
> Anyway, this way of computing one of the solutions for a quadratic
> equation is bad because it introduces more numerical instability than
> is coming from the problem itself.  Read more about how to do it
> better in
> 
> <http://home.pipeline.com/~hbaker1/sigplannotices/sigcol05.pdf>
> <http://home.pipeline.com/~hbaker1/sigplannotices/sigcol06.pdf>
> 
> >... then consider what you have to do in Forth to achieve the same end.
> >of pushing variables onto the stack and manipulating that stack to
> >realise that Forth is, indeed, assembly language!
> 
> Yes.  Forth has the benefits of assembly language (stability,
> performance) as well as some of the benefits of higher-level languages
> (in particular, portability), mitigating the drawbacks of assembly
> language (non-portability) and higher-level languages (instability for
> C, low performance for, e.g., Python).
> 
> - anton
I understand what you are saying, but I don't agree about one statement ... C programs can be very stable if you write them correctly.

[toc] | [prev] | [next] | [standalone]

#49239

Chris Curl <ccurl609@gmail.com> writes:
>On Wednesday, July 20, 2016 at 6:31:49 AM UTC-4, Anton Ertl wrote:
>> Yes.  Forth has the benefits of assembly language (stability,
>> performance) as well as some of the benefits of higher-level languages
>> (in particular, portability), mitigating the drawbacks of assembly
>> language (non-portability) and higher-level languages (instability for
>> C, low performance for, e.g., Python).
>> 
>> - anton
>I understand what you are saying, but I don't agree about one statement ... C programs can be very stable if you write them correctly.

That's not falsifiable, and therefore belongs more in the area of
religion than in anything that can be tested scientifically.

Anyway, there are no such "if"s for the assembly language of decent
CPUs (at least not for sequential programs; for concurrent programs
the mindset that is corrupting C is also wide-spread, that's why it's
so unpopular).

- 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 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#49238

Anton Ertl wrote:

> "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> writes:
> > Consider the solution of the quadratic equation expressed in
> > a HLL ...
> > 
> > X = (-B + SQRT ( B**2 - 4*A*C))?2*A
> 
> Which HLL uses "?" as division operator that has lower priority than
> "*"; actually, which HLL has a division operator with lower priority
> than "*"?
> 
> Anyway, this way of computing one of the solutions for a quadratic
> equation is bad because it introduces more numerical instability than
> is coming from the problem itself.  Read more about how to do it
> better in
> 
> <http://home.pipeline.com/~hbaker1/sigplannotices/sigcol05.pdf>
> <http://home.pipeline.com/~hbaker1/sigplannotices/sigcol06.pdf>
> 
> > ... then consider what you have to do in Forth to achieve the same end.
> > of pushing variables onto the stack and manipulating that stack to
> > realise that Forth is, indeed, assembly language!
> 
> Yes.  Forth has the benefits of assembly language (stability,
> performance) as well as some of the benefits of higher-level languages
> (in particular, portability), mitigating the drawbacks of assembly
> language (non-portability) and higher-level languages (instability for
> C, low performance for, e.g., Python).

OCaml has neither the drawback of instability nor of low performance.

Note that he didn't post a solution in Forth.

It would have been too difficult to write the solution,
and, once written, the solution would have been too
difficult to read.

OCaml:

let quad a b c = (sqrt(b *. b -. 4. *. a *. c) -. b) /. (2. *. a) ;;

quad 1. 2. (-8.) ;;
 ===>
2.

quad 3. (-10.) 5. ;;
 ===>
2.7207592200561268



Julia:

quad(a,b,c) = (sqrt(b*b - 4a*c) - b)/2a

quad(1,2,-8)
 ===>
2.0

quad(3,-10,5)
 ===>
2.720759220056127

-- 
Amazon bans book.  After nearly a month on the site, all traces of the book and
its 80 reviews have been removed.
http://jamesfetzer.blogspot.com/2015/11/debunking-sandy-hook-debunkers-5.html
https://www.youtube.com/watch?v=EEl_1HWFRfo

[toc] | [prev] | [next] | [standalone]

#49240

"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message 
news:2016Jul20.121415@mips.complang.tuwien.ac.at...
> "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> writes:
>>Consider the solution of the quadratic equation expressed in
>>a HLL ...
>>
>>X = (-B + SQRT ( B**2 - 4*A*C))?2*A
>
> Which HLL uses "?" as division operator that has lower priority than
> "*"; actually, which HLL has a division operator with lower priority
> than "*"?

A minor typo caused by typing with the shift key held down

And, yes, S/B (2*A) but neither critique answers the HLL versus assembler
criticism.

> Anyway, this way of computing one of the solutions for a quadratic
> equation is bad because it introduces more numerical instability than
> is coming from the problem itself.  Read more about how to do it
> better in

Not relevant to demonsrtating the ease of use and built in syntax checking
of a HLL compared to an assembler.

>>... then consider what you have to do in Forth to achieve the same end.
>>of pushing variables onto the stack and manipulating that stack to
>>realise that Forth is, indeed, assembly language!
>
> Yes.  Forth has the benefits of assembly language (stability,
> performance)

Very little commercial advantage in assembler; in fact just the opposite
as far as productivity and reliabililty and maintainability go.

[toc] | [prev] | [next] | [standalone]

#49250

On Wednesday, July 20, 2016 at 6:49:53 AM UTC-7, gareth G4SDW GQRP #3339 wrote:
> "Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message 
> news:2016Jul20.121415@mips.complang.tuwien.ac.at...
> > Anyway, this way of computing one of the solutions for a quadratic
> > equation is bad because it introduces more numerical instability than
> > is coming from the problem itself.  Read more about how to do it
> > better in
> 
> Not relevant to demonsrtating the ease of use and built in syntax checking
> of a HLL compared to an assembler.

I'm pretty sure that getting the math right is relevant in a math program --- pretty syntax doesn't fix bad math --- or, as the Japanese say: wasabi doesn't fix spoiled fish.

A better example than the quadratic equation might be polynomial evaluation, as done in numeric approximations of transcendental functions --- there is a trick for making that efficient --- this trick comes out nice and clean in Forth, as compared to the infix-arithmetic languages.

Calculating parallel-resistance is a super-simple example. Here is my discussion from my Stundurd document:
-------------------------------------------------------------------------
The manual for ISYS Forth (for the Apple-IIc) gave us this example of good Forth style:

: par  \ r1 r2 -- r                                 \ calculate parallel resistance of two resistors
    ddup +  */ ;

: par3  \ r1 r2 r3 -- r                             \ calculate parallel resistance of three resistors
    par par ;

The high-functioning C'diot may avoid stack-juggling (the DDUP in PAR above) like this:

: par  local{ r1 r2 -- r }                          \ calculate parallel resistance of two resistors
    r1 @  r2 @
    r1 @  r2 @  +  */ ;

: par3  local{ r1 r2 r3 -- r }                      \ calculate parallel resistance of three resistors
    r1 @  r2 @  par
    r3 @  par ;

The low-functioning C'diot will do even worse. For one thing, he may fail to understand */ because he can't translate it into C code --- so he will use * and / instead, resulting in an overflow bug. Or, he may fail to understand */ but will understand that overflow is an issue --- so he will use D* and D/ instead, resulting in abysmally slow code. Also, he may fail to understand that one of the purposes of factoring is so that sub-functions can be reused (PAR was reused in PAR3) because factoring is not considered to be a virtue in the C world. A collision of not understanding */ and not understanding reusability, would result in this:

: par  local{ r1 r2 r3 -- r }                       \ calculate parallel resistance of two resistors (WARNING: overflow is possible!)
    r1 @  r2 @  *
    r1 @  r2 @  +  / ;

: par3  local{ r1 r2 r3 | t1 -- r }                 \ calculate parallel resistance of three resistors (WARNING: overflow is possible!)
    r1 @  r2 @  *
    r1 @  r2 @  +  /  t1 !
    t1 @  r3 @  *
    t1 @  r3 @  +  / ;

The Stundurd code above appears to have been written in C first, and then translated line-by-line into Stundurd; it is pretty much just an rpn-version of C. It is typical for C'diots to have a function such as PAR3 that obviously contains cut-and-paste code from another function (the PAR function just above it). It is also typical for C'diots to comment their bugs (as done above, with the comments warning that overflow is possible). Of course, the true C'diot would put a comment on every line in a vain effort at improving readability --- and then criticize the good-style version of PAR and PAR3 for not being adequately commented!

[toc] | [prev] | [next] | [standalone]

#49252

"gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> writes:
>"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message 
>news:2016Jul20.121415@mips.complang.tuwien.ac.at...
>> "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> writes:
>>>Consider the solution of the quadratic equation expressed in
>>>a HLL ...
>>>
>>>X = (-B + SQRT ( B**2 - 4*A*C))?2*A
>>
>> Which HLL uses "?" as division operator that has lower priority than
>> "*"; actually, which HLL has a division operator with lower priority
>> than "*"?
>
>A minor typo caused by typing with the shift key held down
>
>And, yes, S/B (2*A) but neither critique answers the HLL versus assembler
>criticism.

"S/B (2*A)"?

What "HLL vs. assembler criticism"?

If your example was an attempt to show the superiority of the Fortran
notation over the Forth notation, then the fact that you made two
errors in this one line was not a good testimonial for the Fortran
way.

>> Anyway, this way of computing one of the solutions for a quadratic
>> equation is bad because it introduces more numerical instability than
>> is coming from the problem itself.  Read more about how to do it
>> better in
>
>Not relevant to demonsrtating the ease of use and built in syntax checking
>of a HLL compared to an assembler.

So you want to demonstrate the superiority of the Fortran notation
with an example that no competent Fortran programmer will write in
that way?  And then you parenthesize it incorrectly, a mistake that
will not be detected by "syntax checking".

Interestingly, in <913374461.4045.0.nnrp-04.9e98250c@news.demon.co.uk>
(from 1998) Gareth Alun Evans (any relation to you?) gave pretty much
the same example (in BASIC syntax, though), and made the same
parenthesis omission mistake.  Not a testimonial for the qualities of
infix syntax.

If you write the example in a numerically stable way, you get several
smaller statements rather than a big one, more like most real
programs, and the difference between infix and postfix becomes
smaller.  I guess that's why you choose this example; apparently it's
hard to come up with another huge formula that many people can relate
to.  So even if the Fortran notation would be better for writing down
one solution of a quadratic equation in a numerically unstable way
(and the mistakes of you and Gareth Alun Evans are evidence against
this thesis), that says little about the quality of that notation for
real (and competently written) programs.

Anyway, here's a way to compute the roots (if they are real) without
the numeric instability (you still have bad condition when bb/4 and ac
cancel each other out, so you may want to compute that part with higher
precision).

: compute-q { f: a f: b/2 f: c -- q }
  b/2 b/2 f* a c f* f- fsqrt
  b/2 f0< if fnegate then \ avoids cancelation by the F+ below
  b/2 f+ ;

: quadratic { f: a f: b f: c -- x1 x2 }
  a b f2/ c compute-q { f: q }
  q a f/ c q f/ ;

- 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 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#49257

On 20/07/2016 15:35, Anton Ertl wrote:
> "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> writes:
>> "Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
>> news:2016Jul20.121415@mips.complang.tuwien.ac.at...
>>> "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> writes:
>>>> Consider the solution of the quadratic equation expressed in
>>>> a HLL ...
>>>>
>>>> X = (-B + SQRT ( B**2 - 4*A*C))?2*A
>>>
>>> Which HLL uses "?" as division operator that has lower priority than
>>> "*"; actually, which HLL has a division operator with lower priority
>>> than "*"?
>>
>> A minor typo caused by typing with the shift key held down
>>
>> And, yes, S/B (2*A) but neither critique answers the HLL versus assembler
>> criticism.
>
> "S/B (2*A)"?
>
> What "HLL vs. assembler criticism"?
>
> If your example was an attempt to show the superiority of the Fortran
> notation over the Forth notation, then the fact that you made two
> errors in this one line was not a good testimonial for the Fortran
> way.
>
>>> Anyway, this way of computing one of the solutions for a quadratic
>>> equation is bad because it introduces more numerical instability than
>>> is coming from the problem itself.  Read more about how to do it
>>> better in
>>
>> Not relevant to demonsrtating the ease of use and built in syntax checking
>> of a HLL compared to an assembler.
>
> So you want to demonstrate the superiority of the Fortran notation
> with an example that no competent Fortran programmer will write in
> that way?  And then you parenthesize it incorrectly, a mistake that
> will not be detected by "syntax checking".
>
> Interestingly, in <913374461.4045.0.nnrp-04.9e98250c@news.demon.co.uk>
> (from 1998) Gareth Alun Evans (any relation to you?) gave pretty much
> the same example (in BASIC syntax, though), and made the same
> parenthesis omission mistake.  Not a testimonial for the qualities of
> infix syntax.
>
> If you write the example in a numerically stable way, you get several
> smaller statements rather than a big one, more like most real
> programs, and the difference between infix and postfix becomes
> smaller.  I guess that's why you choose this example; apparently it's
> hard to come up with another huge formula that many people can relate
> to.  So even if the Fortran notation would be better for writing down
> one solution of a quadratic equation in a numerically unstable way
> (and the mistakes of you and Gareth Alun Evans are evidence against
> this thesis), that says little about the quality of that notation for
> real (and competently written) programs.
>
> Anyway, here's a way to compute the roots (if they are real) without
> the numeric instability (you still have bad condition when bb/4 and ac
> cancel each other out, so you may want to compute that part with higher
> precision).
>
> : compute-q { f: a f: b/2 f: c -- q }
>    b/2 b/2 f* a c f* f- fsqrt
>    b/2 f0< if fnegate then \ avoids cancelation by the F+ below
>    b/2 f+ ;
>
> : quadratic { f: a f: b f: c -- x1 x2 }
>    a b f2/ c compute-q { f: q }
>    q a f/ c q f/ ;
>
> - anton
>

Oh dear, you'll be on Gareth's enemy list now.

[toc] | [prev] | [next] | [standalone]

#49261

"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message 
news:2016Jul20.163523@mips.complang.tuwien.ac.at...
> "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> writes:
>>"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
>>news:2016Jul20.121415@mips.complang.tuwien.ac.at...
>>> "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> writes:
>>>>Consider the solution of the quadratic equation expressed in
>>>>a HLL ...
>>>>X = (-B + SQRT ( B**2 - 4*A*C))?2*A
>>> Which HLL uses "?" as division operator that has lower priority than
>>> "*"; actually, which HLL has a division operator with lower priority
>>> than "*"?
>>A minor typo caused by typing with the shift key held down
>>And, yes, S/B (2*A) but neither critique answers the HLL versus assembler
>>criticism.
> "S/B (2*A)"?
> What "HLL vs. assembler criticism"?
> If your example was an attempt to show the superiority of the Fortran
> notation over the Forth notation, then the fact that you made two
> errors in this one line was not a good testimonial for the Fortran
> way.
>>> Anyway, this way of computing one of the solutions for a quadratic
>>> equation is bad because it introduces more numerical instability than
>>> is coming from the problem itself.  Read more about how to do it
>>> better in
>>Not relevant to demonsrtating the ease of use and built in syntax checking
>>of a HLL compared to an assembler.
> So you want to demonstrate the superiority of the Fortran notation
> with an example that no competent Fortran programmer will write in
> that way?  And then you parenthesize it incorrectly, a mistake that
> will not be detected by "syntax checking".
> Interestingly, in <913374461.4045.0.nnrp-04.9e98250c@news.demon.co.uk>
> (from 1998) Gareth Alun Evans (any relation to you?) gave pretty much
> the same example (in BASIC syntax, though), and made the same
> parenthesis omission mistake.  Not a testimonial for the qualities of
> infix syntax.
> If you write the example in a numerically stable way, you get several
> smaller statements rather than a big one, more like most real
> programs, and the difference between infix and postfix becomes
> smaller.  I guess that's why you choose this example; apparently it's
> hard to come up with another huge formula that many people can relate
> to.  So even if the Fortran notation would be better for writing down
> one solution of a quadratic equation in a numerically unstable way
> (and the mistakes of you and Gareth Alun Evans are evidence against
> this thesis), that says little about the quality of that notation for
> real (and competently written) programs.
> Anyway, here's a way to compute the roots (if they are real) without
> the numeric instability (you still have bad condition when bb/4 and ac
> cancel each other out, so you may want to compute that part with higher
> precision).
> : compute-q { f: a f: b/2 f: c -- q }
>  b/2 b/2 f* a c f* f- fsqrt
>  b/2 f0< if fnegate then \ avoids cancelation by the F+ below
>  b/2 f+ ;
> : quadratic { f: a f: b f: c -- x1 x2 }
>  a b f2/ c compute-q { f: q }
>  q a f/ c q f/ ;

I regret that you seem to be nit-picking over an irrelevance to the 
discussion
about readability; you discuss the hairs on the skin of the pig and not the 
flavour
of the pork.

But your last 7 lines above illustrate so well the unreadability of Forth 
being, as it is,
an assembly language.

I don't use Fortran

[toc] | [prev] | [next] | [standalone]

#49262

On 7/20/2016 3:30 PM, gareth G4SDW GQRP #3339 wrote:
> "Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
> news:2016Jul20.163523@mips.complang.tuwien.ac.at...
>> "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> writes:
>>> "Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
>>> news:2016Jul20.121415@mips.complang.tuwien.ac.at...
>>>> "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> writes:
>>>>> Consider the solution of the quadratic equation expressed in
>>>>> a HLL ...
>>>>> X = (-B + SQRT ( B**2 - 4*A*C))?2*A
>>>> Which HLL uses "?" as division operator that has lower priority than
>>>> "*"; actually, which HLL has a division operator with lower priority
>>>> than "*"?
>>> A minor typo caused by typing with the shift key held down
>>> And, yes, S/B (2*A) but neither critique answers the HLL versus assembler
>>> criticism.
>> "S/B (2*A)"?
>> What "HLL vs. assembler criticism"?
>> If your example was an attempt to show the superiority of the Fortran
>> notation over the Forth notation, then the fact that you made two
>> errors in this one line was not a good testimonial for the Fortran
>> way.
>>>> Anyway, this way of computing one of the solutions for a quadratic
>>>> equation is bad because it introduces more numerical instability than
>>>> is coming from the problem itself.  Read more about how to do it
>>>> better in
>>> Not relevant to demonsrtating the ease of use and built in syntax checking
>>> of a HLL compared to an assembler.
>> So you want to demonstrate the superiority of the Fortran notation
>> with an example that no competent Fortran programmer will write in
>> that way?  And then you parenthesize it incorrectly, a mistake that
>> will not be detected by "syntax checking".
>> Interestingly, in <913374461.4045.0.nnrp-04.9e98250c@news.demon.co.uk>
>> (from 1998) Gareth Alun Evans (any relation to you?) gave pretty much
>> the same example (in BASIC syntax, though), and made the same
>> parenthesis omission mistake.  Not a testimonial for the qualities of
>> infix syntax.
>> If you write the example in a numerically stable way, you get several
>> smaller statements rather than a big one, more like most real
>> programs, and the difference between infix and postfix becomes
>> smaller.  I guess that's why you choose this example; apparently it's
>> hard to come up with another huge formula that many people can relate
>> to.  So even if the Fortran notation would be better for writing down
>> one solution of a quadratic equation in a numerically unstable way
>> (and the mistakes of you and Gareth Alun Evans are evidence against
>> this thesis), that says little about the quality of that notation for
>> real (and competently written) programs.
>> Anyway, here's a way to compute the roots (if they are real) without
>> the numeric instability (you still have bad condition when bb/4 and ac
>> cancel each other out, so you may want to compute that part with higher
>> precision).
>> : compute-q { f: a f: b/2 f: c -- q }
>>  b/2 b/2 f* a c f* f- fsqrt
>>  b/2 f0< if fnegate then \ avoids cancelation by the F+ below
>>  b/2 f+ ;
>> : quadratic { f: a f: b f: c -- x1 x2 }
>>  a b f2/ c compute-q { f: q }
>>  q a f/ c q f/ ;
>
> I regret that you seem to be nit-picking over an irrelevance to the
> discussion
> about readability; you discuss the hairs on the skin of the pig and not the
> flavour
> of the pork.
>
> But your last 7 lines above illustrate so well the unreadability of Forth
> being, as it is,
> an assembly language.
>
> I don't use Fortran

It is only unreadable to those who refuse to learn it.  The code Anton 
posted is very simple and clear.  If you can't understand it either you 
have not at all tried to learn the words he used or you simply are not 
capable of programming in a new language (to you).

He has mentioned how you made errors in your code that would not have 
been picked up by the syntax checker.  Syntax does not typically find 
logic flaws.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#49263

On Wednesday, July 20, 2016 at 9:35:05 PM UTC+2, rickman wrote:
> On 7/20/2016 3:30 PM, gareth G4SDW GQRP #3339 wrote:
> > "Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
> > news:2016Jul20.163523@mips.complang.tuwien.ac.at...
> >> "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> writes:
> >>> "Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
> >>> news:2016Jul20.121415@mips.complang.tuwien.ac.at...
> >>>> "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> writes:
[..]
> > I don't use Fortran
> 
> It is only unreadable to those who refuse to learn it.  The code Anton 
> posted is very simple and clear.  If you can't understand it either you 
> have not at all tried to learn the words he used or you simply are not 
> capable of programming in a new language (to you).
> 
> He has mentioned how you made errors in your code that would not have 
> been picked up by the syntax checker.  Syntax does not typically find 
> logic flaws.

There are at least three other reasons why this is
a bad example to show other languages' superiority
over Forth: 1) the chosen formula wants to return
TWO results in most, but not all, cases (a natural
in Forth), 2) this formula may deliver a result
of either type real or type complex (many
straightforward solutions in Forth), 3) the
result of the formula is undefined for a = 0
(but the original *linear* equation is perfectly
valid).

We had a nice discussion over this in CLF in 2002
(K. Myneni), resulting in a solution avoiding all
the numerical pitfalls and only a single exception
remaining.

-marcel

[toc] | [prev] | [next] | [standalone]

#49274

mhx@iae.nl wrote:

> the chosen formula wants to return
> TWO results in most, but not all, cases (a natural
> in Forth)

It's even more "natural" in Scheme or Lisp:

gosh> (values 2 3)
2
3
gosh> (values->list (values 2 3))
(2 3)

In other languages, one simply returns a list or an array.

[toc] | [prev] | [next] | [standalone]

#49295

On Wednesday, July 20, 2016 at 12:35:05 PM UTC-7, rickman wrote:
> On 7/20/2016 3:30 PM, gareth G4SDW GQRP #3339 wrote:
> > "Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
> > news:2016Jul20.163523@mips.complang.tuwien.ac.at...
> >> "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> writes:
> >>> "Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
> >>> news:2016Jul20.121415@mips.complang.tuwien.ac.at...
> >>>> "gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> writes:
> >>>>> Consider the solution of the quadratic equation expressed in
> >>>>> a HLL ...
> >>>>> X = (-B + SQRT ( B**2 - 4*A*C))?2*A
> >>>> Which HLL uses "?" as division operator that has lower priority than
> >>>> "*"; actually, which HLL has a division operator with lower priority
> >>>> than "*"?
> >>> A minor typo caused by typing with the shift key held down
> >>> And, yes, S/B (2*A) but neither critique answers the HLL versus assembler
> >>> criticism.
> >> "S/B (2*A)"?
> >> What "HLL vs. assembler criticism"?
> >> If your example was an attempt to show the superiority of the Fortran
> >> notation over the Forth notation, then the fact that you made two
> >> errors in this one line was not a good testimonial for the Fortran
> >> way.
> >>>> Anyway, this way of computing one of the solutions for a quadratic
> >>>> equation is bad because it introduces more numerical instability than
> >>>> is coming from the problem itself.  Read more about how to do it
> >>>> better in
> >>> Not relevant to demonsrtating the ease of use and built in syntax checking
> >>> of a HLL compared to an assembler.
> >> So you want to demonstrate the superiority of the Fortran notation
> >> with an example that no competent Fortran programmer will write in
> >> that way?  And then you parenthesize it incorrectly, a mistake that
> >> will not be detected by "syntax checking".
> >> Interestingly, in <913374461.4045.0.nnrp-04.9e98250c@news.demon.co.uk>
> >> (from 1998) Gareth Alun Evans (any relation to you?) gave pretty much
> >> the same example (in BASIC syntax, though), and made the same
> >> parenthesis omission mistake.  Not a testimonial for the qualities of
> >> infix syntax.
> >> If you write the example in a numerically stable way, you get several
> >> smaller statements rather than a big one, more like most real
> >> programs, and the difference between infix and postfix becomes
> >> smaller.  I guess that's why you choose this example; apparently it's
> >> hard to come up with another huge formula that many people can relate
> >> to.  So even if the Fortran notation would be better for writing down
> >> one solution of a quadratic equation in a numerically unstable way
> >> (and the mistakes of you and Gareth Alun Evans are evidence against
> >> this thesis), that says little about the quality of that notation for
> >> real (and competently written) programs.
> >> Anyway, here's a way to compute the roots (if they are real) without
> >> the numeric instability (you still have bad condition when bb/4 and ac
> >> cancel each other out, so you may want to compute that part with higher
> >> precision).
> >> : compute-q { f: a f: b/2 f: c -- q }
> >>  b/2 b/2 f* a c f* f- fsqrt
> >>  b/2 f0< if fnegate then \ avoids cancelation by the F+ below
> >>  b/2 f+ ;
> >> : quadratic { f: a f: b f: c -- x1 x2 }
> >>  a b f2/ c compute-q { f: q }
> >>  q a f/ c q f/ ;
> >
> > I regret that you seem to be nit-picking over an irrelevance to the
> > discussion
> > about readability; you discuss the hairs on the skin of the pig and not the
> > flavour
> > of the pork.
> >
> > But your last 7 lines above illustrate so well the unreadability of Forth
> > being, as it is,
> > an assembly language.
> >
> > I don't use Fortran
> 
> It is only unreadable to those who refuse to learn it.  The code Anton 
> posted is very simple and clear.  If you can't understand it either you 
> have not at all tried to learn the words he used or you simply are not 
> capable of programming in a new language (to you).
> 
> He has mentioned how you made errors in your code that would not have 
> been picked up by the syntax checker.  Syntax does not typically find 
> logic flaws.

This is a troll thread. Rickman has never posted any Forth code on comp.lang.forth, and there is no evidence to indicate that he knows how to program in Forth. Gareth is posting non-Forth code on comp.lang.forth, and there is no evidence to indicate that he knows how to program in Forth. Rickman and Gareth are just trolls flaming each other, each claiming to be a big expert in a subject that he knows nothing about.

Anton Ertl pointed out problems with Gareth's code, but Gareth hasn't fixed them. WJ pointed out problems in Anton Ertl's code but Anton Ertl did fix them --- it was important that he did that --- I can respect anybody who writes code that works.

[toc] | [prev] | [next] | [standalone]

#49275

Anton Ertl wrote:

> : compute-q { f: a f: b/2 f: c -- q }
>   b/2 b/2 f* a c f* f- fsqrt
>   b/2 f0< if fnegate then \ avoids cancelation by the F+ below
>   b/2 f+ ;
> 
> : quadratic { f: a f: b f: c -- x1 x2 }
>   a b f2/ c compute-q { f: q }
>   q a f/ c q f/ ;

Charles Moore said that local variables are harmful,
but Anton had to use them.  Imagine how unwritable
and how unreadable his code would have been without them!
It's atrocious enough already.

Testing:

3e0 -10e0 5e0 quadratic  ok
.s <0>  ok
f. -0.612574113277207  ok
f. -2.72075922005613  ok

Both results are wrong.

Note a very important fact.  None of the Forth "gurus"
posting in this thread noticed that his code produces
absolutely incorrect results.  Correctness matters
far less than dogmatic devotion to a stone-age language.


Julia:

quad(a,b,c) = (t = -b/2a; q = sqrt(b^2 - 4a*c)/2a; [t+q, t-q])

julia> quad(3,-10,5)
2-element Array{Float64,1}:
 2.72076
 0.612574

julia> quad(1,2,-8)
2-element Array{Float64,1}:
  2.0
 -4.0


Employing the other formula, but using a real language (Julia):

calc_q(a, b_2, c) = copysign(sqrt(b_2^2 - a*c), b_2) + b_2

quad(a,b,c) = (q = -calc_q(a, b/2, c); [q/a, c/q])

julia> quad(1,2,-8)
2-element Array{Float64,1}:
 -4.0
  2.0

julia> quad(3,-10,5)
2-element Array{Float64,1}:
 2.72076
 0.612574

-- 
Amazon bans book.  After nearly a month on the site, all traces of the book and
its 80 reviews have been removed.
http://jamesfetzer.blogspot.com/2015/11/debunking-sandy-hook-debunkers-5.html
https://www.youtube.com/watch?v=EEl_1HWFRfo

[toc] | [prev] | [next] | [standalone]

#49276

"WJ" <w_a_x_man@yahoo.com> writes:
>Anton Ertl wrote:
>
>> : compute-q { f: a f: b/2 f: c -- q }
>>   b/2 b/2 f* a c f* f- fsqrt
>>   b/2 f0< if fnegate then \ avoids cancelation by the F+ below
>>   b/2 f+ ;
>> 
>> : quadratic { f: a f: b f: c -- x1 x2 }
>>   a b f2/ c compute-q { f: q }
>>   q a f/ c q f/ ;
...
>3e0 -10e0 5e0 quadratic  ok
>.s <0>  ok
>f. -0.612574113277207  ok
>f. -2.72075922005613  ok
>
>Both results are wrong.

Good catch.  And looking in the history, I actually did run it on
these parameters, but either did not check the results, or overlooked
the "-".  Lesson: Better have an automated check of the result, even
if you are using an algorithm that should be correct; there can be a
bug in the transcription (as happened here) or in the published
version.

Here's a corrected version of the code, plus a check:

: compute-q { f: a f: b/2 f: c -- q }
  b/2 b/2 f* a c f* f- fsqrt
  b/2 f0>= if fnegate then \ avoids cancelation by the F+ below
  b/2 f- ;

: quadratic { f: a f: b f: c -- x1 x2 }
  a b f2/ c compute-q { f: q }
  q a f/ c q f/ ;

: check { f: a f: b f: c -- }
\ should print two 0s, or something close to 0
  a b c quadratic 2 0 do { f: x }
    a x f* x f* b x f* f+ c f+ f.
  loop ;
   
- 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 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#49288

"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message 
news:2016Jul21.144416@mips.complang.tuwien.ac.at...
> Here's a corrected version of the code, plus a check:
>
> : compute-q { f: a f: b/2 f: c -- q }
>  b/2 b/2 f* a c f* f- fsqrt
>  b/2 f0>= if fnegate then \ avoids cancelation by the F+ below
>  b/2 f- ;
>
> : quadratic { f: a f: b f: c -- x1 x2 }
>  a b f2/ c compute-q { f: q }
>  q a f/ c q f/ ;
>
> : check { f: a f: b f: c -- }
> \ should print two 0s, or something close to 0
>  a b c quadratic 2 0 do { f: x }
>    a x f* x f* b x f* f+ c f+ f.
>  loop ;

It is unclear from the above as to whether you speak for, or against, the 
motion
that programming in Forth is programming with all the difficulties 
encountered
by human beings when programming in assembly language.

Collapse of stout party?

[toc] | [prev] | [next] | [standalone]

#49313

"gareth G4SDW GQRP #3339" <no.spam@thank.you.invalid> writes:
>"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message 
>news:2016Jul21.144416@mips.complang.tuwien.ac.at...
>> Here's a corrected version of the code, plus a check:
>>
>> : compute-q { f: a f: b/2 f: c -- q }
>>  b/2 b/2 f* a c f* f- fsqrt
>>  b/2 f0>= if fnegate then \ avoids cancelation by the F+ below
>>  b/2 f- ;
>>
>> : quadratic { f: a f: b f: c -- x1 x2 }
>>  a b f2/ c compute-q { f: q }
>>  q a f/ c q f/ ;
>>
>> : check { f: a f: b f: c -- }
>> \ should print two 0s, or something close to 0
>>  a b c quadratic 2 0 do { f: x }
>>    a x f* x f* b x f* f+ c f+ f.
>>  loop ;
>
>It is unclear from the above as to whether you speak for, or against, the 
>motion
>that programming in Forth is programming with all the difficulties 
>encountered
>by human beings when programming in assembly language.

Programming in Forth has the following advantages over programming in
assembly language:

* Interactivity: You can run and test individual words directly.

* Portability: No need to rewrite when moving, e.g., from AMD64 to ARM.

* Stacks: No need to worry about saving and restoring registers.

Do you have any other difficulties in mind?

- 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 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#49320

"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message 
news:2016Jul22.084236@mips.complang.tuwien.ac.at...
>
> Programming in Forth has the following advantages over programming in
> assembly language:


But programming in Forth _IS_ programming in assembly languge, a simulation
of the assembly language of the English Electric KDF9 which was published as
prior art when Forth was first conceived.

As to the characteristics that you listed, all apply equally well to a 
number
of other interpreted environments such as Python and TCL.

[toc] | [prev] | [next] | [standalone]

#49324

On 7/22/2016 7:03 AM, gareth G4SDW GQRP #3339 wrote:
> "Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
> news:2016Jul22.084236@mips.complang.tuwien.ac.at...
>>
>> Programming in Forth has the following advantages over programming in
>> assembly language:
>
>
> But programming in Forth _IS_ programming in assembly languge, a simulation
> of the assembly language of the English Electric KDF9 which was published as
> prior art when Forth was first conceived.

It is clear that you don't know much about Forth.  You are zeroed in on 
the fact that the language appears to emulate a stack machine.  It is 
also odd that you are solely focused on the KDF9 which is a machine that 
Chuck Moore is unlikely to have ever seen while the Burroughs B5500 was 
a machine he specifically talks about.

http://worrydream.com/refs/Moore%20-%20Forth%20-%20The%20Early%20Years.pdf

https://en.wikipedia.org/wiki/Burroughs_large_systems

http://www.forth.org/fd/FD-V01N6.pdf

https://uwaterloo.ca/independent-studies/sites/ca.independent-studies/files/uploads/files/eric_laforest_thesis.pdf

This last one is particularly interesting in that it specifically says 
there is *no* connection between Moore's work on Forth and the KDF9 or


> As to the characteristics that you listed, all apply equally well to a
> number
> of other interpreted environments such as Python and TCL.

Yes, so you agree Forth is not assembly language?

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web