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

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

revisiting a prgramming problem

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

Contents

  revisiting a prgramming problem gavino_himself <visploveslisp@gmail.com> - 2014-10-14 15:55 -0700
    Re: revisiting a prgramming problem hughaguilar96@yahoo.com - 2014-10-14 18:52 -0700
      Re: revisiting a prgramming problem Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-21 17:58 +0200
        Re: revisiting a prgramming problem Paul Rubin <no.email@nospam.invalid> - 2014-10-21 09:09 -0700
          Re: revisiting a prgramming problem Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-21 22:18 +0200
            Re: revisiting a prgramming problem rickman <gnuarm@gmail.com> - 2014-10-23 15:44 -0400
              Re: revisiting a prgramming problem "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-23 17:01 -0400
              Re: revisiting a prgramming problem the_gavino_himself <visphatesjava@gmail.com> - 2014-11-08 21:33 -0800
                Re: revisiting a prgramming problem rickman <gnuarm@gmail.com> - 2014-11-29 20:40 -0500
                  Re: revisiting a prgramming problem the_gavino_himself <visphatesjava@gmail.com> - 2014-12-01 22:43 -0800
                    Re: revisiting a prgramming problem rickman <gnuarm@gmail.com> - 2014-12-02 02:47 -0500
                      Re: revisiting a prgramming problem Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-12-02 11:53 +0000
                      Re: revisiting a prgramming problem the_gavino_himself <visphatesjava@gmail.com> - 2014-12-02 05:23 -0800
                        Re: revisiting a prgramming problem rickman <gnuarm@gmail.com> - 2014-12-02 09:01 -0500
          Re: revisiting a prgramming problem Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-21 22:25 +0200
            Re: revisiting a prgramming problem Paul Rubin <no.email@nospam.invalid> - 2014-10-21 16:10 -0700
              Re: revisiting a prgramming problem the_gavino_himself <visphatesjava@gmail.com> - 2014-11-08 21:41 -0800
          Re: revisiting a prgramming problem Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-21 22:30 +0200
            Re: revisiting a prgramming problem the_gavino_himself <visphatesjava@gmail.com> - 2014-12-01 22:45 -0800
          Re: revisiting a prgramming problem Hans Bezemer <the.beez.speaks@gmail.com> - 2014-10-21 23:04 +0200
        Re: revisiting a prgramming problem Mark Wills <markwills1970@gmail.com> - 2014-10-21 10:17 -0700
          Re: revisiting a prgramming problem "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-22 02:13 -0400
            Re: revisiting a prgramming problem Paul Rubin <no.email@nospam.invalid> - 2014-10-21 23:26 -0700
              Re: revisiting a prgramming problem "Alex McDonald" <blog@rivadpm.com> - 2014-10-22 16:18 +0100
                Re: revisiting a prgramming problem mhx@iae.nl (Marcel Hendrix) - 2014-10-22 21:27 +0200
                  Re: revisiting a prgramming problem albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-24 10:30 +0000
                    Optimal comparisons for m maximums from n items  (was Re: revisiting a prgramming problem) "Alex McDonald" <blog@rivadpm.com> - 2014-10-24 16:29 +0100
                      Re: Optimal comparisons for m maximums from n items  (was Re: revisiting a prgramming problem) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-25 08:27 +0000
                        Re: Optimal comparisons for m maximums from n items (was Re: revisiting a prgramming problem) "Alex McDonald" <blog@rivadpm.com> - 2014-10-25 18:54 +0100
                    Re: revisiting a prgramming problem mhx@iae.nl (Marcel Hendrix) - 2014-10-25 13:28 +0200
                    Re: revisiting a prgramming problem mhx@iae.nl (Marcel Hendrix) - 2014-10-25 14:28 +0200
                    Re: revisiting a prgramming problem mhx@iae.nl (Marcel Hendrix) - 2014-10-25 15:17 +0200
              Re: revisiting a prgramming problem Gerry Jackson <spam@qlikz.org> - 2014-10-22 21:57 +0100
                Re: revisiting a prgramming problem Paul Rubin <no.email@nospam.invalid> - 2014-10-22 14:06 -0700
                  Re: revisiting a prgramming problem Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-23 00:03 +0200
                  Re: revisiting a prgramming problem albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-23 14:46 +0000
                    Re: revisiting a prgramming problem Paul Rubin <no.email@nospam.invalid> - 2014-10-23 08:16 -0700
                    Re: revisiting a prgramming problem "Alex McDonald" <blog@rivadpm.com> - 2014-10-23 19:21 +0100
                      Re: revisiting a prgramming problem "Alex McDonald" <blog@rivadpm.com> - 2014-10-23 20:02 +0100
                        Re: revisiting a prgramming problem albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-23 20:29 +0000
                    Re: revisiting a prgramming problem Coos Haak <chforth@hccnet.nl> - 2014-10-23 22:23 +0200
                Re: revisiting a prgramming problem awegel@arcor.de (Alexander Wegel) - 2014-10-23 00:36 +0200
                  Re: revisiting a prgramming problem Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-24 10:44 +0100
                Re: revisiting a prgramming problem hughaguilar96@yahoo.com - 2014-10-22 17:26 -0700
                  Re: revisiting a prgramming problem Michael Barry <barrym95838@yahoo.com> - 2014-10-23 00:02 -0700
            Re: revisiting a prgramming problem the_gavino_himself <visphatesjava@gmail.com> - 2014-11-08 23:10 -0800
          Re: revisiting a prgramming problem the_gavino_himself <visphatesjava@gmail.com> - 2014-11-08 21:42 -0800
    Re: revisiting a prgramming problem Roger Levy <roger.levy@gmail.com> - 2014-10-15 08:18 -0700
      Re: revisiting a prgramming problem Roger Levy <roger.levy@gmail.com> - 2014-10-15 08:18 -0700
        Re: revisiting a prgramming problem november.nihal@gmail.com - 2014-10-15 08:57 -0700
        Re: revisiting a prgramming problem Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-10-15 17:10 +0100
        Re: revisiting a prgramming problem "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-17 21:53 -0400
      Re: revisiting a prgramming problem Roger Levy <roger.levy@gmail.com> - 2014-10-15 08:19 -0700
    Re: revisiting a prgramming problem awegel@arcor.de (Alexander Wegel) - 2014-10-22 00:30 +0200
      Re: revisiting a prgramming problem hughaguilar96@yahoo.com - 2014-10-21 16:07 -0700
        Re: revisiting a prgramming problem awegel@arcor.de (Alexander Wegel) - 2014-10-22 03:23 +0200
          Re: revisiting a prgramming problem "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-22 02:15 -0400
            Re: revisiting a prgramming problem awegel@arcor.de (Alexander Wegel) - 2014-10-22 12:52 +0200
          Re: revisiting a prgramming problem hughaguilar96@yahoo.com - 2014-10-22 17:19 -0700
            Re: revisiting a prgramming problem awegel@arcor.de (Alexander Wegel) - 2014-10-23 16:10 +0200
        Re: revisiting a prgramming problem "Rod Pemberton" <buzzoff@nonamewhichexists.cmm> - 2014-10-22 02:14 -0400
        Re: revisiting a prgramming problem the_gavino_himself <visphatesjava@gmail.com> - 2014-11-08 23:21 -0800
        Re: revisiting a prgramming problem "WJ" <w_a_x_man@yahoo.com> - 2014-12-06 02:34 +0000
        Re: revisiting a prgramming problem "WJ" <w_a_x_man@yahoo.com> - 2014-12-27 08:00 +0000
          Re: revisiting a prgramming problem Mark Wills <markwills1970@gmail.com> - 2014-12-27 05:15 -0800
    Re: revisiting a prgramming problem "WJ" <w_a_x_man@yahoo.com> - 2014-11-29 17:20 +0000
      Re: revisiting a prgramming problem the_gavino_himself <visphatesjava@gmail.com> - 2014-11-29 12:00 -0800
      Re: revisiting a prgramming problem "WJ" <w_a_x_man@yahoo.com> - 2014-12-02 16:15 +0000
    Re: revisiting a prgramming problem Paul Sephton <prsephton@gmail.com> - 2014-12-02 05:06 -0800
      Re: revisiting a prgramming problem Paul Sephton <prsephton@gmail.com> - 2014-12-02 05:14 -0800
      Re: revisiting a prgramming problem the_gavino_himself <visphatesjava@gmail.com> - 2014-12-02 05:24 -0800

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#34123

