Date: Wed, 13 Nov 2019 15:22:33 -0800 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: Jeff Walden <jwalden@mit.edu> Cc: freebsd-numerics@freebsd.org Subject: Re: UB in various hypot() implementations (left-shifting a negative number) Message-ID: <20191113232233.GA64847@troutmask.apl.washington.edu> In-Reply-To: <ecf6c3ed-dea7-ae4f-77fa-a6114b688fec@mit.edu> References: <ecf6c3ed-dea7-ae4f-77fa-a6114b688fec@mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Looks good to me. Just need to convince someone to commit it. -- steve On Wed, Nov 13, 2019 at 02:43:04PM -0800, Jeff Walden wrote: > > Just wanted to note here that I filed https://reviews.freebsd.org/D22354 to fix a bit of undefined behavior in the hypot() function implementations. > > `hypot(x, y)` computes `sqrt(x*x + y*y)`, with IEEE-754-aware precision. For very large or small `x` or `y`, the naive implementation would lose precision -- so in such cases the calculation is performed after multiplying the numbers by a very large (or very small) power of two, then the multiplication is undone at end. > > Undoing the multiplication involves multiplying a quantity `w` by `2**k`, where `k` (which may be positive or negative) was computed depending on the particular `x` and `y` values provided. Current algorithms generally take `t1=0.0`, extract the high word, add `k<<20` or `k<<23` to it to appropriately bump the exponent, then overwrite `t1`'s high word. But it seems equally effective to take `t1=0.0`, then write `(1023+k)<<20` or `(127+k)<<23` to it for identical effect -- and `k` is never so negative to compute a negative value. My changes do this. (I wish there were named constants I could use for all these numbers, but as there don't seem to be any, magic numbers seems like the best I can do.) > > Errors in these changes would most likely produce a power of two off by a factor of two, so *probably* testing any inputs that would happen to invoke these code paths should be adequate testing. I'm fixing this in order to upstream a likely fix in the SpiderMonkey JavaScript engine for this, so the (double, double) algorithm/change is the only one I have (purely manually) tested. Eyeballs on the other functions' changes especially appreciated! > > Jeff > _______________________________________________ > freebsd-numerics@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-numerics > To unsubscribe, send any mail to "freebsd-numerics-unsubscribe@freebsd.org" -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191113232233.GA64847>