I tried to find out why evaluating sin works as expected while
for special functions like Gamma or digamma we get numeric
evaluation by default. I must admit that details are still
unclear for me, but I made one step forward compared to what
is written in issue 130.
Namely, the only exposed declaration of one-argument sin is
in TRIGCAT. Expression Integer, Float and DoubleFloat have
TRIGCAT.
Currently one-argument Gamma have exposed definitions in SPFCAT,
DoubleFloat, DoubleFloatSpecialFunctions, FloatSpecialFunctions.
Expression Integer and DoubleFloat have SPFCAT. Un-exposing
DoubleFloatSpecialFunctions and FloatSpecialFunctions do not
help: after that interpreter picks definition from DoubleFloat.
However, when I did the following:
- removed declaration of Gamma from DoubleFloat (but left definition
there),
- added definition (but no declaration) of Gamma to Float
- declared that Float has SPFCAT
then I got "correct" funcion selection for Gamma: with exact
arguments I got Expression Integer, while for Float and
DoubleFloat I got numeric result.
Unfortunatly, this has bad side effect: after that change
I get:
digamma(2.0)
Internal Error
The function digamma with signature hashcode is missing from domain
Float
that is, interpreter expects to find digamma in Float (after all
I promised this saying that Float has SPFCAT) and returns error
when it is not found.
Now, one possibility is to declare in SPFCAT only functions that
have full set of definitions (symbolic, Float and DoubleFloat)
-- currently only one argument Gamma. Another possibility
is to split SPFCAT into parts, depending which definitions
are available. In fact, without symbolic definition just
declaring functions in Float and/or DoubleFloat works OK
so we need to consider only functions having symbolic
definitions (and adding symbolic definition is easy anyway).
Also, it is easy to produce DoubleFloat version given
one in Float (just round down Float result to DoubleFloat
precision). So we could use three categories: one for
symbolic-only functions, one for symbolic + DoubleFloat and
one for full definitions. If we distinguish between real
and complex versions than the get six variants, but I
would rather only allow functions with complex definitions.
Another possibility is to use different names for numeric
and symbolic functions.
Any thoughts? I must admit that neither of alternatives
looks really attractive for me, but I plan to improve
our support for special functions and some solutuion
is needed (as I wrote we can easily add symbolic definitions,
while numeric support will take more time). Currently
having multiple categories looks like least evil.
--
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
-~----------~----~----~----~------~----~------~--~---