Op 23 Oct 2014 14:46:10 GMT schreef Albert van der Horst:

> In article <7xoat37r0s.fsf@ruckus.brouhaha.com>,
> Paul Rubin  <no.email@nospam.invalid> wrote:
>>Gerry Jackson <spam@qlikz.org> writes:
>>>> MAX of course wraps a conditional
>>> 'Of course'? In practice you are almost certainly correct but MAX (and
>>> MIN) can be implemented in ANS Forth without an IF...
>>> : max 2dup < 1+ pick nip nip ;
>>
>>How do you think < works?
> 
> Typical code for 32 bits Pentium (from yourforth):
> 
>      header  _less_,   _less_+5*cw, 0, 0, lastlink, "<"
>          pop     edx
>          pop     ebx
>          xor     eax,eax
>          cmp     ebx,edx
>          setl    al       ; Set bit to "less"
>          neg     eax
>          push    eax
>          next
> 
> Groetjes Albert

16 bits Forth and TOS in BX

  pop     ax
  cmp     ax,bx
  setl    bl
  and     bx,$0001
  neg     bx
  next

-- 
Coos

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

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

#34101

Gerry Jackson <spam@qlikz.org> wrote:

> Any more?

: min 2dup < dup 0= 2and or ;

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

#34128

On 22/10/2014 23:36, Alexander Wegel wrote:
> Gerry Jackson <spam@qlikz.org> wrote:
>
>> Any more?
>
> : min 2dup < dup 0= 2and or ;
>

