On Jun 3, 2008, at 11:06 AM, Gary Furnish wrote: > 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 sure hope not. If so, that needs to change (but I'm pretty sure it isn't). > 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. That sounds much better, though I'm still not a fan. > > 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 -~----------~----~----~----~------~----~------~--~---
