public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "weslley.pereira at ucdenver dot edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/107753] gfortran returns NaN in complex divisions (x+x*I)/(x+x*I) and (x+x*I)/(x-x*I)
Date: Fri, 18 Nov 2022 23:45:04 +0000	[thread overview]
Message-ID: <bug-107753-4-lbG6cMbCwx@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-107753-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107753

--- Comment #7 from Weslley da Silva Pereira <weslley.pereira at ucdenver dot edu> ---
(In reply to anlauf from comment #3)
> I guess the reporter assumes that gcc uses a clever algorithm like Smith's
> to handle such extreme cases of complex division.  Not sure if that one is
> available by some compilation flag, and I think it would impact performance.
> 
> In any case, if the reporter wants to get robust results and in a portable
> way, I would advise him to change/fix his algorithm accordingly.  It appears
> that a few other compilers behave here like gfortran.

Thanks for the suggestion of changing the algorithm that needs such a division.
What are the ranges for nominator and denominator where one should rely on the
intrinsic complex division? Maybe this is the good question to ask. Then we can
build algorithms that attend such requisites. LAPACK has cladiv and zladiv,
which are routines for complex division that avoids unnecessary under and
overflow. They are used in many parts of the code. This implementation is for
sure less efficient than the intrinsic complex division, but we rely on it
because of robustness.

More data for the discussion:
1. In a Ubuntu 18.04.5 LTS, using GNU Fortran 7.5.0, I tested optimization
flags `-O` but still reproduce the wrong result for complex divisions with huge
numbers. See
https://github.com/Reference-LAPACK/lapack/issues/575#issuecomment-910616816
that used the code from
https://github.com/Reference-LAPACK/lapack/blob/master/INSTALL/test_zcomplexdiv.f.
This is the test currently in LAPACK 3.11.0.
2. I have just reproduced what was reported in
https://github.com/Reference-LAPACK/lapack/issues/575#issuecomment-910616816 in
my Ubuntu 20.04.5 LTS, using GNU Fortran 9.4.0.
3. I noticed that the optimization flag is unable to target divisions like
`x/x` depending on where they are inside a program.
4. My Ubuntu 20.04.5 LTS with compiler ifort 2021.7.1 computes the complex
division `x/x` accurately even for the case of huge numbers. Scenarios tested:
   - I tested the program in
https://github.com/Reference-LAPACK/lapack/blob/master/INSTALL/test_zcomplexdiv.f
and the one in https://godbolt.org/z/b3WKWodvn.
   - I tested ifort with flags -fp-model precise and -fp-model fast. The latter
enables more aggressive optimizations on floating-point data.
   - I tested compilation with optimization flags -O0, -O, -O1, -O2, -O3. 

Here is the implementation of the complex division in LAPACK if it somehow
helps the discussion:
https://netlib.org/lapack/explore-html/d8/d9b/group__double_o_t_h_e_rauxiliary_gad1c0279ec29e8ac222f1e319f4144fcb.html

  parent reply	other threads:[~2022-11-18 23:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-18 19:32 [Bug fortran/107753] New: " weslley.pereira at ucdenver dot edu
2022-11-18 19:50 ` [Bug fortran/107753] " anlauf at gcc dot gnu.org
2022-11-18 20:50 ` kargl at gcc dot gnu.org
2022-11-18 21:26 ` anlauf at gcc dot gnu.org
2022-11-18 22:05 ` kargl at gcc dot gnu.org
2022-11-18 23:24 ` sgk at troutmask dot apl.washington.edu
2022-11-18 23:32 ` sgk at troutmask dot apl.washington.edu
2022-11-18 23:45 ` weslley.pereira at ucdenver dot edu [this message]
2022-11-18 23:47 ` weslley.pereira at ucdenver dot edu
2022-11-19  0:25 ` sgk at troutmask dot apl.washington.edu
2022-11-19 19:11 ` kargl at gcc dot gnu.org
2022-11-19 20:14 ` anlauf at gcc dot gnu.org
2022-11-20  0:54 ` sgk at troutmask dot apl.washington.edu
2022-12-07 21:16 ` anlauf at gcc dot gnu.org
2022-12-07 21:50 ` kargl at gcc dot gnu.org
2022-12-07 22:31 ` anlauf at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-107753-4-lbG6cMbCwx@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).