Re: (log #c(0 1) #c(0 -1)) errors
On 3/21/23 07:20, James Cloos wrote: With 21.2.1 I get: (log #c(0 1) #c(0 -1)) Debugger received error of type: DIVISION-BY-ZERO # Error flushed. gcl, sbcl and ccl all return #C(-1.0 0.0). Probably related. (log #c(0 1)) and (log #c(0 -1)) both signal a division by zero. The answer should be #c(0 1.5707964) and #c(0 -1.5707964), respectively.
Re: bug in (log)
On Sun, Jul 3, 2022 at 8:10 AM James Cloos wrote: > it looks like that bug only harms ratio. bignum integer seems to be ok. > > so aworkarount is, in the caseof a ratio, to take the difference of the > logs of the numerator and the denominator. > This is basically what cmucl does. But you have to be careful if the numerator and denominator are very close to each other. Then you'll take the difference of two logs that are essentially equal and lose lots or precision. IIRC, cmucl doesn't do this if the ratio is close to 1 because then converting to double-float isn't a problem. There are other ways to handle this though, like implementing a log2 function that returns the integer part and the fraction separately so you don't lose too many fraction bits when the numbers are huge. > > -JimC > -- > James Cloos OpenPGP: 0x997A9F17ED7DAEA6 > > -- Ray
Re: least-positive vs least-positive-normalized
Sorry for the delay On Tue, Jan 29, 2019 at 11:08 PM Daniel Kochmański wrote: > Hey, > > > With ecl 16.1.3, I noticed that least-positive-double-float and > > least-positive-normalized-double-float are exactly equal. This is > > allowed, but ecl can work with denormals since (/ > > least-positive-normalized-double-float 10) is printed correctly. > > The reason they are the same is because portable C gives us DBL_MIN at > our disposal (and its counterparts for other floats). > Seems reasonable for portability. > > > > Maybe these two values should be different? > > Maybe we could hardcode other value when ieee-floating-point is in > featuers (fwiw it is an optional build flag). I'm not sure what would > be the right thing here. > I don't know either, but it is a bit weird if you can create and print values that are less than least-positive-double-float. :-) > > > > Or maybe ecl really meant to turn on flush-to-zero so that no > > denormals can > > occur? > > > > ECL signals a floating-point-overflow/underflow conditions unless > disabled by an internal function si:trap-fpe. > You trap on underflow by default? That seems unusual and kind of annoying. > > Regards, > Daniel > > > -- Ray
least-positive vs least-positive-normalized
With ecl 16.1.3, I noticed that least-positive-double-float and least-positive-normalized-double-float are exactly equal. This is allowed, but ecl can work with denormals since (/ least-positive-normalized-double-float 10) is printed correctly. Maybe these two values should be different? Or maybe ecl really meant to turn on flush-to-zero so that no denormals can occur? -- Ray?
