[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: seul-edu@seul.org*Subject*: Re: [seul-edu] [no longer OT] summation of 1/2x*From*: Jan Hlavacek <jhlavacek@sf.edu>*Date*: Thu, 6 Apr 2000 13:02:04 -0500*Delivery-Date*: Thu, 06 Apr 2000 14:02:11 -0400*In-Reply-To*: <2.2.32.20000405185454.009ae1b8@[192.168.1.23]>; from ray@comarre.com on Wed, Apr 05, 2000 at 11:54:54AM -0700*Mail-Followup-To*: seul-edu@seul.org*References*: <2.2.32.20000405185454.009ae1b8@[192.168.1.23]>*Reply-To*: seul-edu@seul.org*Sender*: owner-seul-edu@seul.org

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/

**References**:**Re: [seul-edu] [no longer OT] summation of 1/2x***From:*Ray Olszewski <ray@comarre.com>

- Prev by Date:
**Re: [seul-edu] It looks like I'm going to learn Python** - Next by Date:
**Re: [seul-edu] Intro** - Prev by thread:
**yacas Re: [seul-edu] [no longer OT] summation of 1/2x** - Next by thread:
**Re: [seul-edu] [no longer OT] summation of 1/2x** - Index(es):