Re: Parsing timestamps?

On 30/10/2024 7:37 pm, Hans Bezemer wrote:

On 30-10-2024 01:31, dxf wrote:

On 30/10/2024 12:45 am, Hans Bezemer wrote:

On 29-10-2024 10:25, dxf wrote:

On 29/10/2024 4:07 am, Hans Bezemer wrote:

...
I have put the complication elsewhere. If we assume we're working in decimal, you don't even need >NUMBER:
>
char 0 negate +constant 0-
>
: /int    ( a1 n1 -- a2 n2 n3)
    0 >r 1 >r 1- chars over +
    begin
     over 1- over <
    while
      dup c@ is-digit
    while
      dup c@ 0- r> tuck * r> + >r 10 * >r 1-
    repeat over - rdrop r> -rot
;
...

>
So that's how to convert a numeric string from the other end.
Nice!  Easier than I imagined it would be.

>
TORS is the multiplier, 2ORS is the accumulator. Normally, the multiplier is multiplied after each run with BASE @ - but that makes little sense when IS-DIGIT isn't properly adjusted. Would be a nice exercise, though.

>
Something like this...
>
\  \CHAR ( a u -- a u-1 c )
\  >DIGIT ( c base -- u -1 | c 0 )
>
: /INT ( a1 n1 -- a2 n2 u )
   0 >r  1  begin  >r  dup while
     \char  base @ >digit  while
     r> tuck  *  r> + >r  base @ *
   repeat  drop ( -1 /string)  then  rdrop  r> ;
>
OTOH the necessity to convert R-L is probably rare.

 
Yes, R-L number parsing is very rare. This time, it felt like the easiest solution, though. Equally when you're parsing a non-decimal date. That's why I left it out here. But it doesn't hurt to contemplate such things. ;-)
 
I got the words you describe as "STRING/C" (rings a bell?) and "DIGIT?". Seem like natural candidates to tackle this problem.

Char extraction occurs often that it made sense to make them bona-fide words.
Having them in the kernel meant I could code them in asm for extra speed.

It raises the question of whether it's better to test then extract - or extract
then test.  The latter is simpler but it can mean one has to undo the operation.
That was the purpose of ( -1 /string) ... which BTW was incorrect; it should have
been ( 1+) .