On Mon, Mar 12, 2012 at 6:54 PM, Ronan Lamy <[email protected]> wrote: > Le lundi 12 mars 2012 à 14:13 -0600, Aaron Meurer a écrit : >> Great. I came to the same conclusion when working on that issue. >> >> Regarding the last commit, "Don't allow classes to set assumptions, >> except for Symbol." does that mean that Function should not be allowed >> to set assumptions. I noticed that Function("f", real=True) does not >> actually work, either in master or your branch? But it should, right? > > well, Function is special because it returns a class, not a Basic > object. I didn't change its behaviour. > > It's not that clear what Function("f", real=True) should do. In most > cases, what you actually want is a function that returns a real when its > argument is real, but that can't be expressed clearly with that kind of > notation.
I would expect it to just satisfy f(whatever).is_real == True. More advanced stuff (like dependence on the argument) would either have to rely on some unimplemented feature of the (new) assumptions, or simply subclassing Function. By the way, in the long run, I think we should change how Function works to not generate a class. http://code.google.com/p/sympy/issues/detail?id=1198 is one big reason. >> >> Regarding the rest, I have no idea what happens in the logic code, so >> I can't say much about that. > > The changes in sympy/core/facts.py aren't that relevant to this > refactoring. They follow a different strand of thought which is to get > the old assumptions to rely on sympy.logic.boolalg instead of using its > own logic system in sympy.core.logic. I see. Well, if you are unsure about what you've done there, you could probably ping Christian to review the changes. I'm sure they are fine, though (especially if you can get the tests to pass :-) Aaron Meurer > > >> Aaron Meurer >> >> On Mon, Mar 12, 2012 at 11:34 AM, Ronan Lamy <[email protected]> wrote: >> > I've been working on a refactoring of the old assumptions. The first >> > part was to replace the ._assumptions dict with a dedicated class >> > (subclassing dict). This brings interesting conceptual clarifications >> > and code simplifications. >> > >> > In particular, it's now clear to me that "assumptions" are used in two >> > rather different ways. For Symbols, assumptions do actually represent >> > assumptions that are part of the object's definition. For all other >> > objects, "assumptions" are a smart property cache, that allows some >> > properties to be computed lazily and efficiently, and these >> > "assumptions" should therefore never be explicitly set, not even in the >> > constructors. >> > >> > I guess that the next steps are to make the split more explicit and to >> > stop pickling property caches (which would solve >> > http://code.google.com/p/sympy/issues/detail?id=2587 ). My branch is >> > here: https://github.com/rlamy/sympy/tree/new-core and I'd be happy to >> > have some feedback. >> > >> > >> > >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "sympy" 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/sympy?hl=en. >> > >> > > > -- > You received this message because you are subscribed to the Google Groups > "sympy" 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/sympy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sympy" 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/sympy?hl=en.
