Bill Page wrote:
>
> On Wed, Dec 3, 2008 at 8:59 PM, Waldek Hebisch wrote:
> > IMHO we need all of them: algebraic part, symbolic manipulation,
> > logic and numerical computations. Refusing promising approach
> > on ideological reasons would be very wrong precedent.
> >
>
> Ok. I agree that "ideological reasons" alone would not be sufficient
> to argue against any given possible approach. But I am quite convinced
> that one of the strengths of FriCAS (alias Axiom) is the ways in which
> it differs from other current computer algebra systems. For me it is
> the strongly typed algebraic-oriented language of FriCAS that sets it
> apart and makes it of great interest to me. Of course this is viewing
> FriCAS as a research-oriented platform rather than as a merely a tool
> for doing mathematics by computer but I think there are other open
> source options available for simply "doing mathematics by computer"
> that are already significantly more advanced than FriCAS and FriCAS
> has very little possibility to "catch-up" with these developments.
>
I wonder which systems you consider to be "significantly more
advanced" for "doing mathematics by computer"? Besides Axiom
forks I think that the following are serious general purpose
computer algebra systems: Maxima, giac/xcas, Sage. In the
past I have looked at Maxima and my opinion is as follows:
from the user point of view FriCAS is better (more advanced,
more reliable, easier to use). Note in some areas Maxima
is better, in other FriCAS but IMHO average is in favour
of FriCAS. From developement point of view I consider
Maxima as dead end: very hard to read source code, poor
structure with complicated interactions. My impression
is that Maxima has significantly more developers than
FriCAS, but that as the project they move forward not
faster than us. When looking at conditional expressions
AFAIK Maxima has only assertions (which we do not have),
but no conditional expressions -- they are just now
implemetiong piecewise functions (but all I heard
suggest that there are technical problems which
conditional expressions are supposed to avoid).
giac/xcas has some nice functionality
but at least last time when I looked at it it missed
many more advanced functions. AFAIK giac/xcas is essentialy
developed by one person so I do not expect that this
comparison will change much in the future. I do not
know if giac/xcas has conditional expressions. Concering
Sage: currently significant part of general purpose
expression manipulations in Sage is done via Maxima.
My impression was that native Sage capabilities
were significantly below our Expression.
In other words, conditional expressions are used in comercial
system and open source systems need to catch up. From
my point of view FriCAS is in best position to do this.
> > checker is static checking, but actually to benefit from static
> > checking conditions have to be _data_ (because static type
> > checking of types is actually weaker than static type checking
> > of ordinary data).
> >
> >
> > SubDomain nicely illustates this point: because cond is a
> > function typechecker can do nothing beyond checking that
> > cond takes values of declared type and returns Boolean.
> >
>
> I do not see this a limitation of the type system. It seems essential
> and unavoidable to me that FriCAS must be able to evaluate
> Boolean-valued functions that are part of a domain defined as a
> SubDomain at run-time. Could you elaborate on how this illustrates
> your point?
>
We need to simplify conditions. In case of SubDomain cond is
just piece of code and mere checking for equality may be
problematic. When it comes to more complicated simplifications
they work fine if you have symbolic representation of
conditions, but there is no chance to use them on piece of
machine code. As an example: on symbolic level we may easily
observe that one codition implies another one (we may miss may
cases where implication is not obviois, but there is enough
easy cases where we can prove that implication holds). On
machne code level (barring de-compilation and reconstruction
of original expression) there is _no_ way to prove implication.
--
Waldek Hebisch
[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
