Of course, I have, for SBCL, some solutions. Just simple. Le mer. 5 avr. 2023, 16:56, Grégory Vanuxem <[email protected]> a écrit :
> Hello Waldek, > > Thanks for your detailed explanation. It was very instructive. > > I looked deeper into this and the interpreter has several ways to coerce > the Integer to JDF. Even if I did not implement this coercion. > > I'm still trying to bypass this. The fact that 'sqrt(2)' returns an > AlgebraicNumber I totally agree with but not with sin(2) if sin$Domain is > implemented in a package and not in the Domain itself. In fact, I do not > understand why *trigonometric and other special functions have to be > implemented in the domain itself and why this solution was chosen. > > More to come on this. > __ > Greg > > > Le lun. 3 avr. 2023 à 02:06, Waldek Hebisch <[email protected]> > a écrit : > > > > On Sun, Apr 02, 2023 at 10:17:56PM +0200, Grégory Vanuxem wrote: > > > Hello folks, > > > > > > I have an exposed domain JuliaDoubleFloat (abbrev JDF), and an exposed > > > package JuliaSpecialFunctions (abbrev JSF) that implements the 'sin' > > > function. JDF does not include TrigonometricFunctionCategory as its > > > exports, contrary to DoubleFloat for example. > > > > > > I'm wondering why if I issue a 'sin(2)' in the interpreter it chooses > > > the sin$JSF: > > > > > > (1) -> )set mess bo on > > > (1) -> sin 1 > > > > > > Function Selection for sin > > > Arguments: PI > > > -> no appropriate sin found in PositiveInteger > > > -> no appropriate sin found in Integer > > > -> no appropriate sin found in PositiveInteger > > > -> no appropriate sin found in Integer > > > > > > Modemaps from Associated Packages > > > no modemaps > > > > > > Remaining General Modemaps > > > [1] D -> D from D if D has TRIGCAT > > > [2] JuliaDoubleFloat -> JuliaDoubleFloat from JuliaSpecialFunctions > > > > > > > > > [1] signature: JDF -> JDF > > > implemented: slot (JuliaDoubleFloat)(JuliaDoubleFloat) from JSF > > > [2] signature: EXPR(INT) -> EXPR(INT) > > > implemented: slot $$ from EXPR(INT) > > > > > > > > > (1) 0.8414709848078965 > > > Type: > JuliaDoubleFloat > > > > > > If I unexpose JSF I obtain what is expected: > > > (2) -> )unexpose JSF > > > JuliaSpecialFunctions is now explicitly hidden in frame initial > > > (2) -> sin 1 > > > > > > (2) sin(1) > > > Type: > Expression(Integer) > > > > > > Now, DoubleFloat also implements the 'sin' function, but directly in > > > the DoubleFloat domain. Not in a separate package. > > > > > > If I do the same, move 'JSF$sin' to 'JDF$sin', the interpreter now > > > returns an EXPR INT as expected. Any idea why? And why, for example, > > > 'sin(1)' does not return a DoubleFloat. Is this related to the > > > exposed.lsp file in src/algebra? If I want to continue to expose JSF > > > with 'sin' in it, how can I circumvent this choice and have an EXPR > > > INT returned? > > > __ > > > > There is a lot of special purpose tricks to get good selection > > in "known" cases. General rule is that interpreter prefers > > "low complexity constructors" and parameterless package is > > deemed low complexity, so it is used in preference to alternatives. > > > > For DoubleFloat interpreter knows that DoubleFloat may loose exactness, > > so function selection machinery adds extra penalty to "cost" of > > selections involving DoubleFloat. Interpreter does not know that > > there is anything special about JuliaSpecialFunctions, you exposed > > it so interpreter thinks that you want it. > > > > Also, it looks that you are plying tricks to defeat Spad typechecking. > > However, in typeless context type-based overload resolution is > > not going to work well: if you can coerce anything to anything, > > than interpreter have no way to know what you prefer. > > > > Anyway, for DoubleFloat 'sin' important part is that it is defined > > in domain, so to use it intepreter must already have DoubleFloat > > argument or must use coercion (which counts as more complex option). > > > > So possiblities seem to be: > > - follow intended design and define functions in domais > > - or make sure that there is no way to automatically get > > JuliaDoubleFloat from integer/integer literal > > > > You could try adding JuliaDoubleFloat to 'isApproximate' in > > src/interp/i-funsel.boot, but I doubt that it would help. > > IIRC we had similar problem with special functions: we obtained > > numeric values instead of symbolic ones. This was fixed adapting > > current structure (or, more precisely removing deviations from > > used pattern). > > > > BTW: If you name your package JuliaDoubleFloatSpecialFunctions, > > then interpreter will treat is as "associated" package to > > JuliaDoubleFloat. In such case, having JuliaDoubleFloat > > intepreter will consider use of functions from > > JuliaDoubleFloatSpecialFunctions, but will not introduce > > JuliaDoubleFloat on whim. > > > > -- > > Waldek Hebisch > > > > -- > > You received this message because you are subscribed to the Google > Groups "FriCAS - computer algebra system" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/fricas-devel/20230403004949.55n3optn3lkb2qxv%40fricas.math.uni.wroc.pl > . > -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2da97rGga-n9UUWtA%3DGtbbNFcVHKt%3DV1dbW6L7fuPiSXwQ%40mail.gmail.com.
