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. (If I'm not mistaken, only hypergeometric0F1 is currently not in SPFCAT, although implemented in DFSFUN. Shouldn't that be in SPFCAT, too?) > 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) 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.) by the way: it may make sense to check which constructors in exposed.lsp actually exist: (|FloatSpecialFunctions| . FSFUN) does not... * 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. Martin --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
