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 <[email protected]> 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 <[email protected]> > 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
