pika-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pika-dev] ping numbers.pika.hackerlab


From: Tom Lord
Subject: Re: [Pika-dev] ping numbers.pika.hackerlab
Date: Thu, 11 Dec 2003 09:08:42 -0800 (PST)



    > From: Matthew Dempsky <address@hidden>

    > I haven't heard any news about numbers from you in a while, so what's
    > the status of things?

It took me a few days to figure out how to do the "scaffolding" that
gets filled in with various representations and implementations of the
basic number procedures.  When you see it you might wonder _why_ it
took a few days since the end result is very simple but it took me a
while to get over trying to do something far ... er... "fancier" (to
be generous).

I've just pushed it by the way (patch-194) and though I plan to do
write a HOWTO and do some work on fixnums and doubles within the
framework -- it's there.

Basically, there are two new directories and three layers:

    --------------------------------
    |                              |
    |  scm/libscm-numbers          |
    |                              |
    |  declares interfaces to      |      A routine like `scm_add' is 
    |  numbers and provides        |      defined in scm/libscm-numbers.
    |  front ends that type-check  |      It checks that both arguments
    |  math functions and handle   |      are numbers and calls scm_reps_add
    |  "raise" errors              |      in scm/libscm-numbers-reps
    |                              |
    --------------------------------
    |                              |
    |  scm/libscm-numbers-reps     |      scm_reps_add normally adds two
    |                              |      numbers but can also instead 
    | implements math routines     |      return scm_err_numeric_raise_needed
    | and conversion <-> C types   |
    |                              |      in that case, scm_add converts
    | can add new numeric reps     |      the arguments to the same 
    | using the vtable facility    |      representation and retries
    |                              |      the add
    --------------------------------
    |                              |
    |  scm/reps                    |
    |                              |      fixnum and double representations
    |  provides optimized          |      are coded here so that they
    |  representations for         |      can be heavily optimized
    |  fixnums and doubles         |
    |                              |      other new number types just
    |  (also provides GC,          |      use the `vtable' facility
    |   vtable objects, etc.)      |
    --------------------------------


Of course, front ends to the general purpose equality predicates,
hashing function, read and write still live in scm/libscm.



    > As for floating point support in hackerlab, I haven't touched
    > the code in a while, but I'm also not to certain about how much
    > more I could improve on it.  Maybe I'll have to hope that I
    > suddenly receive some major mathematical enlightenment as to how
    > I may emulate high precision integer arithmetic efficiently.
    > I've also been thinking about testing out GMP for this, but I'm
    > not sure how you'd feel about hackerlab depending on it (maybe
    > it could be compile-time configured or something?).  Just some
    > thoughts...

Doesn't GNU libc use GMP for floating point formatting and reading?

I haven't done so yet but I am still leaning towards floating GMP in
the libscm interfaces -- use of GMP isn't in and of itself a problem.

The big issues for floating point io in libhackerlab are, in my mind,
(and in order of priority):

     1) correctness

     2) not dragging in more than a few K of .o files if your
        only use for conversion is printfmt and/or the hackerlab
        cvt_* functions;   not using absurd amounts of data
        memory at run-time for those funtions.

     3) speed

-t




reply via email to

[Prev in Thread] Current Thread [Next in Thread]