Re: [colorforth] Euler Project Problems.
- Subject: Re: [colorforth] Euler Project Problems.
- From: "Ray St. Marie" <ray.stmarie@xxxxxxxxx>
- Date: Tue, 20 May 2008 23:44:40 -0600
Am I wrong again?
: READ.DECIMAL.NUMBER
\ ( --- >> "number.string" )
1 TO PRECISION \ Reset precision
BL WORD \ get from input
COUNT \ String.address length
DUP 0= ABORT" Please input a number"
DUP length ! \ Remember!
0 DO \ Convert each digit
C@+ ASCII->BINARY
I num digit! \ to binary in number.
LOOP DROP \ Drop string address.
10 current.base digit! \ Start with decimal
0 current.base CELL+ ! \ Guard decimal for the overflow
;
READ.DECIMAL.NUMBER starts out pretty kosher. It resets a variable,
gets input and does COUNT.
The length of the string is passed by an abort test and a duplicate
stored in a variable, then we enter the do loop with the length as the
limit.
Okay so far so good. C@+ as we've said could be replaced with COUNT.
but this time we are not taking the count of a string, we are taking a
count of the address on the stack which happens to be the address that
we got when we did the first count.
Is this intentional?
I created a test...
: raytest bl word count ( print original count ) 2dup . .
( drop and print the length of original count and leave the address on
the stack simulating entering the above do-loop) drop dup .
( count again? ) count . . ;
entering we get
raytest string 6 -9479113 -9479113 115 -9479112 ok
The length is different.. and the address is now incremented by one.
I'm not sure this is what the author originally intended. I'm thinking
that the original length is what was needed.
---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com