On Wed, 6 Oct 2021 at 23:36, Francesco Bonazzi
wrote:
>
> It would be curious if we could rewrite SymPy's core using MatchPy. I
> mean, there have been some development with a lot of code developed to
> properly handle the subclassing (or .kind property, that has been
> introduced now) the *Add*
It would be curious if we could rewrite SymPy's core using MatchPy. I mean,
there have been some development with a lot of code developed to properly
handle the subclassing (or .kind property, that has been introduced now)
the *Add* and *Mul* classes, especially their flattening algorithm.
Mul
I wonder if we should somehow refactor Derivative so that derivatives
wrt non-Symbols are represented internally by a Subs object. The logic
in Subs should handle this sort of thing correctly. For instance, this
is correct
>>> expr = Subs(f(x).diff(x), x, y(t))
>>> expr.subs(t, 0)
Subs(Derivative(
On Wed, Oct 6, 2021 at 2:10 AM Francesco Bonazzi
wrote:
>
>
>
> On Wednesday, October 6, 2021 at 12:46:25 a.m. UTC+2 asme...@gmail.com wrote:
>>
>> Since we are bringing up SymPEPs again, it would be helpful to agree
>> on the actual SymPEP process itself. There hasn't been much discussion
>> on h
On Wed, Oct 6, 2021 at 1:52 AM Jason Moore wrote:
>
> I think we should relax our stringent no dependency stance for pure python
> dependencies. Pure python dependency management is essentially solved now for
> the python ecosystem with the various package managers. This dependency would
> also
On Wed, 6 Oct 2021 at 08:52, Jason Moore wrote:
> I think we should relax our stringent no dependency stance for pure python
> dependencies. Pure python dependency management is essentially solved now
> for the python ecosystem with the various package managers. This dependency
> would also be pu
Oscar Benjamin writes:
> I think that the basic problem is just this (which is a bug):
>
> In [86]: expr = f(y(t)).diff(y(t))
>
> In [87]: print(expr)
> Derivative(f(y(t)), y(t))
>
> In [88]: print(expr.subs(t, 0))
> Derivative(f(y(0)), y(0))
Thank you for your detailed answer.
Arguab
On Tuesday, October 5, 2021 at 2:57:41 p.m. UTC+2 syle...@gmail.com wrote:
> Although the matchpy gives of AC1-matching capability as far as I'm aware,
> I just have a question that if is it really general enough.
> I'm aware that general equational matching could be an undecidable
> problem,
On Wednesday, October 6, 2021 at 12:46:25 a.m. UTC+2 asme...@gmail.com
wrote:
> Since we are bringing up SymPEPs again, it would be helpful to agree
> on the actual SymPEP process itself. There hasn't been much discussion
> on https://github.com/sympy/SymPEPs/pull/2 for a while.
>
> I was al
I think we should relax our stringent no dependency stance for pure python
dependencies. Pure python dependency management is essentially solved now
for the python ecosystem with the various package managers. This dependency
would also be pulled into the sympy organization, so we will have just as
On Tuesday, October 5, 2021 at 2:07:06 p.m. UTC+2 Oscar wrote:
>
> I agree that pattern matching is a crucial part of a CAS and should really
> be the core of SymPy. If I was redesigning SymPy from scratch then
> everything would be built on top of a pattern-matching engine and almost
> all o
11 matches
Mail list logo
