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. Important too 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. Algae is not designed to deal with non-finite (INF & NaN) floating point numbers -- instead it expects to catch the exceptional conditions that generate such numbers when they happen. One of our challenges has been in dealing with the variety of responses we get from different math libraries. For example, `log(0)' quietly returns -INF on some systems, sets `errno' on others, and raises a divide by zero exception on still others. 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".) By the way, the file names in that directory are really lame, and I ought to fix that. For example, "i586-unknown-linux.c" worked on a Linux 1.2 system, while "i686-pc-linux-gnu.c" is for a Linux 2.2 system. Whether it's an Intel 586 or 686 makes no difference at all. 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. 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". You'll wind up getting "inf" values in your results. This is serious, though, because the Fortran sections of the code will really mess up in that case. 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 Intel Itanium II ---------------- The g77 compiler (version 3.3) seems to have a problem with the LAPACK routine DLALN2 with -O2 optimization. That's about all I know, except that it seems to work fine with -O optimization. IBM RS/6000 ----------- The "malloc" and "free" library routines are remarkably slow, at least on an AIX 4.3 system I worked on. As a test, I linked with Doug Lea's dlmalloc package and saw times reduced by a factor of 10 for some cases. This may be worth considering, but I haven't really explored it enough to be able to recommend it. It probably isn't worth worrying about for most uses of Algae, but some of Algae's timing tests do run in about half the time with dlmalloc. Alpha (HP, DEC, etc.) --------------------- On an older (OSF/1 V4.0) machine, I haven't had any luck getting Algae to use the optimized BLAS routines in the DXML library. (But I haven't tried very hard.) The configure process tries to use these by default. The problem seems to be with the run-time linker. Instead, I just gave the "--without-blas" option to configure and accept the inferior performance of the non-optimized "reference" BLAS routines that are distributed with Algae. An old DEC compiler that I've used (DEC OSF/1 AXP Compiler 3.11) had 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. It seems to have been fixed by v. 5.9 of that compiler. Expect the trap tests to complain about sloppy range errors. You may also get a complaint about sloppy divide by zero handling -- the Alphas that I've used signal overflow when they 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 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. The HPUX math libraries have some funny ideas when it comes to range and domain errors. For example, `log(0)' returns -INF (or -1.798e+308 on some machines) but it should also set errno to ERANGE. 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 a variety of sloppy error messages. Linux ----- Of all the operating systems that I've compiled Algae on, Linux has given me the least trouble by far. There were a few problems with error handling in early versions of the math libraries, but we're way past that now. You can expect the trap tests to complain about sloppy handling of overflow and divide by zero. I'm not sure what's going on (as of 31 August 2001), but I've had problems with the LAPACK and BLAS packages distributed as RPM files by Red Hat. The symptoms involve raising a floating point exception for no apparent reason. If Algae is linked to these libraries and it fails its tests (especially "eig_test"), configure it instead with the "--without-blas" (and perhaps "--without-lapack") flags. This will cause Algae to use its own code in their place. SGI --- Expect the trap tests to complain about 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 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. The native `make' may have problems. You should use GNU make. Expect the trap tests to complain about 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 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.