Bill Page wrote:
>
> > Waldek Hebisch writes:
> >> I am not sure if it is obvious, but I had this in mind when I wrote
> >> about conditional expressions. However, I think that name "conditional
> >> expression" is better -- when Tim wrote about provisos he was short
> >> on details but he indicated possible implementation technique
> >> which IMHO is not practical. OTOH conditional expressions are
> >> used by other systems (I am not sure the name is accepted one).
> >
> >> Martin Rubey wrote:
> > Yes. I used "provisos" (under quotation names) only to make archive
> > search easier.
> >
>
> Although something like this has been done in other computer algebra
> systems I am not convinced that implementing "provisos" or any other
> type of "conditional expression" is a good direction for FriCAS.
> FriCAS is fundamentally a strongly-typed *algebraic* system but it
> seems to me that the concept of conditional expressions leads in
> another direction involving symbolic manipulation and logic.
>
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.
> It seems to me that just having conditional expressions is not enough.
> In evaluating conditions it is necessary to know which symbols are
> parameters and which are constants.
What is the difference between constant and parameter? AFAICS
there is no need to distinguish unknown constant and a parameter.
> Maybe what you are suggesting
> could be represented by a domain for piecewise defined functions.
> Something like this is already possible in the interpreter:
>
> It seems to me that a better direction for FriCAS would be to insist
> that this sort of logic remain part of the *type system* of the
> language rather than as values in some new "conditional expression"
> domain. I believe that this was one of the original motivations for
> the concept of the "SubDomain" constructor:
>
> SubDomain(T:SetCategory,cond:T->Boolean)
>
> There is already partial support for this in the FriCAS compiler.
> SubDomain is currently used in the definition of PositiveInteger and
> NonNegativeInteger but these are the *only* places where it is used in
> the FriCAS library. The current implementation of SubDomain in the
> compiler seems incomplete. Notice that the second argument to
> SubDomain is a function that returns a Boolean - not an expression!
>
Conditional expressions are realistic approch: possibly as little
as a week of coding can give useful implementation. Using type
system for this is a speculation and even at level of speculation
is not very promising. Namely, one reason we need conditions is
that we our mathematical algorithms are too weak to give
unconditional answer. The other is when result have "discontinuous"
dependence on parametes -- more precisely result can not
be captured by single formula. Both reasons means that conditions
are runtime thing and as we refine implementation we will want
to use deep mathematical knowledge to handle them. OTOH our
types are quite heavy at runtime and type checker has only
little mathematical knowledge (basicaly rather simple minded
support for propositional calculus). Strength of type 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.
--
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
-~----------~----~----~----~------~----~------~--~---
