
Known bugs:

* General:
  + Does not yet properly handle +inf, -inf in math operations
  + divide by zero throws no exception

* BigFloat:
  + unfinished (fmod() is missing)
  + certain operations (div?) leave $x->{_m} as NaN! Oups! (also BS2000)
  + comparing (<=> or == or !=) a BigFloat to an BigInt does not work yet
  + new is first running the entire number trough _split, then again the parts
    to construct BigInts. Could be a bit more optimzed.
  + fdiv() using F (fallback) mode does not honour local (aka $x's) A settings
  + MBF uses internally MBI for calculating. This can make problems if MBI has
    set global accuracy settings, and thus rounds unexpectedly the mantissa.
    My attempt to fix it stops the following from breaking, but it might not
    catch every occurance:
   
    use Math::BigInt; 
    use Math::BigFloat; 
    $Math::BigInt::accuracy = 4;	
    $x = Math::BigFloat->new(123.456);
    ok ($x,123.456);

  + hexadecimal integers work, but what about '0xABC.DEF'? Really needed?
  
* BigInt:
  + doesn't have a mode akin to 'use integer;', e.g. it always emulates Perl
  + Handling of undef arguments is somewhat broken (no proper warnings)
  + use Math::BigInt qw/0.004/;	does not fail (wrong version)
  + inf handling is not finished yet. Since you normally do not get -+inf, and
    the old code never knew about +-inf anyway, it is very low priority
  + eval('use...') and use Math::BigInt qw/:constant/ fail on Perl prior 5.6.0
    This is likely an Exporter bug, and causes Math::BigInt to eval require on
    earlier Perls when loading the core math lib. Thus the loading can fail on
    filesystems that can not cope with 'Math/BigInt/Calc.pm' style filenames.

Accuracy:
 Any operation encountering the following should result in an error:
  + $x with set A, and $y with set P
  + $x with a different rounding mode than $y

###############################################################################

Mixing of classes does not always work like here:

	use Math::BigInt;
	use Math::BigFloat;

	$x = Math::BigFloat->new(2.5);
	$y = Math::BigInt->new(2);

	$z = $x + $y;

What should $z become? Certainly not a BigFloat with value 4. But a BigFloat
with value 4.5? Ora BigInt with value 4? And should

	$z = $y + $x;	# reversed order

influence the result? Overload works this way with scalars, the first object
gives the class to that the result is set and the second argument is converted:

	$z = $x + 2;	# 4.5
	$z = 2 + $x:	# 4.5
	$z = $y + 2.5;	# 4 !!

One problem is that in normal Perl floating point is prefered, when in doubt.
But this assumes that MBI knows about MBF and that MBF is considered more
"powerfull", so that MBI objects promote themselfe to MBFs upon contact:

	$z = $x + $y;	# 4.5
	$z = $y + $x;	# 4.5, too

While this could be made to work somehow, the assumption that MBI must know
anything about MBF (a subclass of it) is somewhat ugly. (Of course having a
routine in both packages, that return 1 for MBI, and 2 for MBF, thus denoting
the more powerfull would work, and even with subclasses of MBI, which inherit
than the 1, or override it (maybe even with 3 for complex numbers)).

The old code (v0.01 etc) breaks in various, mysterious and strange ways when
confronted with mixed arguments, but for others it works by suprise. For fun
throw t/mbimbf.t at the old library.

My new code is only partially better, I am afraid.

Please send me test-reports, your experiences with this and your ideas - I love
to hear about my work!

Tels <http://bloodgate.com/>