Yes I didn't think of that approach. Using INVERT would be better than 
0= also it needs 2AND defining e.g.
: 2and  rot and >r and r> ;

-- 
Gerry

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

#34104

On Wednesday, October 22, 2014 1:57:43 PM UTC-7, Gerry Jackson wrote:
> On 22/10/2014 07:26, Paul Rubin wrote:
> > MAX of course wraps a conditional
> 
> 'Of course'? 

Apparently nobody involved in this thread knows about the CMOVcc instruction in x86 assembly-language.

VFX will generate good code for MIN and MAX, so apparently Pelc knows about the CMOVcc instruction.

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

#34109

On Wednesday, October 22, 2014 5:26:33 PM UTC-7, hughag...@yahoo.com wrote:

> 
> Apparently nobody involved in this thread knows about the CMOVcc
> instruction in x86 assembly-language.
> 
> VFX will generate good code for MIN and MAX, so apparently Pelc knows
> about the CMOVcc instruction.

I never followed the x86 line past the 086, because I found its assembly
 language unappealing, but CMOVcc appears to have debuted on the Pentium
 Pro, and a quick search led me to this interesting (although a bit off-
 topic) question:

http://objectmix.com/asm-x86-asm-370/69393-futility-cmovcc.html

Mike

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

#34369

On Tuesday, October 21, 2014 11:12:01 PM UTC-7, Rod Pemberton wrote:
> On Tue, 21 Oct 2014 13:17:45 -0400, Mark Wills <markwills1970@gmail.com>  
> wrote:
> > On Tuesday, 21 October 2014 16:57:19 UTC+1, The Beez  wrote:
> 
> <HA>
> > After you have this first program written, and everybody is cheering
> > for you, write another program that takes *2* numbers and squares
> > each of them, adding the products together. Then you are done!
> </HA>
> 
> >>
> >> Duh.. : sumofsquare over max dup * >r max dup * r> + ;
> >>
> > That's not how I interpret Hugh's challenge. It says take two numbers,  
> > not the highest two of three. Perhaps I'm reading it wrong...
> >
> > : sos ( a b -- n ) dup * >r dup * r> + ;
> 
> Hugh broke the problem into two parts:
> 
> 1) maximum two of three
> 2) sum of squares of results of #1
> 
> That was his brain teaser. #1 really needs to be 2 parts.
> 
> AISI, it's really a three part problem because the three
> values really need to be sorted first, largest to smallest,
> to _safely_ remove or drop the smallest, thereby leaving
> the two largest.
> 
> : 2SORT 2DUP < IF SWAP THEN ;
> : 2MAX 2SORT ROT 2SORT DROP ;
> : SQSUM 2MAX DUP * SWAP DUP * + ;
> 
> Expanded, it's only a hair longer longer than the one
> of Beez' which I think works correctly.  It doesn't need
> the return stack.  And, you might be able to work MAX in
> for one of the 2SORTS that way, shortening it to the same
> length or thereabouts.
> 
> 
> Rod Pemberton

