On Thu, Jul 8, 2010 at 11:26 AM, Ronan Lamy <ronan.l...@gmail.com> wrote: > Le mardi 06 juillet 2010 à 21:56 -0700, Ondrej Certik a écrit : >> On Tue, Jul 6, 2010 at 4:51 PM, Ronan Lamy <ronan.l...@gmail.com> wrote: >> > Le mardi 06 juillet 2010 à 11:19 -0700, Ondrej Certik a écrit : >> >> Yeah, that's right. It's still faster though: >> > >> > OK, then I guess using expr.func(*some_list) instead of >> > expr.new(*some_list) helps. We could probably even gain a bit more by >> > having a Basic.from_iterable classmethod and doing >> > expr.from_iterable(some_list). >> >> Either is fine with me. >> > I've tried the from_iterable idea and it doesn't seem very useful and > makes code slightly less readable. OTOH, most expr.new <- expr.func > replacements from your branch could be applied on master. > >> >> >> >> > why you expect to see any kind of speedup, since the old assumption >> >> > system is fast and efficient. >> >> >> >> I disagree. >> >> >> > Why? >> >> The old assumptions make it impossible to speedup the core. You wrote >> that you don't see "why it would require the new assumptions." The >> answer to that is that with the current old assumptions, attached to >> symbols, it's not possible to make it as fast as ginac or Sage (for >> example), because you have to worry about assumptions each time you >> construct an expression. >> > I don't understand why you "have to worry about assumptions each time > you construct an expression". Expressions don't actually have > assumptions in the old system. Actually, one of the best features of the > new system is that it promises to allow assumptions to be attached to > expressions. > >> Well, technically, you might say, that it might, theoretically be >> somehow possible, but in practice, we have a nice new core, written in >> python and cython and it is comparable to ginac. It doesn't use >> assumptions. And I don't know any fast way to implement the old >> assumptions in there, without drastically slowing it down. Nor anyone >> else has produced any code to show that. > > OK but the new core doesn't actually work, in the sense that there > exists a branch which can be rebased on master and where all tests pass.
The new core is here: http://github.com/certik/sympyx it can't be rebased on top of master, because it doesn't use assumptions. With the remove_assumptions branch, it will be possible to finally merge it and create a patch that can be rebased on top of master and where all tests pass. > I think it's unwise to throw away code that actually works for the sake > of code that doesn't. I totally agree and I do not propose anything like that. >> >> > >> >> > Apart from this, I can see 2 problems with your branch: >> >> > * There is way too much boilerplate required whenever you want to work >> >> > with symbols. Replacing the Assume thingies with Predicates would help a >> >> > little but still not enough. Maybe Vinzent's "local assumptions" hack >> >> > could be a solution?? >> >> > * The new assumption system hasn't so much replaced the old one as been >> >> > wedged into it. As a result, there are basically two separate assumption >> >> > system, coded separately: obj.is_integer vs. Q.integer(obj). On general >> >> > principles, that sort of code duplication is wrong, and here it raises >> >> > many issues such as which one to use in a given situation or how to make >> >> > sure that their results aren't contradictory. >> >> >> >> >> >> Those are valid concerns, but it's an improvement over the current >> >> master. And it's a necessary step to get the new core in. >> >> >> > I don't think that making sympy slower and harder to use is an >> > improvement. >> >> I don't understand this statement. As I showed above, the new branch >> makes sympy *faster*, and also easier to use, because the core doesn't >> need assumptions attached to symbols, so it will be possible to use >> our fast core. >> > The new branch makes sympy slightly faster in some cases but > significantly slower overall. Forcing users to add boilerplate code I believe that is due to caching. I want to fix it, so that it is not significantly slower over all. > every time they use symbols and to remember to properly manage > assumptions' lifetimes does IMO make sympy harder to use. I agree that if we forced the user to properly manage assumptions in some hard way, as you said, it would make sympy harder to use. I don't want sympy to be harder to use and I am positive that we'll figure it out that everything plays nicely together. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sy...@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
