Function selection
Waldek Hebisch
point arithmetic instead of exact evaluation (for example see
http://sourceforge.net/tracker/?func=detail&aid=2974970&group_id=200168&atid=972421)
The patch below should fix this problem. The 'isApproximate' function
is somewhat ad-hoc, ideally we would declare such information in
algebra. However, ATM we do not have a way to propagate such
information where needed. OTOH the problem is getting urgent
because I want to add numerical routines for more special
functions. Currently Gamma, digamma and bessel function have
problems. Elementary functions are not affected, because
numerical versions are defined in Float (and not in a separate
package), but I really do not want to put all numerical
routines in Float to avoid this problem. And beside special
functions we sometimes got numerical evaluation for polynomials
so the change fixes more problem.
--- ../ppn33/trunk/src/interp/i-funsel.boot 2011-01-04 18:32:17.000000000 -0500
+++ i-funsel.boot 2010-11-29 17:41:08.000000000 -0500
@@ -605,6 +605,13 @@
mmS := [mm,:mmS]
nreverse mmS
+isApproximate(t) ==
+ op := CAR(t)
+ member(op, ["Float", "DoubleFloat"]) => true
+ member(op, ["Complex", "Expression", "List", "Polynomial",
+ "Matrix", "Vector"]) => isApproximate(CAR(CDR(t)))
+ false
+
mmCost(name, sig,cond,tar,args1,args2) ==
cost := mmCost0(name, sig,cond,tar,args1,args2)
res := CADR sig
@@ -628,6 +635,8 @@
-- modemaps with the wrong number of arguments if we want to the one
-- with no arguments and the name is overloaded. Thus check for this.
+ nargs := #args1
+
if args1 then
for x1 in args1 for x2 in args2 for x3 in sigArgs repeat
n := n +
@@ -637,6 +646,8 @@
topcon = topcon2 => 3
CAR topcon2 = 'Mapping => 2
4
+ if isApproximate(x1) ~= isApproximate(x3) then
+ n := n + 10*nargs
else if sigArgs then n := n + 100000000000
res := CADR sig
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
I cannot really judge this patch since I have no idea what the arguments
of mmCost0 actually are. But it really looks like an ad-hoc patch.
Go on if you think it solves the problem. But you should definitely add
some documentation to i-funsel.boot of why you do this, otherwise it
will just add complexity that nobody understands anymore in the future.
Since you refer to
>
http://sourceforge.net/tracker/?func=detail&aid=2974970&group_id=200168&atid=972421
you seem to want to avoid coercion of 2 to 2.0@Float. Am I wrong?
I guess, digamma(2.0) should still give 0.42278433509846725.
Looks like only the interpreter is the problem, no change for compiled
code, right?
What you do in
isApproximate(t) ==
op := CAR(t)
member(op, ["Float", "DoubleFloat"]) => true
member(op, ["Complex", "Expression", "List", "Polynomial",
"Matrix", "Vector"]) => isApproximate(CAR(CDR(t)))
false
looks like defining a new Category "Approximate", putting Float and
DoubleFloat in it and having this category (conditionally) inherited by
the other constructors you list above. Only that you do this in the
above function without categories.
Since I consider the category way more flexible, I'd like to ask, how
complete your list of the above domain constructors is.
Please, put at least the URL to this email thread into the code.
Ralf
Waldek Hebisch
>
> Waldek,
>
> I cannot really judge this patch since I have no idea what the arguments
> of mmCost0 actually are. But it really looks like an ad-hoc patch.
>
name is name of the function, sig is signature under consideration,
cond are conditions uder which signature is valid (we are allowed
to call conditionally exported functions only if conditions are satisfied),
tar is disired target type, cond are conditions uder which signature
is valid (we are allowed to call conditionally exported functions
only if conditions are satisfied), args1 are actual types of
arguments, args2 represet alternative types (types to which
we can convert arguments, this is a hack to allow automatic
coercion for few important types).
> Go on if you think it solves the problem. But you should definitely add
> some documentation to i-funsel.boot of why you do this, otherwise it
> will just add complexity that nobody understands anymore in the future.
>
> Since you refer to
> >
> http://sourceforge.net/tracker/?func=detail&aid=2974970&group_id=200168&atid=972421
> you seem to want to avoid coercion of 2 to 2.0@Float. Am I wrong?
> I guess, digamma(2.0) should still give 0.42278433509846725.
>
Yes. The code tries to avoid coercion of 2 to 2.0, but also tries
to avoid coercion from 2.0 to 2 (so that when computations are
approximate the result type should reflect this).
> Looks like only the interpreter is the problem, no change for compiled
> code, right?
>
Yes.
> What you do in
>
> isApproximate(t) ==
> op := CAR(t)
> member(op, ["Float", "DoubleFloat"]) => true
> member(op, ["Complex", "Expression", "List", "Polynomial",
> "Matrix", "Vector"]) => isApproximate(CAR(CDR(t)))
> false
>
> looks like defining a new Category "Approximate", putting Float and
> DoubleFloat in it and having this category (conditionally) inherited by
> the other constructors you list above. Only that you do this in the
> above function without categories.
>
Yes.
> Since I consider the category way more flexible, I'd like to ask, how
> complete your list of the above domain constructors is.
>
Theoreticaly very incomplete. I belive that in practice it will
cover vast majority of use cases. Of course, if some new problem
shows up we would have to amend this list.
One theoretical problem is p-adic numbers: they are approximate
so we probably want to avoid coercions to p-adics. But without
use cases it is hard to decide if we really want this, so
I decided to omit them form the list above.
--
Waldek Hebisch
heb...@math.uni.wroc.pl