works nicely

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

#34366

On Tuesday, October 21, 2014 10:17:46 AM UTC-7, Mark Wills wrote:
> On Tuesday, 21 October 2014 16:57:19 UTC+1, The Beez  wrote:
> After you have this first program written, and everybody is cheering for
> you, write another program that takes *2* numbers and squares each of them,
> adding the products together. Then you are done!
> > 
> > Duh.. : sumofsquare over max dup * >r max dup * r> + ;
> > 
> > 
> > 
> > Hans Bezemer
> 
> That's not how I interpret Hugh's challenge. It says take two numbers, not the highest two of three. Perhaps I'm reading it wrong...
> 
> : sos ( a b -- n ) dup * >r dup * r> + ;

the challenge is sum sqaures of 2 biggest

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

#33914

1 2 3 drop drop drop 15

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

#33915

On Wednesday, October 15, 2014 11:18:06 AM UTC-4, Roger Levy wrote:
> 1 2 3 drop drop drop 15

that's a 13, nobody saw that

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

#33919

Déjà vu 


https://groups.google.com/forum/#!topic/comp.lang.forth/avJCQhwciTs

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

#33920

On 15/10/2014 16:18, Roger Levy wrote:
> On Wednesday, October 15, 2014 11:18:06 AM UTC-4, Roger Levy wrote:
>> 1 2 3 drop drop drop 15
>
> that's a 13, nobody saw that
>

No it was correct, you were working with octal numbers

-- 
Gerry

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

#33994

On Wed, 15 Oct 2014 11:18:43 -0400, Roger Levy <roger.levy@gmail.com>  
wrote:
> On Wednesday, October 15, 2014 11:18:06 AM UTC-4, Roger Levy wrote:

>> 1 2 3 drop drop drop 15
>
> that's a 13, nobody saw that

Fail.

This is not because of the posted results.
You didn't follow the directions which said
to 1) compute the result and 2) accept any
three numbers.

;-)


Rod Pemberton

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

#33916

that's a 13 nobody saw that

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

#34074

gavino_himself <visploveslisp@gmail.com> wrote:

> 1.3 in sicp book on scheme from MIT
> 
> given 3 numbers, produce the sum of the squares of the biggest 2 of 3
> 
> 
> can someone provide the solution again and explanation?
> 
> thx

