Boost logo

Boost :

From: Daryle Walker (darylew_at_[hidden])
Date: 2000-10-23 20:34:30


A little while ago, I posted version 9 of "dlw_oprs.zip" to the vault. It
contains improvements based on discussions when I tried to get version 8
entered. Has anyone checked the new version for approval?

I added a little sub-library for math stuff. It is called "more_math.zip"
in the vault and is currently at version 3. (I re-implemented the 'sgn_mag'
class from version 2.) It has:

- Imaginary numbers. They complement the standard complex numbers. I read
some stuff on the Internet from mathematicians stating that keeping results
as pure reals or pure imaginaries as long as possible is better than merging
them together as complex numbers for the whole calculation. Separation
keeps mismatched magnitudes of reals and imaginaries from corrupting each
other in certain operations. The class also honors the imaginary number
stuff introduced in C-1999. The (template) class has the same interface as
std::complex.

- Miscellaneous operations. It's the little things that probably don't
deserve a whole header file for themselves. It has a generalization of the
integral divide/modulus operations. The specializations for 'int' and
'long' use the operations from <cstdlib>. This system uses an intermediate
computation class. This class is made to be specialized for types that can
efficiently compute quotients and remainders simultaneously. Similar to the
Boost header "iterator.hpp" centralizing the namespace madness with the
std::iterator class, the general header tries to do the same for the
std::abs function. It contains a general template version for any numeric
type, and specializations for 'int,' 'long,' 'float,' 'double,' and 'long
double' that use the standard functions from <cstdlib> and <cmath>. Boost
headers that already try to solve namespace madness with std::abs, like
"rational.hpp," probably should remove their version in deference to this
version if this sub-library is approved (except for specializations of
boost::abs, of course). Maybe the LCM and GCD functions from "rational.hpp"
should move here too.

- Sign-magnitude numbers. This (template) class is what I was asking about
in the "Question on implementing two slightly different versions" thread.
It passes operations through for already-signed numeric types. But it
adapts unsigned types to be signed. I guess it can be used to add a signed
version of an user-defined unsigned numeric type.

Future plans (in order of planning and likelihood of doing):

- Generalized numeric I/O. When I was working on my bitint class
("bitint.hpp" in the vault), I realized that all numeric types conceptually
have the same I/O characteristics (based on the current locale), independent
of their internal representations. So instead of making complicated
locale-compliant I/O for each one of my numeric types individually, why
don't I move all that stuff to separate (template) functions. Since these
functions need a lot of stream and locale crap that the numeric type doesn't
need, I'll probably make a "*_fwd.hpp" header. Question: I could do this
for integral types by using DIV and MOD operations to get the digits, but
how can I implement this for floating-point types, including user-defined
ones?

- School-boy (or -girl) arithmetic algorithms. Reminisce about how you
learned how to add, subtract, multiply, and divide in elementary school.
Possibly include square roots, and maybe higher roots. Make two versions,
the main version assumes that the radix value and all intermediate results
can be represented by the base numeric type. The other version works
assuming that only the values 0 through (radix - 1) are guaranteed to be
representable. Mainly for fun (since no sane numerical programmer uses
these; they use other algorithms that are more efficient, but are nearly
incomprehensible).

- Big ints (and maybe floats and fixeds). Arbitrary radix. Could use the
school-child algorithms.

Comments or suggestions?

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk