Short answer for now... Waldek Hebisch <[EMAIL PROTECTED]> writes:
> Martin Rubey wrote: > > > > Waldek Hebisch <[EMAIL PROTECTED]> writes: > > 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. I don't think so. If, then only superficially. > 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. Exactly, we agree here, and this is actually in line with the current design of the algebra. I once asked an expert the very naive question, what a special function is... > 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 term using SPFCAT as container for all special > functions looks reasonable for me. That's exactly what I think, too. No: also for long term, actually. I don't think it is a problem if two categories export the same function, given that there is good reason for it. If a function is member of SpecialFunctionCategory, and turns out to be holonomic, then in future there will be two Categories exporting it, no problem. What I meant with proper design is: * which domains should export SPFCAT: Float, DFLOAT, EXPR INT, and probably Complex thereof, * I'll have to think about "associated" packages. You wrote: > 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. I guess, the point is that we cannot say (at least in SPAD/Aldor) in, say FLOAT: take definitions from the package FloatSpecialFunctions if you cannot find them here... ------------------------------------------------------------------------------- > 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). Yes, we agree. > 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). Maybe, but I do not see a case here. > 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. Well, not so sure about that. > 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. Yes, definitively. 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 -~----------~----~----~----~------~----~------~--~---
