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 -~----------~----~----~----~------~----~------~--~---
