
Here are some problems that we've encountered with Algae on various
systems. If you solve any of them (or have additional information),
please let us know.

GENERAL PROBLEMS

One of the basic design decisions that we made with Algae was that
exceptional conditions such as overflow, division by zero, and other
range and domain errors should immediately stop execution.  More
important to me than the specific behavior, however, was that it be
consistent across computer platforms.  Naively thinking at the time
that most systems adhered to a small number of major standards (such
as IEEE 754), I had no idea how difficult this consistent behavior
would be to obtain.

Before I get too carried away, I must admit that I'm still no expert
in this area.  I've seen enough, though, to be pretty unhappy with the
current state of affairs.  I have yet to see a machine pass our "trap"
tests with no complaints.

Below are the exceptions that Algae is supposed to trap, and some of
the problems I've encountered.  The tests referred to are those run by
"test/trap_tests".  Algae's code to enable and handle these exceptions
is implemented (or not) in the appropriate file in the "fpe"
directory.  (I refer to this file as "fpe.c".)


integer overflow
----------------

    Although many machines claim they can signal this, I've never seen
    one that actually works.  That means you get stuff like

        > 2000000000+2000000000
		-294967296

    I suspect that they'd take a performance hit if they really did
    trap integer overflow, so they may be wise in not doing it.
    Still, they shouldn't waste my time by claiming that they can.

    Unfortunately, it's easier to encounter integer overflow than you
    might think.  If you think your numbers might get large, use real
    numbers instead of integers.  For constants, use a decimal point;
    otherwise, use the function "real".

floating point overflow
-----------------------

    If this isn't trapped, it probably just isn't implemented in "fpe.c".


floating point divide by zero
-----------------------------

    I never dreamed that this one would be a problem.  If it isn't
    trapped on your system, hopefully it just isn't implemented in
    "fpe.c".  However, I read a man page on an HP 9000/715 that
    claimed that floating point division by zero does not raise an
    exception "as defined by the IEEE POSIX Standard".  That's not
    right.  The DEC Alpha that I've used never signals divide by zero;
    it signals overflow instead.

range and domain errors
-----------------------

    The ANSI standard for C specifies that math library routines like
    `exp' and `log' indicate range and domain errors (like `log(0)')
    by setting the global variable `errno'.  Better yet, some systems
    call the function matherr(3) on such errors.  It's pretty common,
    though (when floating point exceptions are enabled), to actually
    get a "divide by zero" or "overflow" error instead.  This warrants
    a "sloppy" accusation by the "trap" tests.  The math library on
    our Titan machine doesn't signal any errors at all!

SYSTEM PROBLEMS


dec alpha
---------

    The DEC compiler that I've used (DEC OSF/1 AXP Compiler 3.11)
    seems to have a bug that prevents it from compiling
    "src/subtract.c" correctly with optimization.  The symptom is
    failing the math tests with a "memory fault".  If you have the
    same trouble, try compiling with the -O1 option for that one file.

    Expect the trap tests to complain about integer overflow and
    sloppy range errors.  You may also get a complaint about sloppy
    divide by zero handling -- the Alpha that I've used signals
    overflow when it should signal divide by zero.

apollo
------

    Installing Algae on the poor old Apollo isn't too hard, but it's a
    bit more work than on most machines.  Most of my experience is
    with a DN3500 running DomainOS 10.3.5.  Here are a few things you
    may run into:
    
      1.  The native `make' may have problems, getting part way through
	  and then just quitting.  I had to compile the rest of it
	  manually.  You might try getting GNU make.
    
      2.  On one machine, the C compiler made some bad mistakes.  I've
          hacked in some workarounds that seem to take care of it.
    
      3.  I think you could probably get much better performace by
	  compiling with the appropriate "-A" option.

    Expect the trap tests to complain about integer overflow and
    sloppy range and domain errors.

