> 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.
>>
>> Ring operations are easy:
>>
>> [c_1, e_1],...,[c_n, e_n]] op [[c'_1, e'_1],...]
>>
>> is the list
>>
>> [c_1 and c'_1, e_1 op e'_1], [c_2 and c'_1, e_2 op e'_1],...]
>>
>> that is we logical and all pairs of conditions and perform
>> operation on corresponding expressions.
>
On Mon, Dec 1, 2008 at 8:10 AM, Martin Rubey wrote:
> But this will give a huge mess...
> ...
On Mon, Dec 1, 2008 at 8:10 AM, Martin Rubey wrote:
> Well, what is a suitable language for conditional expressions to
> get this started? Actually, it might be worth to have a domain
> for conditional expressions...
>
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. Maybe what you are suggesting
could be represented by a domain for piecewise defined functions.
Something like this is already possible in the interpreter:
(1) -> f:Integer->Integer
Type: Void
(2) -> f(x|x>0) == 1
Type: Void
(3) -> f(x|x<0) == -1
Type: Void
(4) -> f(x|x=0) == 0
Type: Void
(5) -> f
(5)
f (x | 0 < x) == 1
f (x | x < 0) == - 1
f 0 == 0
Type: FunctionCalled(f)
--
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!
In general functions defined in the FriCAS library should always be
total over their domains. E.g.
g:Integer->Integer
should have a well-defined value for all values of Integer and not
generate any run-time exception. This philosophy would mean that
operations like
/:(Integer,Integer) -> Fraction(Integer)
in Fraction(Integer) are not properly defined in the present code. It
seems that there is a need for a subdomain of Integer that might be
called for example NonZeroInteger, similar to PositiveInteger and
NonNegativeInteger.
/:(Integer,NonZeroInteger) -> Fraction(Integer)
Probably it also makes sense to have NonZero(S:IntegralDomain) as a
domain constructor in it's own right.
/:(S,NonZero(S)) -> Fraction(S)
/:(%,NonZero(%)) -> %
Ideally subdomains should interact with Union so that for example we
would have the following type equivalence:
PositiveInteger = Union(Zero(Integer),NonNegativeInteger)
However the current implementation of Union in FriCAS is rather
"brain-dead" in several ways. There are two different forms - one with
"labels" and one without, but neither of these forms can deal with
having the same domain occur more than once, e.g.
(1) -> )sh Union(Integer,Integer)
Union(Integer,Integer) is a domain constructor.
------------------------------- Operations --------------------------------
?=? : (%,%) -> Boolean autoCoerce : % -> Integer
autoCoerce : Integer -> % autoCoerce : Integer -> %
?case? : (%,Integer) -> Boolean ?case? : (%,Integer) -> Boolean
coerce : % -> Integer coerce : % -> Integer
coerce : % -> OutputForm
(1) -> )sh Union(A:Integer,B:Integer)
Union(A: Integer,B: Integer) is a domain constructor.
------------------------------- Operations --------------------------------
?=? : (%,%) -> Boolean ?case? : (%,A) -> Boolean
?case? : (%,B) -> Boolean coerce : % -> OutputForm
construct : Integer -> % construct : Integer -> %
?.? : (%,A) -> Integer ?.? : (%,B) -> Integer
Unions of this kind would allow one to implement "multi-valued"
functions in a manner that is analogous to the method of "Reimann
surface". Union provides the means to "glue" domains together like
neighborhoods in a manifold. The injective maps of the Union are just
like the "charts" of a manifold. So for example 'sqrt' would be
defined as a multi-valued function like this:
sqrt:Union(principal:Float,nonPrincipal:Float)->Float
There is a natural coercion of Float into the "principle branch" of
the Union. So just as now
sqrt(4.0) == 2.0
but the non-principle branch(es) should also be accessible
sqrt(nonPrincipal 4.0) == -2.0
Similarly log and inverse trigonometric functions can be defined over
a Union indexed by the integers.
Regards,
Bill Page.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
