|Multiprecision Integer Math Package email@example.com (1993-09-22)|
|Re: Multiprecision Integer Math Package firstname.lastname@example.org (Dave Gillespie) (1993-09-22)|
|Re: Multiprecision Integer Math Package email@example.com (1993-09-26)|
|From:||firstname.lastname@example.org (Roberto Sierra)|
|Date:||Wed, 22 Sep 1993 07:27:21 GMT|
Hello all --
I just wanted to let y'all know that there is an interesting thread
developing on sci.math which some of you may want to check out and
contribute to. Check out the 'Re: Multiprecision C sources?' thread
to come up do date on what's been discussed so far.
There's a fellow who will soon be releasing a free C++ library to
perform extended precision integer arithmetic. It would allow
phenomenally large integers to be operated on using standard C-like
syntax by overloading all of the arithmetic operators. Here's just
a teeny example (the integers could be *much* larger):
bsint a = "384398349854857384759834758734958374519";
bsint b = "31415925634982429872345023042034982374";
c = a + a/b;
[Full precision result ends up in c.]
This obviously has applications in math, possibly physics and other
sciences where a large number of events might need to be counted,
and to the general C/C++ programming community at large.
The point of this cross-posting is to open up the discussion to a
wider audience and to try and to figure out just what the package should
do and what the target audience might be. Right now, the discussion on
sci.math is slightly biased by the preponderance of mathematicians. Not
that this is a problem, but I'd like to see a wider audience of programmers
make some comments on what they'd like to see.
(1) If you've seen free C++ source for manipulating really large
integers, please let us know -- we've already heard about the
Gnu package written in C (I think it's called gmp?).
(2) There are a number of issues being raised about how the package
should behave, how it should be designed, what it should try and
do and not do, and so on, which you might be able to contribute
significantly to. I would personally like to get feedback from
a fairly diverse crowd since I think the package will ultimately
appeal to a *very* wide audience.
(3) There are some specific nitty-gritty issues currently being raised
about how to evaulate a/b or a%b when a and/or b are negative integers.
ANSI C does not define a standard behavior, and most compilers seem
to evaluate floor(a/b), for example, since this is what most CPUs
return. From a mathematical point of view, this is not necessarily
the most sensible behavior -- you would usually want to round a/b
towards zero. This has raised a number of issues which I think
deserves attention by a wider audience intimately familiar with
software engineering issues, C compilers, and mathematics.
Anyway, please feel free to jump into the fray. Follow-ups to this
thread will go to sci.math, comp.lang.c, and comp.lang.c++. I would
recommend, though, that you post followups to the original thread on
sci.math unless there's good reason to do otherwise. It makes sense
to me to try to keep a 'central' discussion wherever possible, and
that just happense to be where it is right now.
Hoping to hear from you soon!
san francisco, calif.
Return to the
Search the comp.compilers archives again.