New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disallow automatic abs() simplifications resulting non-real expressions #19797
Comments
Branch: u/jdemeyer/ticket/19797 |
comment:2
Isn't this sacrificing a lot of numerical performance? At least IEEE 754-2008 contains fused multiply-add. The doctest is
Isn't the real problem that abs does not default to
so something that ought to be manifestly real is not. Compare:
vs.
New commits:
|
Commit: |
comment:3
Replying to @vbraun:
I have no idea but I doubt it. For example, Intel architectures added this instruction only very recently. |
comment:4
Yes but CPU's haven't seen any general speedups recently, either. Only more specialized instructions, and if you don't use them then you are not participating in progress. |
comment:5
Replying to @vbraun:
I would say that at least in the specific case of complex multiplication, the use of FMA instructions is wrong. |
comment:6
Alternatively, we could probably play some tricks with |
comment:7
So the question is: Should we guarantee that I'm not sure.
What I am pretty sure about is: multiplying |
comment:8
Replying to @vbraun:
Maybe it's better to expand automatically if the result contains
It is but only when expanded. |
comment:9
Also only if the result is not of form |
comment:10
And not of the form Automatically expanding isn't good enough either in general:
|
Upstream: Reported upstream. Developers acknowledge bug. |
This comment has been minimized.
This comment has been minimized.
comment:12
Replying to @vbraun:
With x87, it is reasonable to assume that the whole imaginary part will be evaluated with 80 bits, so there won't be numerical noise either (see also the successful i386 buildbot reports). |
comment:13
Replying to @vbraun:
This can be fixed in
Why not? This is real as well and could be rewritten as a sum of trig function expressions. |
comment:14
Replying to @rwst:
Volker's point is about being "manifestly" real, which means: an expression which will always give a real result when evaluated, even if sub-expressions introduce numerical noise. An expression like
is not manifestly real, since there is no guarantee that the imaginary parts of the two terms will exactly cancel out. |
comment:15
Well then, exclude functions in the treewalk in the search for |
comment:16
Its not just that there is no guarantee against numerical noise in the imaginary part of
Thoughts? |
comment:17
Replying to @vbraun:
Is this decidable without expansion? Simply weeding out rational exponents will make If so, I no longer think it useful. |
comment:18
So, you're proposing to always hold |
comment:19
Even with expansion I think it can be difficult to tell if a radical is real or not; Cardano's formula which can't be written in real radicals even if the roots are real comes to mind. Of course it is possible to decide if a radical is real or not, for example using QQbar. Can't we just |
comment:20
Replying to @vbraun:
We could certainly do that as a stopgap-style solution. However, this is certainly going to break some doctests... |
comment:21
Replying to @jdemeyer:
I get only two fails in |
comment:22
So the result is arrived at by two code parts: first |
comment:23
So I'll just disable the |
comment:24
Replying to @rwst:
It's really this second part which is problematic. |
This comment has been minimized.
This comment has been minimized.
Changed dependencies from #19796 to none |
This comment has been minimized.
This comment has been minimized.
comment:27
The simplification |
This comment has been minimized.
This comment has been minimized.
comment:28
This was introduced with pynac-0.3.9.2 from GiNaC. I'll revert it for pynac-0.5.4. |
Reviewer: Jeroen Demeyer |
comment:29
"Duplicate" of #19819. |
Changed author from Jeroen Demeyer to none |
Changed branch from u/jdemeyer/ticket/19797 to none |
Changed commit from |
Calling
abs()
on certain expressions can yield something which is not guaranteed to be evaluated as a real number:In the presence of numerical noise, the expression
x*conjugate(x)
can have a non-zero imaginary part. And even if there is no noise, the type would be wrong: complex instead of real.This causes the following doctest failure:
See pynac/pynac#117
Upstream: Reported upstream. Developers acknowledge bug.
CC: @rwst
Component: packages: standard
Reviewer: Jeroen Demeyer
Issue created by migration from https://trac.sagemath.org/ticket/19797
The text was updated successfully, but these errors were encountered: