axiom-developer
[Top][All Lists]
Advanced

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

RE: [Axiom-developer] Re: Defining piece-wise functions and drawing, int


From: Bill Page
Subject: RE: [Axiom-developer] Re: Defining piece-wise functions and drawing, integrating, ...
Date: Sun, 3 Jun 2007 18:22:59 -0400

On June 3, 2007 4:56 PM Ralf Hemmecke wrote:
> ... 
> >> Agreed, but what about telling Axiom the following:
> >>
> >> (1) -> g(x)==if x>0 then x else -x
> >>                                  Type: Void
> >>
> > 
> On 06/03/2007 07:44 PM, Bill Page wrote:
> > I think this is equivalent to writing:
> > 
> >   g(x|x>0) == x
> >   g(x|x<=0) == -x
> > 
> > As far as I know the difference is only a matter of style.
> 
> Since that function definition is only possible in the 
> interpreter (SPAD  would have to figure out some reasonable
> types at compile time, and Aldor would forbid such typeless
> things altogether), you may be right.
> 
> But, actually, who tells you that > and <= are "opposite"
> things?

True. I said "equivalent" but very likely the object code
generated when the functions are compiled is not identical.

> ... 
> >> As I see it, we are a bit in a dilemma here. We need the
> >> function expression here and at the same time > should be
> >> considered as something like (Float, Float) -> Boolean.
> >>
> > 
> > I think we really need a class of fuctions > with signatures
> > like:
> > 
> >   > : (Expression Integer, Expression Integer) ->
> >         Union(Expression Integer, Boolean)
> 
> I think that would make things more complicated.

You are right. That was a poor suggestion.

> 
> > Then 'x<0' can be treated as an expression of type
> > Expression Integer just like 'sin(x)'. Or more generally
> > we need a domain of predicate expressions which can interact
> > with other domains like Expression.
> 
> Yep. I like to see a true expression domain. Axiom's 
> Expression(..) is rather special. It covers a lot, but its
> inhabitants are not expression trees. They are rational
> functions.

That is true but I think that there is a good reason for
this - part of the "Axiom philosophy". The mathematical
domains that we define should always be as "algebraic" as
possible.

> ...
> 
> Then writing "Expression BooleanRing" is probably also not
> what you want. At least I don't want it.

No 'Expression BooleanRing' is definitely not what I want.
'Polynomial BooleanRing' was just an exercise in one way to
provide boolean expressions. Really of course what we want
is a conventional free boolean algebra.

> ... 
> > If we had a domain for predicate expressions then it would not
> > be difficult to introduce an expression in Expression of the
> > form:
> > 
> >   piecewise(Cond:Expression Boolean,
> >             Then:Expression Integer,
> >             Else:Expression Integer):Expression Integer
> 
> Well, what I would dream of is an expression domain (or 
> several of them) that lets you define a general expression
> tree where you would have control over what is allowed as
> nodes. Maybe it would be interesting to be able to give a
> grammar G and MyExpression(G) would then describe the 
> language generated by G. It would be nice to be able to 
> encode the Aldor language in that way.

For Axiom this does not seem sufficiently "algebraic" to me.
Axiom does not like to work with things like "general
expression trees", or rather it does already very nearly
have such things, e.g. SExpression, but they are considered
rather low-level compared to the usual mathematical objects
with which one is expected to work.

> 
> You all probably know that everything in Maple is an 
> expression also "if a then b else c fi" and that one can
> compute with these things. (Yes, yes, looks again like the
> Maple language is nothing but Lisp with another syntax. ;-) ).
>

I think it is quite deliberate that Axiom is different from
Maple in this regard.
 
> Aldor's LibAlgebra defines a domain ExpressionTree. But that
> is certainly not yet perfect.
> 

I think of this as a more sophisticated replacement for
SExpression.

Regards,
Bill Page.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]