From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13813 invoked by alias); 5 Sep 2003 11:36:51 -0000 Mailing-List: contact gsl-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sources.redhat.com Received: (qmail 17057 invoked from network); 5 Sep 2003 08:09:40 -0000 Subject: Re: libevaluator library and GSL From: Alberto Manuel =?ISO-8859-1?Q?Brand=E3o_Sim=F5es?= Reply-To: albie@alfarrabio.di.uminho.pt To: Kenneth Geisshirt Cc: GSL Discussion list In-Reply-To: <3F58429B.7080203@geisshirt.dk> References: <20030904174840.GA67119@daemon.local> <20030905072946.GA287@daemon.local> <3F58429B.7080203@geisshirt.dk> Content-Type: text/plain Organization: Departamento de Informática - Universidade do Minho Message-Id: <1062749699.25098.2.camel@eremita.di.uminho.pt> Mime-Version: 1.0 Date: Fri, 05 Sep 2003 11:36:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2003-q3/txt/msg00239.txt.bz2 On Fri, 2003-09-05 at 09:00, Kenneth Geisshirt wrote: > Aleksandar B. Samardzic wrote: > > >>I'm only speaking for myself here: I'd like to have some of this > >>functionality available, > > Me too. But I don't care whether it's a seperate library or not. > Aleksandar: great initiative. > > >>Could you tell us more about what your evaluator does? How does it > >>compute derivatives? Symbolically or numerically? Does it simplify > >>formulas? Does it look for common subexpressions? > > I wrote a similar library about 10 years ago. Derivatives are not too > difficult to implement, but the expressions become really ugly. Try to > derive sin(x)^cos(x) w.r.t. x to see what I mean :-). I have such a system in Numexp-core (http://numexp.sf.net), but as Kenneth said, derivatives become very ugly. > > Simplifying expressions is a much harder job. Of course you can do > simple things like (x-x) -> 0 and (1*x) -> x but (x+y)-x is not that easy. I am doing some of these simple simplifications. Started writing a better simplifier by patter matching in Perl. It gives some interesting results, but is not a decent way. > > > My library is parsing string and creating tree representation of it in > > memory. > > Tree representation is straight forward but might not be the most > efficient representation. At least in the 1980's and 1990's I believe > that most compilers used DAGs (Directed Acyclic Graphs). The Dragon book > by Aho et al. outlines the algorithms. I am using trees, too! Alberto