That (other thread which i didn't participate in) was a while ago, and
there were some solutions.
So here's my take (with an eye on algorithmic understandability):

: msquare ( n -- d )  \ mixed-precision integer square
  dup m* ;

: minmax ( n1 n2 -- n1 n2 | n2 n1 )  \ bigger comes out atop
  2dup > if swap then ;

: msum_of_squares ( n1 n2 n3 -- d )  \ mixed-precision solution
  minmax >r        \ move bigger of n2 and n3 to r-stack
  max              \ discard smaller (=smallest overall) number
  msquare r> msquare d+  \ calculate result
;

(a single-precision version can be derived from this easily)

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

#34077

On Tuesday, October 21, 2014 3:31:01 PM UTC-7, Alexander Wegel wrote:
> gavino_himself <visploveslisp@gmail.com> wrote:
> 
> > 1.3 in sicp book on scheme from MIT
> 
> > given 3 numbers, produce the sum of the squares of the biggest 2 of 3
> 
> > can someone provide the solution again and explanation?
> 
> > thx

> That (other thread which i didn't participate in) was a while ago, and
> there were some solutions.
> So here's my take (with an eye on algorithmic understandability):

The other thread was:
https://groups.google.com/forum/#!topic/comp.lang.forth/YJxex8DrFD8%5B26-50-false%5D

Why are we going over this stuff again??? Apparently Gavino was pleased with how much response he got last time, so he posted the same question again. This is somewhat like when a boy drags a twig across a picket fence, and causes the dog in the yard to bark furiously at him --- this is so much fun, that he makes a habit of doing it every time that he walks past.

In that thread, Payson posted this code:

: sq ( n -- n² ) dup * ; 
: g ( a b c -- n )  2dup max sq >r min max sq r> + ; 

That was the best, I thought.

Here is Alex's code:

> : msquare ( n -- d )  \ mixed-precision integer square
>   dup m* ;
> 
> : minmax ( n1 n2 -- n1 n2 | n2 n1 )  \ bigger comes out atop
>   2dup > if swap then ;
> 
> : msum_of_squares ( n1 n2 n3 -- d )  \ mixed-precision solution
>   minmax >r        \ move bigger of n2 and n3 to r-stack
>   max              \ discard smaller (=smallest overall) number
>   msquare r> msquare d+  \ calculate result
> ;
> 
> (a single-precision version can be derived from this easily)

Alex's MINMAX is terrible.

This was my MINMAX from that thread:

: minmax ( a b -- min max ) 
    2dup min -rot  max ; 

The use of IF when it is not necessary, is very novice-level programming. Most likely, Alex doesn't know any assembly language, and doesn't know that unpredicted branches slow down the processor. Alex isn't the only "programmer" who doesn't know anything about the processor --- Elizabeth Rather is equally ignorant of assembly language. This is from that thread:

On Monday, January 21, 2013 8:35:01 PM UTC-7, Hugh Aguilar wrote:
> On Jan 14, 2:43 am, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> > Aren't you ignoring the fact that there's a conditional in min? Why so
> > important to avoid a conditional?
> 
> > Cheers,
> > Elizabeth
> 
> Elizabeth Rather doesn't know about the CMOVcc instructions in x86
> assembly language! This tells me that she doesn't know anything about
> the modern x86 processors, and she would not be able to write even a
> simple function such as MIN or MAX in assembly language. Also, she
> asks: "Why so important to avoid a conditional?" This tells me that
> she doesn't know anything about any x86 processor, all the way back to
> the 8088 (see Abrash's first book for a lengthy discussion of how
> branches empty out the prefetch queue on the 8088).
> 
> This is an abysmal level of ignorance! Branching has been an issue on
> all processors, for the last 30 years! To find a processor that
> branching wasn't an issue on, you have to go back to things like the
> 65c02 and the Z80 (and the PDP-11 afaik) that didn't do any look-ahead
> at all, but just executed each opcode one after the other, with each
> taking a fixed number of clock cycles. That world hasn't existed since
> I was a teenager.
> 
> I don't consider Elizabeth Rather to be a programmer at all. When she
> says that my code "sucks," she is speaking as a Forth Inc.
> salesperson, and not as a technical person. She really knows nothing
> about the subject --- except that she wants people to spend $500 on
> SwiftForth --- but she doesn't have any technical knowledge.

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

#34081

<hughaguilar96@yahoo.com> wrote:

> Why are we going over this stuff again???

That's what i ask myself every second post by you. All the thousands of
wasted lines where you repeat your insults, generally false accusations,
and useless rants are a real bore.

> The use of IF when it is not necessary, is very novice-level programming.

Well - it was meant for a novice to understand, not as an excercise in
premature optimization - so what.

> Most likely, Alex doesn't know any assembly language, and doesn't know that
> unpredicted branches slow down the processor. Alex isn't the only "programmer"
> who doesn't know anything about the processor

Wow - you're not just drawing (wrong) conclusions from nothing, but you
use them to add more insults and lies (which obviously was your reason
for posting this in the first place).

BTW: Your minmax isn't that bright either.

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

#34084

On Tue, 21 Oct 2014 21:23:55 -0400, Alexander Wegel <awegel@arcor.de>  
wrote:

> <hughaguilar96@yahoo.com> wrote:
>
>> Why are we going over this stuff again???
>
> That's what i ask myself every second post by you.

Alex why are _you_ specifically  ***SO***  freaking angry over
events and words which _never_ directly affected you?

With Hugh and Gavino in this thread I had a strange thought ...
But, I wasn't going to post it at first.

However, with anti-troll and new rant Alex joining in, who sounds
much like he is reliving John Passiniti's past and not his own,
and who seems to have much the same unbounded, out-of-control
fury, and desire to insult and provoke others as J.P. did, I
decided to go ahead and post it.

Now, it's time for the for the odd thought:

The condition of being a troll is testable in Forth.
It's the value of the condition which is indeterminable
by Forth and requires human input ...

: ?TROLL ( x -- ) IF ." TROLL!" THEN ;


Rod Pemberton

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

#34088

Rod Pemberton <buzzoff@nonamewhichexists.cmm> wrote:

> On Tue, 21 Oct 2014 21:23:55 -0400, Alexander Wegel <awegel@arcor.de>
> wrote:
> 
> > <hughaguilar96@yahoo.com> wrote:
> >
> >> Why are we going over this stuff again???
> >
> > That's what i ask myself every second post by you.
> 
> Alex why are _you_ specifically  ***SO***  freaking angry over
> events and words which _never_ directly affected you?

I don't have time for your nonsense - practice reading, then maybe one
day you get it.

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

#34103

On Tuesday, October 21, 2014 6:23:57 PM UTC-7, Alexander Wegel wrote:
> <hughaguilar96@yahoo.com> wrote:
> > The use of IF when it is not necessary, is very novice-level programming.
> 
> Well - it was meant for a novice to understand, not as an excercise in
> premature optimization - so what.

Actually, the use of gratuitous control-structures reduces readability. In general, IF statements slow down the reader's understanding of the code because he has to consider two paths, effectively the same as if he had to understand two functions rather than one --- this is made worse by nested IF statements. This point was made in "Thinking Forth" --- it has been well-known since the late 1970s.

This problem presented by Gavino is very simple. This is why I challenged Gavino to solve it himself, as his first-ever Forth program (which he didn't do --- no surprise there!). Despite how easy this problem is, Alex still managed to mess it up, using gratuitous control-structures and generally ugly Forth.

Consider this thread:
https://groups.google.com/forum/#!searchin/comp.lang.forth/codejam/comp.lang.forth/3Y4w_MdYl0k/IMCaSNvF864J

Alex is a master of obfuscated Forth code --- here we have his masterpiece:

On Tuesday, May 1, 2012 10:12:25 AM UTC-7, Alex Wegel wrote:
> Here it comes - cheers,
> Alex
> 
> #! /usr/local/bin/gforth-fast
> 0 value hi
> create d 36 allot
> : wipe d 36 erase 0 to hi ;
> : +dig d hi + c! 1 hi + to hi ;
> : >dig?
>   hi begin dup while
>     1 - 2dup d + c@ = if nip true exit then
>   repeat drop false ;
> : twiddle dup >r c@ r@ char+ c@ r@ c! r> char+ c! ;
> : pars
>   bounds do
>     i c@ >dig? if drop else +dig then
>   loop d twiddle hi 2 max to hi ;
> : dig> dup 9 > if 7 + then [char] 0 + ;
> : eval
>   2dup pars 2dup bounds do i c@ >dig? drop dig> i c! loop
>   hi base ! s>unumber? drop decimal ;
> : getl pad dup 64 stdin read-line throw drop ;
> : .. ." Case #" 1 .r ." : " 1 ud.r cr ;
> : app getl evaluate 0 do getl eval i 1+ .. wipe loop ;
> ' noop is bootmessage
> app bye

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

#34110

<hughaguilar96@yahoo.com> wrote:

> Despite how easy this problem is, Alex still managed to mess it up,

Well - if it's you who writes that, then most likely there isn't a
problem with my code.

> Consider this thread:
> https://groups.google.com/forum/#!searchin/comp.lang.forth/codejam/ [...]

Yes, but from the beginning (still laughing).

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web