Hi all,
In SymPy is there any way of stopping orthogonal polynomials from
automatically simplifying down to concrete expressions? So for:
sy.jacobi_normalized(2, 0, 1, x)
to give:
sqrt(6)/3*jacobi(2, 0, 1, x)
as opposed to:
sqrt(6)*(5*x**2/2 - x - 1/2)/2
I have a use-case where it is
Unwanted automatic evaluation comes up fairly frequently on the listhost.
It's on our radar but there hasn't been much movement on the issue lately.
It requires a concerted effort by someone with some time.
> is there wider interest in such a feature?
Absolutely.
On Wed, Feb 5, 2014 at 2:54 PM,
Although, I don't know much about the polynomials module. It may be
possible to resolve the problem there without tackling the problem at large.
On Wed, Feb 5, 2014 at 3:29 PM, Matthew Rocklin wrote:
> Unwanted automatic evaluation comes up fairly frequently on the listhost.
> It's on our rada
Isn't the solution simply to provide a class Jacobi, that is not
evaluated, and a function jacobi(), that does what it does now?
Ondrej
On Wed, Feb 5, 2014 at 4:38 PM, Matthew Rocklin wrote:
> Although, I don't know much about the polynomials module. It may be
> possible to resolve the problem
I guess I'd like to see code like the following
>>> sy.jacobi_normalized(2, 0, 1, x)
sqrt(6)*(5*x**2/2 - x - 1/2)/2
>>> with evaluation(False):
...sy.jacobi_normalized(2, 0, 1, x)
sqrt(6)/3*jacobi(2, 0, 1, x)
But yes, I suppose we could just capitalize the jacobi class and add an
evaluate= k
We should just change all the special polynomial objects to not
evaluate by default. jacobi_normalized actually *is* a class, but it
evaluates whenever the degree is an explicit integer. But there's no
need for this, as we already have *_poly versions of these functions
to do that.
Until this gets
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/02/2014 01:43, Aaron Meurer wrote:
> We should just change all the special polynomial objects to not
> evaluate by default. jacobi_normalized actually *is* a class, but
> it evaluates whenever the degree is an explicit integer. But
> there's no
Hi,
> We should just change all the special polynomial objects to not
> evaluate by default.
Ok, let me fix that. But be aware that this *will* break
compatibility in all cases. I don't think we can avoid
that with reasonable effort. (And I will not try.)
--
You received this message because yo
What do you mean it will break compatibility? Of course, any code that
writes hermite(2, x) and expects a polynomial will break, but that's
the point of the change.
Aaron Meurer
On Fri, Feb 7, 2014 at 7:09 PM, someone wrote:
> Hi,
>
>> We should just change all the special polynomial objects to
Hi,
> > We should just change all the special polynomial objects to not
> > evaluate by default.
Please try PR #2890.
--
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
> What do you mean it will break compatibility? Of course, any code that
> writes hermite(2, x) and expects a polynomial will break, but that's
> the point of the change.
That is exactly what I mean. And this may occur deep within
some other algorithms, for example heurisch maybe. The tests
will s
11 matches
Mail list logo
