Martin Rubey wrote:
>
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> > 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.
>
> Still, I think that these two packages should be unexposed, after all these
> functions *should* be accessible via the domains DFLOAT and Float.
^^^^^^^^
That is actually tricky question: packages like DoubleFloatSpecialFunctions
or FloatSpecialFunctions exists exactly to allow adding functions
without modifying DoubleFloat or Float, more precisely adding
functions without directly or indirecly adding them to list of
exported functions. Interpreter has special logic to find
"associated packages" and look for functions there.
This works well if we want purely numeric functions. Unfortunatly,
as we see there is a conflict with symbolic versions.
Currently we probably do not have any function which is numeric-only,
but I can not exclude one in the future. So in short term
we should unexpose those packages, but remember that we may
need a new one for purely numeric case.
BTW: There are bootstrap problems if we put implementation in
packages. For DoubleFloatSpecialFunctions it works, but
for Gamma in FloatSpecialFunctions ATM I am unable to reuse
definition and just gave a fake one in Float.
> (If I'm not
> mistaken, only hypergeometric0F1 is currently not in SPFCAT, although
> implemented in DFSFUN. Shouldn't that be in SPFCAT, too?)
>
IIRC we miss symbolic implementation here (should be easy to fix).
> > However, when I did the following:
> > - removed declaration of Gamma from DoubleFloat (but left definition
> > there),
>
> I think, this should be done in any case. I think it's a very bad idea to
> declare functions that are inherited anyway (also if it's only to override --
> usually: specialize -- the documentation string).
>
> > - 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.
>
> Actually, I think this side-effect is not so bad. After all, it is a bug:
> digamma should be implemented...
>
> > 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.
>
> I think it would be better to proceed as follows:
>
> * set up a proper design which domains should have (in an ideal world) which
> categories (i.e., Float should have SPFCAT)
>
I am affraid that our notions of "proper design" differ. Namely there is
a lot of special functions and every year new one get some attention.
So proper design must allow easy adding of new functions. Some special
functions neatly fit into larger families (holonomic and differentially
algebraic giving a notable example of such families) but many are
really special -- they essentially form a category in itself.
Given richeness of special functions we must accomodate reality that
large part of them will be unimplemented and that implemented part
will be somewhat like a random sample.
Also, as theory advances new properties and consequently new categories
will gain significance.
So, I think that should _not_ define categories early in advance, rather
add them when needed. In short therm using SPFCAT as container
for all special functions looks reasonable for me.
One thing is clear: in ideal world all special functions would have
both numeric and symbolic implementation. Also, classical special
functions are holomorphic, so they would have corresponding Taylor
series expanders. So Expression Integer, Float, DoubleFloat and
series domains would essentially have the same set of special functions
-- the difference beeing that in Float and DoubleFloat we may have some
non-holomorphic functions (abs beeing the simplest example).
Note that a gven function may or may not have expansion belonging
to given series domain. I am affraid that type system is too
weak to accurately state neccessary conditions -- raising error
in impossible cases seems to be right approach here. Also, currently
we get series by explicit action, so we do not have problem
with function selection for series domains.
> Packages whose functionality is provided through domains should certainly be
> unexposed. (and in exposed.lsp, we should write, in the "hidden" section
> for
> example:
>
> (|DoubleFloatSpecialFunctions| . DFSFUN) ; functionality provided by DFLOAT
>
> I think this is important, since we had already some hassle with exposed and
> unexposed packages. (it was PartialFractionPackage, I think.)
>
If all functionality is provided elsewhere a package certainly should
be unexposed. But ability to provide some functionality _only_ via
package may be usefull (assuming we avoid bad effects on function
selection).
> by the way: it may make sense to check which constructors in exposed.lsp
> actually exist:
>
> (|FloatSpecialFunctions| . FSFUN)
>
> does not...
>
Do you have up to date version? I added FloatSpecialFunctions before
1.0.3 release.
> * write dummy implementations for those functions, where you do not have the
> time to do something proper, i.e., in Float
>
> digamma x == error "digamma$Float is not yet implemented, use
> digamma$DoubleFloat."
>
>
> I do not see any bad side effects this way.
>
Given that single precision numeric routines are much easier to
find than multiple precision versions we may have many cases like this.
And certainly it is rather unfriendly to give error instead of
choosing DoubleFloat version automatically. Note that returning
DoubleFloat result conveted to Float is bad, because it would
give false impression of higher accuracy -- when we have lower
accuracy we want the result to have DoubleFloat type to inform
the user about it.
--
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
-~----------~----~----~----~------~----~------~--~---