hpux
----

    I find hpux very difficult to work with, and I avoid it if
    possible.  If HP is trying to discourage software development on
    their machines, then they're doing a great job.  For a while I
    tried to maintain binaries compiled with c89, their ANSI C
    compiler.  I finally gave that up, though, because the required
    compiler options changed with every release.  I even had trouble
    getting gcc working on hpux 10!

    I wish that someone could explain to me why we fail to catch
    domain errors on this machine.  For example, `log(0)' should write
    an error message and raise an exception -- instead it returns 0.0.

    Version 9.01 of hpux appears to have had a major bug in cpp which
    prevents it from compiling Algae.  You should either use gcc or
    upgrade to a newer version of cpp.

    Also expect the trap tests to complain about integer overflow and
    a variety of sloppy error messages.  With a little work, we could
    probably clean up some of the sloppy messages.

linux
-----

    Of all the operating systems that I've compiled Algae on, Linux has
    given me the least trouble by far.  There was a problem with error
    handling in the math library (as of version 5.1.18), but that
    should be fixed in upcoming versions.  Also, Linux can't yet
    distinguish between the various floating point exceptions (overflow,
    divide by zero, etc.).
    
    You can expect the trap tests to complain about failing to trap
    integer overflow and sloppy handling of overflow and divide by
    zero.  Until the math library gets fixed, you'll also see sloppy
    handling of range errors and failure to trap domain errors.

sgi
---

    Expect the trap tests to complain about integer overflow and
    sloppy range and domain errors.

sun (sunos 4.1)
---------------

      1.  The Fortran libraries that `configure' sets in "src/Makefile"
          may take some tweaking for your system.  For one thing,
          "-lI77" is required on some systems but must be removed on
          others.
    
      2.  Expect the trap tests to complain about integer overflow and
          sloppy range and domain errors.

sun (solaris 2.*)
-----------------

    The native C compiler gives dozens of lovely messages like
    "semantics of < change in ANSI C".  You can ignore them.

    Expect the trap tests to complain about integer overflow and
    sloppy range and domain errors.

titan
-----

    The C compiler (release 4.2 beta) on our Titan 3000 has a bug that
    prevents it from correctly compiling "src/dense.c",
    "src/sparse.c", "src/parse.c", and "src/matio.c" with O2
    optimization.  If you get them compiled and the resulting
    executable passes its tests, then you're all set.  Otherwise,
    compile those four files with O1 optimization.
    
    You can expect an enormous number of warning messages from both
    the C and the Fortran compilers.  Some of these are for things
    that we've been a bit sloppy about; many more are because the
    compilers are way too picky.  Ignore them and hope for the best.
    
    I know it sounds stupid, but for exception handling to work
    correctly, you must have the environment variable USE_DEFAULT_SIG
    set to 1.

    A bug (I'm guessing that it's in the Fortran compiler) prevents
    using the execution profiler.  It appears to work, but the Fortran
    routines tend to give wrong answers when interrupted.
    
    Although the Titan documentation claims that integer overflow can
    be trapped, it doesn't work.
    
    Also, the math libraries do not follow the ANSI C standard with
    regard to domain and range errors.  This means that the return
    values may be "inf" or "NaN".  For example, `log(0)' returns
    `-inf'.  This is a problem, because much of the code in Algae can't
    accept "inf" or "NaN" numbers.  For example, the function call
    `svd(log(0))' will never return.

ultrix
------

    Don't use execution profiling unless you want to see a serious
    operating system bug in action.  (Well, maybe it's just Ultrix
    4.2.  Try it at your own risk, though.)  This seems to have been
    corrected in Ultrix 4.4, but an interesting thing happens: floating
    point results are sometimes slightly different from run to run
    when the profiler is active.

    My version of the BLAS library supplied with Ultrix has a bad
    IZAMAX, causing Algae to dump core in the "solve" test.  I just use
    the BLAS library that comes with LAPACK.  I think this was also
    corrected in Ultrix 4.4.

    Expect the trap tests to complain about integer overflow and
    sloppy range and domain errors.  Integer overflow trapping is said
    to work but doesn't.

    I'm used to seeing sloppy handling in the math libraries, but our
    ultrix versions have some flat-out bugs.  For example,
    `atan2(1;0)' yields a "divide by zero" exception.  Again, this
    seems to have been corrected in Ultrix 4.4.
