[libre-riscv-dev] [isa-dev] Re: FP transcendentals (trigonometry, root/exp/log) proposal

[Hendrik Boom]

On Thu, Jan 16, 2020 at 02:21:03AM -0800, Jacob Lifshay wrote:
> On Thu, Jan 16, 2020, 02:00 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
> 
> > On Thursday, January 16, 2020, Jacob Lifshay <programmerjake at gmail.com>
> > wrote:
> >
> > > On Thu, Jan 16, 2020, 01:22 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> > > wrote:
> > >
> > > > On Thursday, January 16, 2020, <whygee at f-cpu.org> wrote:
> > > >
> > > > > On 2020-01-16 04:04, lkcl . wrote:
> > > >
> > > >
> > > >
> > > > > the time (let alone rounding).  how do you *know* when the rounding
> > (or
> > > > the
> > > > >> last bit of the mantissa) is wrong?
> > > > >>
> > > > >
> > > > > That was my reaction :
> > > > > if you *know* your LSB is wrong then you can correct it...
> > > >
> > > >
> > > > ... or can you? this is what i'm fascinated to hear about, mitch.
> > > >
> > > > is there some mathematical way in which the accuracy can be computed
> > yet
> > > > the effort not known?
> > > >
> > >
> > > Yes. you just compute the output to a few more bits where the output is
> > > known to always be within a certain distance of the correct output,
> >
> >
> > sorry to be sounding dumb: the question thus becomes, "how do you know when
> > the output is always within a cer... etc etc " :)
> 
> 
> when approximating a mathematical function, you get an approximate output
> xa and you know by error analysis that the true mathematical output x is
> within distance delta of xa: x is in [xa - delta, xa + delta]
> 
> So, to round, you just find the nearest spot xt to xa where the rounded
> output would change (so, for round to nearest, xt is halfway between
> rounded outputs), then:
> If xt is in [xa - delta, xa + delta], then the rounded result could be
> incorrect because you don't know if x is less, equal, or more than xt.
> Otherwise, the rounded result is known to be correct because comparing xa
> to xt always gives the same answer as comparing x to xt.

In theory, there's no bound on the number of bits of an arbitrary real 
number you have to compute for correct rounding -- you might just always 
find that xt is still withing delta of xa.

But at least this test can punt the problem to software.  Ultimately,
the application will have to decide what is close enough.

A numerical analyst once told me the real reason for last-bit accuracy.
It appears a number of common numerical algorithms converge if the 
computed functions they use have the right monotonicity properties.  
Otherwise they may loop forever.  And one of the easiest ways to achieve 
monotonicity is last-bit accuracy.

-- hendrik

> 
> Jacob
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev