Has anyone had any thoughts or seen what other CAS do to take advantage of
multiple cores? For example, if one is collecting terms, one could imagine
farming out subexpressions to search to each core.
William
On Tue, Jun 22, 2010 at 1:11 AM, Ondrej Certik <ond...@certik.cz> wrote:
> On Mon, Jun 21, 2010 at 9:40 PM, Aaron S. Meurer <asmeu...@gmail.com>
> wrote:
> >
> > On Jun 21, 2010, at 10:31 PM, Ondrej Certik wrote:
> >
> >> Hi Christian,
> >>
> >> On Mon, Jun 21, 2010 at 8:24 PM, Christian Muise
> >> <christian.mu...@gmail.com> wrote:
> >>> I was asked to update the list with my progress daily until Friday, so
> I'll
> >>> keep this quick.
> >>> I've pushed hard against the branch to remove the old assumptions,
> and as
> >>> of a few minutes ago I've managed to get the sympy/core working smooth:
> >>> ======= tests finished: 329 passed, 6 expected to fail, in 12.57
> seconds
> >>> =======
> >>> - Commit: 5e76a479db9f5ad2c55a
> >>> This is in contrast with the state of affairs just after the
> discussion
> >>> late last week:
> >>> tests finished: 306 passed, 22 failed, 5 expected to fail,
> >>> 1 expected to fail but passed, 1 exceptions, in 8.12 seconds
> >>> - Commit: 91bcb155b24fd354cfdc
> >>> And this is the stats on my netbook for the master branch (just in
> case
> >>> those times looked a little high):
> >>> ======= tests finished: 390 passed, 7 expected to fail, in 11.58
> seconds
> >>> =======
> >>> Few things worth noting:
> >>> - Most of the default assumption handling occurs now in the Expr class.
> It
> >>> dispatches to the global_assumptions if there is a straight up
> assumption
> >>> referring to the current query (<var>.is_foo), then attempts to
> >>> _eval_is_foo, and in some cases check's related is_foo2's.
> >>> - Instead of commenting out / deleting the tests that used assumptions,
> I
> >>> rewrote them to use global assumptions. There may be more in the core
> that
> >>> I've missed, but once they're stripped from the constructor those
> should
> >>> surface. This flies against the recommended path, but I think they test
> >>> important things and we can always place them some place else (it's
> easy to
> >>> locate all instances in the testing files).
> >>> - I found that from time to time an expression would be cached, and
> then the
> >>> symbol would be used later with different assumptions. This proved to
> be
> >>> /extremely/ problematic and hard to debug. Would it be worth modifying
> the
> >>> cache so that all expressions related to a symbol (eg. x) are dumped
> when
> >>> the Symbol('x') is called again?
> >>
> >> This is a phenomenal progress! Thanks for this. Yes, you have just
> >> discovered another problem, why I so desperately want to get the old
> >> assumptions gone --- caching. And exactly because of the bugs that you
> >> posted, the cache has to be either fixed or removed.
> >>
> >> I would be more than happy if we can remove all caching altogether,
> >> but since it currently would slow sympy down, Well, maybe not anymore.
> >> We should do some tests. But let's say we need to keep the cache (at
> >> least optional).
> >>
> >> Do I understand correctly, that now the expressions don't remember
> >> their assumptions themselves, but you need to use either local or
> >> global assumptions? If so, I would just store the pure expression in
> >> the cache and only store the result in some form, that is independent
> >> of the assumptions. Or maybe with the assumptions themselves -- e.g.
> >> both an expression and the assumptions.
> >>
> >> Ondrej
> >
> > Aren't some results dependent on assumptions? I don't see how you can
> cache independent of assumptions and not have problems.
>
> For example:
>
> 1) check that there are no global or local assumptions set
> 2) store the expression
>
>
> retrieve:
>
> * check 1)
> * use cache
>
> 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 <sympy%2bunsubscr...@googlegroups.com>.
> 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 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.
