Another thought is that, for a real variable, `Abs` can be rewritten as
`Piecewise`:
```
>>> var('a',real=True)
a
>>> Abs(a).rewrite(Piecewise)
Piecewise((a, a >= 0), (-a, True))
>>> eq = Abs(a**2 + 2) + sqrt(2)*Abs(2*a**2 - 1)/3 + sqrt(2)*(a + 1)*Abs(a
- 1)/3
>>> eq.rewrite(Piecewise).simplify()
Piecewise(
(a**2 + sqrt(2)*a**2 - 2*sqrt(2)/3 + 2, a >= 1),
(sqrt(2)*a**2/3 + a**2 + 2, a**2 >= 1/2),
(-sqrt(2)*a**2 + a**2 + 2*sqrt(2)/3 + 2, True))
```
/c
On Saturday, April 3, 2021 at 1:24:36 AM UTC-5 [email protected]
wrote:
> [NOTE: I mistakenly sent several replies to individuals rather than to
> the group. Several are moot, but I did not want to leave them off-list.
> So I am resending below. Sorry about that! Bruce]
>
>
> Dear Aaron,
>
> Thank you again for your help. I found the solution to my problem
> (which involves the Voronoi cells of a particular 9-dimensional lattice)
> last night. It's the first time that I have used sympy, and I have been
> impressed by its capabilities. I have been a Mathematica user since
> before it existed as a formal product, but it is not appropriate for my
> current problem.
>
> >> I think we should remove this automatic evaluation from sqrt(). If we
> >> did, then simply calling powsimp() on your expression would do what
> >> you want.
> >
> > I believe this is the corresponding issue for this
> > https://github.com/sympy/sympy/issues/7376
>
> Yes, that's the issue. Indeed, after studying the documentation in the
> past days, I had tried powsimp() and some of its friends, but they did
> not have any effect.
>
> A last comment to you and the other experts here.
>
> I signed up to this mailing list to get some help with my issues, which
> are now resolved. But of course I saw the other correspondence there,
> and wanted to say that I am very impressed by the discussion that is
> underway, regarding possible changes to the assumptions system. I'm
> sure one of the reasons that sympy works well is exactly because such
> discussions are being carried out, with the pros and cons hashed out
> among the experts, before the code base gets modified.
>
> I lack the CS competence to be of any use in this (truth be told, K&R C
> is probably the most fluent of my ~20 different computer languages) but
> did have one suggestion, which is entirely from the user perspective.
>
> In your design choice, IMO the overriding concern should be run-time
> efficiency: pick the solution which is potentially the most efficient in
> terms of computer cycles. The reason is simple. We use computers to do
> calculations because they are impossible to do by hand. So provided
> that it does not lead to internal complications which are overwhelming,
> efficiency and (user) simplicity should be paramount.
>
> (Also, if possible, old code should not break. But that's second order
> IMO.)
>
> Cheers,
> Bruce
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/d1264321-108f-4aeb-9f1e-640294105c1cn%40googlegroups.com.
