I think we had a discussion on irc about how homsets still got used for determining the result of something in parent1 op something in parent2 (maybe it was with someone else?) I'm also -1 for hard-coding knowledge and logic about ZZ,QQ, etc into the coercion model. I am +1 for hardcoding it into the elements of say, ZZ,QQ,RR and then having them call the coercion model only if those hardcodes can't figure the situation out.
On Tue, Jun 3, 2008 at 11:48 AM, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > > On Jun 3, 2008, at 7:13 AM, Gary Furnish wrote: > >>>> As long as there are classes in pure python that use MI on the >>>> critical path that symbolics has to use, the argument that coercion >>>> was written to be fast makes no sense to me. >>> >>> Not sure what you mean by "MI" here, could you explain. In any case, >>> just because coercion isn't as fast as it could be doesn't mean that >>> it's not written for speed and much faster than it used to be. Of >>> course there's room for improvement, but right now the focus is >>> trying to finish the new system (which isn't really that "new" >>> compared to the change made a year ago) in place. >>> >> Sets, and in particular a bunch of the category functionality (homset) >> get used in coercion, and use MI, making them impossible to cythonize. > > Ah, yes. Homsets. They're not used anywhere in the critical path > though. (If so, that should be fixed.) > >>> > >>> >>>>> 2) I personally don't like having to sprinkle the "expand" and >>>>> and/or >>>>> "simplify" all over the place. Now I don't think symbolics >>>>> should be >>>>> expanded automatically, but stuff like (1+sqrt(2))^2 should be or >>>>> 1/(1 >>>>> +i). It's like just getting the question back. (I guess I'm >>>>> revealing >>>>> my bias that I don't think of it as living in SR, but rather a >>>>> number >>>>> field...) On that note, I can't even figure out how to do simplify >>>>> "(sqrt(2)-3)/(sqrt(2)-1)" in the symbolics...as opposed to >>>>> >>>>> sage: K.<sqrt2> = NumberField(x^2-2) >>>>> sage: (sqrt2-3)/(sqrt2-1) >>>>> -2*sqrt2 - 1 >>>>> sage: 1/(sqrt2-1) >>>>> sqrt2 + 1 >>>>> >>>> Your going to have a hard time convincing me that the default >>>> behavior >>>> in Mathematica and Maple is wrong. This makes sense for number >>>> theory >>>> but not for people using calculus. >>> >>> OK, this is a valid point, though the non-calculus portions (and >>> emphasis) of Sage are (relatively) more significant. Sage is not a >>> CAS, that is just one (important) piece of it. >>> >>> Maple does >>> >>>> 1/(1+I); >>> 1/2 - 1/2 I >>> >> I somewhat ignored (1/1+i) (I agree there is an obvious >> simplification), but (x+1)^2 shouldn't get simplified under any >> circumstances. This has (little) do with speed (for this small of >> exponent) and everything to do with being consistent with the high >> degree cases and keeping expressions uncluttered. > > I agree that (x+1)^2 shouldn't get simplified, but for me this has a > very different feel than (1+I)^2 or (1+sqrt(2))^2. > >>> at least. Looking to the M's for ideas is good, but they should not >>> always dictate how we do things--none but Magma has the concept of >>> parents/elements, and Sage uses a very OO model which differs from >>> all of them. Why doesn't it make sense for Mathematica/Maple? I think >>> it's because they view simplification (or even deciding to simplify) >>> as expensive. >>> >>>>> 3) The coercion system works best when things start as high up the >>>>> tree as they can, and the Symbolic Ring is like the big black >>>>> hole at >>>>> the bottom that sucks everything in (and makes it slow). There is a >>>>> coercion from ZZ[sqrt(2)] (with embedding) to SR, but not the other >>>>> way around, and even trying to cast the other way is >>>>> problematic. I'd >>>>> rather that matrix([1, 1/2, 0, sqrt(2)]) land in a matrix space >>>>> over >>>>> the a number field (rather than over SR), and ZZ['x'].gen() + >>>>> sqrt(2) >>>>> be an actual polynomial in x. Also, the SR, though very useful, >>>>> somehow seems less rigorous (I'm sure that this is improving). >>>>> >>>> When coercion is faster we can consider changing this. >>> >>> Coercion speed is irrelevant to the issues I mentioned here... and as >>> coercion+number fields is *currently* faster than what you could hope >>> to get with SR (the examples above all involve coercion) it wouldn't >>> help your case either. >> Only for the sqrt case, and I'm willing to work with that (provided >> that for endusers, sum(sqrt(p)) behaves as expected. > > n-th root would have a similar speed increase, but other than those > two cases I don't see one wanting algebraic extensions (short of > explicitly making a number field). > >>> >>>> My definition >>>> of fast is "<10 cycles if the parents are the same, >>> >>> Python semantics tie our hands a bit here, but I think we're about as >>> close as we can get. >>> >>>> no dictionary lookups if one parent is in the other for all common >>>> cases, >>> >>> Would this mean hard-coding all common paths? Currently there is a >>> single dictionary lookup for common cases (and not a Python dict). >>> >> Common cases should be no more then a virtual call and a few if >> statements away (and not a bunch of virtual calls either. They cost >> performance too. No more then one should be necessary for the common >> case (the code to handle this can probably go in the >> addition/multiplication handlers)). Then if that fails we can take >> the cached dict lookup route. Make the common case fast at the >> expense of the uncommon case. > > I am -1 for hard-coding knowledge and logic about ZZ, QQ, RR, RDF, > CC, CDF, ... into the coercion model. > >>>> otherwise reasonablely quick pure Cython code. >>> >>> Yes, it should be fast, but only has to be done once and then it's >>> cached. Of course the code specific to the ring/elements is as fast >>> or slow as whoever wrote it. >> Sets should not be in python because of homsets! >>> >>>> New and old coercion fail these >>>> tests of sufficiently quick, and I'm not waiting to finish symbolics >>>> until they do pass those tests. >>> >>> Thanks for your concise definition--if you have any input of how to >>> make things faster without hard-coding tons of special cases I'd be >>> very glad to hear (though the current focus is getting things merged >>> back into the main sage branch before we focus on optimization >>> again). >>> >> Sometimes hardcoding special cases is the only way to do things fast. >> It is more important for coercion to be fast (especially if we are >> using it internally in algorithms) then for it to be pretty (although >> it can still be designed in a mathematically rigorous way, the code >> that actually implements it may not be pretty) >> >>>> My alternative option is lets throw in a flag, defaults to off >>>> (current behavior) that lets you turn on sqrt/powers as in number >>>> theory by default instead of SR. This makes the code perform as >>>> expected by end users, and advanced users can use number fields if >>>> they know they are appropriate. This is just largely a one if >>>> statement change in the dispatch of sqrt so this should be >>>> reasonably >>>> safe. >>> >>> "Perform as expected" is what we disagree on, though I'd call us both >>> end- and advanced users. I generally dislike the idea of flags the >>> user sets that change behavior, but it's an option to consider. >>> >> The average calculus student coming from maple is not going to >> understand why he can't perform a sum of the sqrt of some primes. If >> we are to be a viable alternative for non-research mathematicians we >> can't run off and implement things that drastically change the >> complexity of simple operations. > > If we can change the complexity for the better we should. It's a > tradeoff of speed for code with a small number of radicals vs. speed > with a large number of radicals. > > - Robert > > > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
