Ralf Hemmecke wrote: > > 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...@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 [email protected] -- 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.
