The word you're thinking of is
teetotal.It's an adjective that describes one who does not drink. It is a pun, since I prefer tea to alcohol (though I've decided a cup of cider from time to time is okay, too).
There are two aspects of MATLAB EXternal interface (MEX) programming that cause
most of your headaches. First: when you use the mex script, the compiler flags
are set in such a way that most of the warnings are turned off. This is bad mojo.
Where possible, put most of the functionality for your program into a separate
file, so that you can compile it to object files (and perhaps even link it to
a testing stub) without testing mex. Then use mex to link everything
together. Second: mex creates dynamically loadable modules, and some of the
dependency checks for those modules are not performed until load time or (if
you're on OS X) possibly even until the unlinked routines are hit at run time.
That's why you get errors about
invalid mex files.Check the order of the libraries on your link line, and check to make sure you have all the libraries you need.
You don't want to write your own eigensolver, LU factorization routine, etc.
Not in C++, not in C, not in Fortran. For dense numerical linear algebra,
go look at LAPACK and a
good BLAS implementation
(BLAS = Basic Linear Algebra Subroutines). If you're writing in C++, and you
have trouble linking to a Fortran code like LAPACK, make sure you use the
Cdirective in order to turn of the C++ compiler's name-mangling. If you're writing in C on most Unix-y platforms, you can call Fortran code by simply appending an underscore; e.g. call dgemm_ from C instead of dgemm. Of course, this is somewhat platform dependent. There is a C translation of LAPACK, which I was responsible for a while back, but I think it's worth the effort of learning to link to Fortran. Still, you might also check out the other packages on Netlib, to see if any of them fit your needs.
For large, sparse systems, you'll
want something different from what you use for dense stuff.
I use Tim Davis's UMFPACK system for sparse linear
solves, and ARPACK for computing eigenvalues of sparse matrices.
- When I wrote before about tensors and duality, the code was there purely for illustration. It is not how I would typically structure a computation, or at least it's not how I'd structure it if I wanted to run something big in a reasonable amount of time. You might check out the Matlisp bindings if you're interested in something serious.
Am I really so pessimistic about my code? For those searching on
crash,check out Valgrind. This tool will help you. It surely helps me.
- If you really are interested in code to do number-theoretic computations, check out Magma, Maxima, or perhaps Mathematica or Maple. If you want to crunch numbers, consider MATLAB, Octave, or perhaps R. There exist C++ number theory libraries, but I'm not sure how much use they'll be (unless you're trying to write a distributed code-cracking system or something -- in which case it's already been done, and you should probably use existing sources).
- For information on the Euler totient function, the lengths of repeating fractions, or a variety of other such things, I refer you to Eric Weisstein's Mathworld.
- If you want a Lisp lexer generator or LL(1) parser generator, you can grab one from my software page. But for the parser generator, you may prefer something that handles LALR grammars, and for the lexer -- why bother?
Wednesday, September 28, 2005
Frequently searched questions
Posted by David at 6:44 PM