[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [seul-edu] [no longer OT] summation of 1/2x
On Wed, Apr 05, 2000 at 11:54:54AM -0700, Ray Olszewski wrote:
> Actually, this gets me thinking again about Brian's original question --
> what language is best for doing mathematical demonstrations? I think we all
> (me included) answered this question with too little thought about the
> specific needs of mathematics.
It is not even clear what are the specifics of mathematics. Do you want
something that will quickly crunch large amount of numbers, possibly
with as good precission as you can get? Do you want something that will
do symbolic manipulation? A language that will help you learn how to
think as a mathematician? A language that will help you understand
basic concepts of mathematics? A language that you can use for
simulation, to verify that your mathematical models are correct? I
could probably go on like this for a while.
Also, do you want a language that a researcher would use, or a language
that is best for teaching and learning?
I am not an expert on programing languages, but I have used couple of
them over the years. And I know a little bit about math, and I was
always interested in the connection of mathematics and programming.
Here are my impressions. There are nothing more than that: impressions.
I would be very glad if somebody disagrees with them, thus giving me a
chance to learn more.
For number crunching, the traditionally used language is indeed FORTRAN.
But my impression is that the main reason it was always preferred over c
was that it had a very strict standard, namely in number precission,
rounding and so on. So you could be sure that even if your calculations
involved rounding errors, these errors will be the same on every
machine, with every FORTRAN compiler, with all possible libraries and so
on. Every c compiler does rounding differently, and even the same
compilers on different machines work differently. Over the years people
developed enormous amount of numerical libraries for FORTRAN, and
existence of these libraries are usually quoted as the main reason why
FORTRAN is still used today.
I don't think it would be very good idea to teach FORTAN as the first
language, even if _number crunching_ is your (or your students's) main
goal. There is plenty of other languages that are good for number
crunching. For learning (but also for research) I would probably use
Octave (http://www.che.wisc.edu/octave), S-Lang (http://www.s-lang.org/),
APL, maybe Gnu R. I am sure there is much more interpreted number
crunching languages.
For symbolic manipulation there is whole lot of high quality commercial
software, but open source software in this area is rather scarce. There
is maxima, something called jackal, but I have never tried that.
I believe that learning any programming language is going to enhance
one's ability to think like a mathematician. However, I think that some
of the languages are "more eqaual" than the others. I would say that
any of the Lisp family (lisp, logo, scheme) are especially suited for
this purpose. One reason is that they heavily utilize recursion.
Recursion may be (and indeed it is) viewed by some as a poor programming
practice, some people say that it is more efficient to write loops,
rather than recursive algorithms. Others disagree, but that is not the
point here. We do not talk about language for "software development"
class, we are talking about math. And recursion is one of the most
important tools in mathematics. Just look how many algorithms used in
math are recursive in nature. Sure, you can code them as loops, but
that is not the way mathematicians usually think about them.
Other great thing about the lisp familly languages is that they
encourage functional programming, which seems to me fairly close to the
way math works, too.
Finally, most lisp family languages do not make any distinction between
data and code, and neither does math. In math, you can have a function
which takes arays of sets of functions and maps them to something else,
which can be as simple as numbers, or as complicated as subcategories of
the category of Banach spaces :-), and you can use mathematical aparatus
to prove things about mathematical proofs and theories. In mathematical
programming language, I think it is fairly important to be able to take
a function and pass it as an argument to another function, which in turn
will return yet another function, based somehow on the first one. And
when I say function, I mean function, not a pointer to it, or a string
containing its name. Function as an object, as a piece of data. this
is the way it works in scheme, ISETL, maple. It works that way in
python, too, except that there is a little trick you have to use when
you define a function inside other function and you want it to see a
local variable.
I could go on, write more about ISETL and so on.
(deleted)
> So ... does anyone know if ANY of the languages we've collectively suggested
> handles these problems well? I do know that perl has BigInt and BigFloat
> packages that are said to handle arbitrarily-large precision. I've actually
> used BigInt, and (except for speed) it works fine with 100+ digit integers.
> I haven't used BigFloat.
There is several languages that handle arbitrarily large precission.
Some dialects of lisp, I believe, the language that Genius calculator
uses, for example. Other languages provide support for exact rational
numbers (MzScheme). I believe Maple and Mathematica have both. The
question is: does it help? Mybe you can get more precise estimate for
the sum if the sum exists, but that's all. Does it help if the sum does
not exist? I think it is better to work around it. Try to find the
sum using single precission, and than again using double precission, and
compare the results. Did it change a lot or just a little? You can
play with things for a little while like this, try to figure out what's
going on and why.
--
Jan Hlavacek (219) 434-7566
Department of Chemistry Jhlavacek@sf.edu
University of Saint Francis http://www.sf.edu/Jhlavacek/