From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <musl-return-20966-ml=inbox.vuxu.org@lists.openwall.com>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,
	RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4
Received: from second.openwall.net (second.openwall.net [193.110.157.125])
	by inbox.vuxu.org (Postfix) with SMTP id CD3DD25B6D
	for <ml@inbox.vuxu.org>; Wed, 29 May 2024 03:38:03 +0200 (CEST)
Received: (qmail 24352 invoked by uid 550); 29 May 2024 01:37:58 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 24308 invoked from network); 29 May 2024 01:37:58 -0000
Date: Tue, 28 May 2024 21:38:14 -0400
From: Rich Felker <dalias@libc.org>
To: Nikolaos Chatzikonstantinou <nchatz314@gmail.com>
Cc: Markus Wichmann <nullplan@gmx.net>, musl@lists.openwall.com
Message-ID: <20240529013813.GG10433@brightrain.aerifal.cx>
References: <CAAQmekd_LMvH+3sTu8E8LNB4zop_aB9BgKRe2M+HKtd6nERTzg@mail.gmail.com>
 <CAAQmekc76iSjRots+cQuWMMsBPnPEV5emiCH8wAsmVxRH+OpEA@mail.gmail.com>
 <20220705093704.GY1320090@port70.net>
 <CAAQmekf1XKw+_nQe9M7YD_5VYWBcVTEgekYK8JEk18D5ugLhgg@mail.gmail.com>
 <20220705153515.GA2522@voyager>
 <CAAQmekfGjOwy5s+P+E6kuUaMrOC02+tMigwN8fgUEhbixd2GYg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAAQmekfGjOwy5s+P+E6kuUaMrOC02+tMigwN8fgUEhbixd2GYg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [musl] Re: Implementing csqrtl()

On Tue, Jul 05, 2022 at 04:14:13PM +0000, Nikolaos Chatzikonstantinou wrote:
> On Tue, Jul 5, 2022 at 3:35 PM Markus Wichmann <nullplan@gmx.net> wrote:
> >
> > On Tue, Jul 05, 2022 at 02:28:32PM +0000, Nikolaos Chatzikonstantinou wrote:
> > > On Tue, Jul 5, 2022 at 9:37 AM Szabolcs Nagy <nsz@port70.net> wrote:
> > > >
> > > > * Nikolaos Chatzikonstantinou <nchatz314@gmail.com> [2022-07-04 11:09:44 +0000]:
> > > >
> > > > > +  if ((isinf(x) || isinf(y)) && (isnan(r) || isinf(r))) {
> > > >
> > > > why do you need the && ?
> > > > can r be other than inf or nan?
> > >
> > > It's the case that x^2 + y^2 is inf for x,y finite.
> > >
> >
> > Yeah, but if x or y is infinite then so is r. So the entire part in
> > front of the && is redundant, because it is contained in the second
> > part.
> >
> > Unless I completely misunderstood how IEEE infinity works...
> 
> Yes you are right, it should be if(isinf(x) || isinf(y)).

I don't think this is correct. It's possible for r (which actually
holds a value I would call r², perhaps r2 as var name?) to be infinite
even when x and y are finite. This sounds problematic. Don't you need
to work with actual r, guaranteed to be finite when x and y are, which
you could obtain from hypotl?

Rich