> But if you can't actually make any changes
or releases for it, then you can't actually do that, and have no
choice but to fork.

Yeah, that was essentially the situation.

> SymPy uses unevaluated expressions
(or "graphs" as the tensor people call it, which is a term I'm not
fond of)...

Aren't you still talking about expression *graphs*, though?  As all this 
symbolic work relates to term rewriting (and all that), graphs seems like a 
pretty standard terminology--especially when one considers anything 
involving multiple, dependent terms.

On Tuesday, March 16, 2021 at 2:51:41 PM UTC-5 asme...@gmail.com wrote:

> On Mon, Mar 15, 2021 at 5:07 PM Brandon T. Willard
> <brandon...@gmail.com> wrote:
> >
> > Same here. I also am interested in more background on the fork. Theano
> > itself was supposed to be "dead" a few years ago when the original
> > developers stopped working on it, but then the pymc developers picked
> > up maintenance.
> >
> > The PyMC group are also maintainers of the original Theano repo, but, 
> per request of the original maintainers, we are not making changes to the 
> Theano repo. The Theano repo really should be frozen, but I'm assuming that 
> we're leaving that up to the original maintainers.
>
> So I guess I was misinformed. I had understood that PyMC was taking
> over development of theano. But if you can't actually make any changes
> or releases for it, then you can't actually do that, and have no
> choice but to fork.
>
> >
> > Could the same thing happen again?
> >
> > Could development stop on Aesara as it did with Theano? If that's the 
> question you're asking, the answer is that it's always possible, but 
> unlikely to occur any time soon. There's still a real place for a primarily 
> Python-driven tensor library with a (relatively) accessible codebase. Also, 
> for PyMC's purposes and future, we need to work more and more at the tensor 
> library level, so it's important that the development requirements not 
> skyrocket, and that the underlying library not make detrimental design 
> and/or implementation changes.
>
> No I meant could theano be revived again? But it sounds like it wasn't
> actually "revived" in the first place.
>
> >
> > Also, I had heard that pymc was dropping theano in favor of tensorflow
> > (do I remember this correctly?). Is this still planned, or has that
> > changed to be aesara now?
> >
> > Since this announcement, we've dropped all plans to implement the next 
> version of PyMC in TensorFlow. The reason: it's possible for us to have the 
> kind of tensor library described above and use other backends, when 
> desired. I wrote a quick example of how we can convert Theano graphs to JAX 
> "graphs", and that was enough to prove the point.
> >
> > My original plan was to use SymPy for all this, but it would've resulted 
> in a distinct project anyway, because doing all that work via changes to 
> SymPy would've most likely taken too long.
>
> I tend to agree with this decision. SymPy uses unevaluated expressions
> (or "graphs" as the tensor people call it, which is a term I'm not
> fond of), but it's really not designed to build arbitrary symbolic
> systems. The main thing it is designed for is representing
> mathematical expression. So you'd run into a lot of problems with
> SymPy. For example, the core SymPy expressions automatically evaluate
> and don't distinguish certain equivalent expressions. It's lower
> fidelity than a pure AST, because the primary thing it cares about is
> mathematics. You would end up building all of the expression classes
> from scratch, in which case, you would be better off just building
> your own thing instead of building on top of SymPy.
>
> With that being said, some of these limitations also limit what SymPy
> itself can do, so we still are interested in removing them. But they
> are indeed a lot of work.
>
> Aaron Meurer
>
> > On Monday, March 15, 2021 at 5:34:27 PM UTC-5 asme...@gmail.com wrote:
> >>
> >> On Mon, Mar 15, 2021 at 4:18 PM Oscar Benjamin
> >> <oscar.j....@gmail.com> wrote:
> >> >
> >> > On Mon, 15 Mar 2021 at 22:01, Aaron Meurer <asme...@gmail.com> wrote:
> >> > >
> >> > > As long as Theano itself still works in versions of Python that 
> SymPy
> >> > > supports, it would be better to deprecate the function rather than
> >> > > just remove it. The function theano_code is public API so just
> >> > > removing it would be a backwards compatibility break, which we try 
> to
> >> > > avoid without deprecations. See
> >> > > https://github.com/sympy/sympy/wiki/Deprecating-policy
> >> >
> >> > I think that if Theano itself is now unmaintained legacy software then
> >> > it's fine to say that if someone wants to use it with sympy they
> >> > should use an older version of sympy.
> >> >
> >> > > As an aside, one thing that has always annoyed me with Theano,
> >> > > especially when SymPy imports it for its tests, is that Theano does 
> a
> >> > > lot of things at import time, such as running compilers to see if 
> they
> >> > > work and printing many warnings (see
> >> > > https://github.com/sympy/sympy/pull/14747). I think it would be 
> better
> >> > > to do these things at runtime, e.g., after the first function is
> >> > > called. I hope Aesara can improve this situation over Theano.
> >> >
> >> > This shows precisely that supporting something like Theano has a
> >> > nonzero cost even if that support is "deprecated". When migrating our
> >> > CI I had to work through many different projects that I do not know in
> >> > order to keep the test suite ticking over. Each of those makes general
> >> > project maintenance harder. I'm much happier about supporting a
> >> > maintained project that has a future and has maintainers willing to
> >> > help us provide support.
> >>
> >> These are fair points. It sounds like we should definitely not leave
> >> it as is. We should either deprecate it or remove it.
> >>
> >> The existing pull request only does a name change, suggesting there
> >> aren't very many differences between theano and aesara yet. So a
> >> deprecation wouldn't be that hard. If that changes in the future, it
> >> may be easier to just remove theanocode rather than trying to keep it
> >> around.
> >>
> >> >
> >> > I'm interested to hear from anyone using SymPy with Theano though (if
> >> > anyone on this particular mailing list is).
> >>
> >> Same here. I also am interested in more background on the fork. Theano
> >> itself was supposed to be "dead" a few years ago when the original
> >> developers stopped working on it, but then the pymc developers picked
> >> up maintenance. Could the same thing happen again?
> >>
> >> Also, I had heard that pymc was dropping theano in favor of tensorflow
> >> (do I remember this correctly?). Is this still planned, or has that
> >> changed to be aesara now?
> >>
> >> Aaron Meurer
> >>
> >> >
> >> >
> >> > Oscar
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google 
> Groups "sympy" group.
> >> > To unsubscribe from this group and stop receiving emails from it, 
> send an email to sympy+un...@googlegroups.com.
> >> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sympy/CAHVvXxSoee41vDUk1oXzY-n-jgFi18z3Q15Beu6AP%2B5hOx-Thw%40mail.gmail.com
> .
> >
> > --
> > You received this message because you are subscribed to the Google 
> Groups "sympy" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to sympy+un...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sympy/9edbf828-2510-4aa0-a3f8-88a35d60263cn%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/973e11b4-5cf5-4e3c-837e-8d496d657cffn%40googlegroups.com.

Reply via email to