On 22 October 2015 at 21:31, Waldek Hebisch <[email protected]> wrote: > Bill Page wrote: >> >> What specifically implements the numeric evaluation in the example of >> >> NV(x:Float):Float == ... erf(...) ? > > One answer is: interpreter via typechecking. Another is that > numeric 'erf' is implemented in FloatLiouvilianFunctions.
Yes, so in this context there is no problem. > More precisely, Johannes asks for connection between symbolic > function and the numeric one. Johannes wrote: > another problem with numeric evaluations for computing the normal > distribution using the error function. > To my opinion, numeric NV(0.7) directly should return 0.7580363478 Perhaps I misread this as implying that the function NV should be considered numeric. In the context of NV(0.7) by default the interpreter assigns NV the signature Float -> Expression(Float), so as you say by default the result here is not numeric. It is not clear to me why this might be the behaviour desired by users. This is probably counter to most user expectations since passing a floating point value one might reasonably expect a floating point result if at all possible In fact later Johannes gave this example: > (56) -> MV(x) == (1+sin(x/sqrt(2)))/2 > Type: Void > (57) -> MV 0.3 > Compiling function MV with type Float -> Expression(Float) > > (57) 0.60527231 > Type: Expression(Float) > > I even would expect the result here being in Float Since the domain Expression(Float) embeds Float, expecting that the type of the result be Float goes beyond what the interpreter tries to automatically do for the user but a simple retraction to Float is easy to express. Resorting to trying to force a numeric result by calling the 'numeric' operator seems undesirable. > Of course a precondition to > this is existence of both numeric and symbolic version. > Once both are available at the command line typechecker will > resolve overloading and choose one of them. Yes. That was the point of my question. > OK if you really need 'numeric' > just now you could do: > > my_numeric(ie : Expression(Integer)) : Float == > fe := ie::Expression(Float) > fval := interpret(fe::InputForm)$InputFormFunctions1(Float) > > (12) -> nv := erf(7/10) > > 7 > (12) erf(--) > 10 > Type: Expression(Integer) > (13) -> my_numeric(nv) > Compiling function my_numeric with type Expression(Integer) -> Float > > > (13) 0.6778011938_3741847297 > Type: Float > > However, I am not sure if we want to implement 'numeric' via > trip to interpreter. After all we already have everything > type-correct and do not want to guess types. > I agree. >> On 2015-10-22 6:26 PM, "Waldek Hebisch" <[email protected]> wrote: >> > >> > expressions in undesirable way. So I would like to limit >> > automatic evaluation only to few cases when it is clear >> > that it will cause no problems. >> >> Do you mean all automatic evaluations, only those involving retractions >> to the coefficient domain, or only those that result in "numeric >> approximations"? > > All automatic evaluation. > This seem very ambitious and perhaps somewhat against the philosophy implemented in Expression of (almost) canonical expressions. I would expect such a change to have far reaching effects on the rest of FriCAS. >> > OK, above I gave reasons while I am not eager to follow Axiom >> > there. So what I intend to do? My current plan is to add >> > new property to operators, giving appropriate evaluation >> > function. Then numeric could be implemented as a tree >> > walker over expressions, in the style of 'eval'. >> > >> >> Should there be one evaluation function for each possible numeric domain or >> something more generic? Evaluation functions for many operators already >> exist. Either way this sounds awkward to me. > > I mean 'Complex(Float)' as numeric doman. We would get 'Float' > via retraction. IIRC no other numeric domain is supported > by 'numeric'. > So, in addition to whatever other evaluation function might already be defined for an operator you would add another just for those cases when a kernel might be approximated by a Complex Float? E.g. sqrt(-1) in Expression Integer would be evaluated as complex(0,1) >> It seems to make fairly good sense to me that one should avoid coefficient >> domains for Expression that export functions that implement otherwise >> symbolic operators if one does not want such automatic simplifications. >> This is the essential difference between Expression Float and Expression >> Integer. > > Interpreter forbids 'Expression(Expression(Integer))' but it actually > makes sense and is used in integrator. OK. > Generic evaluation would > push things into lower 'Expression' potentially destroying > structure. In what sense is structure destroyed by this evaluation? Generic evaluation is not intended to change the type of the result. It just happens that this result has a simpler canonical representation in 'Expression(Expression(Integer))'. Perhaps you just need to account for this possibility when using this type. > Currently the only use is when lower 'Expression' > represents constants and applying function to a constant still > gives a constant so there are no problem. But with more use > we could hit a problem. We already have problems because of > automatic simplification of roots. > If 'Expression(Expression(Integer))' is the best use case for advocating avoiding generic evaluation then my impression is that the cost of such a change would greatly out weigh the cost of finding an alternative representation for use in the integrator. Bill. -- 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 post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
