I guess one should just try to use log1p instead of log(1+x), but I'm not sure how lg+ could be defined with log1p. Note also that lg1+ is defined in terms of log1p (by first exponentiating x).
On Thu, Oct 22, 2015 at 1:41 PM, Alex Knauth <alexan...@knauth.org> wrote: > lg+ and lg- are defined to work with log and exp, but I'm just wondering > if versions of those defined to work with log1p and expm1 would eliminate > some of these errors, by getting rid of the badlands of log and exp? Would > that work? > > > http://docs.racket-lang.org/math/flonum.html#%28def._%28%28lib._math%2Fflonum..rkt%29._fllog1p%29%29 > <http://docs.racket-lang.org/math/flonum.html#(def._((lib._math/flonum..rkt)._fllog1p))> > > > On Oct 20, 2015, at 9:24 AM, Paolo Giarrusso <p.giarru...@gmail.com> > wrote: > > On Tuesday, October 20, 2015 at 12:15:21 PM UTC+2, Laurent Orseau wrote: > > The built-in log-space arithmetic operations are wonderful. (Thanks so > much Neil!) > > It sometimes happens that after some log-operations where the result is > very close to 0 that it actually goes slightly above 0 as a result of > floating point errors, and thus is not a log-probability anymore, which > gave me a few headaches. > > One obvious approach is to surround the result with a check, and if it is > positive but not, say, above 1e-8 then round it down to 0, otherwise raise > an exception if positive. > > But this feels like a hack and I was wondering if there was any "good" way > to ensure that any correct log-space operation remains a log-probability > (i.e., never goes above 0). > > Thanks, > Laurent > > > If lg+ is involved, this discussion in the docs seems relevant — apologies > if you've seen that already: > > http://docs.racket-lang.org/math/flonum.html#%28def._%28%28lib._math%2Fflonum..rkt%29._lg-%29%29 > ? > > After explaining that a good solution is an open research problem, docs > state: > > Further, catastrophic cancellation is unavoidable when logx and logy > themselves have error, which is by far the common case. [...] There are > currently no reasonably fast algorithms for computing lg+ and lg- with low > relative error. For now, if you need that kind of accuracy, use > math/bigfloat. > > > Disclaimer: not an expert here, might well be missing something. > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
