lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Two kinds of precision loss


From: Greg Chicares
Subject: Re: [lmi] Two kinds of precision loss
Date: Fri, 24 Mar 2017 14:38:30 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0

On 2017-03-23 01:48, Vadim Zeitlin wrote:
> On Thu, 23 Mar 2017 00:27:46 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> I'm not sure a round-trip guarantee is even feasible.
> 
> [...snipping the (seriously) fascinating discussion of numeric curiosities,
>     if I have time, I'll try to return to it later, but for now I'd like to
>     concentrate on just the part about the practical consequences...]

It gets much more fascinating--see the message I just posted. (If it's too
long, read it backwards; but that trivializes it and loses the drama.)

> GC> A round-trip guarantee would forbid casting almost any double to float.
> GC> I think that demonstrates that such a guarantee is too restrictive to
> GC> be useful.
> 
>  Why? AFAICS lmi doesn't use float type anywhere, so why should we bother
> casting double (or anything else) to it?
> 
>  If the problem is difficult, but we don't need to solve it, can't we just
> ignore it altogether? It may be a cowardly strategy, but it doesn't mean
> it's an unwise one...

I don't care at all about type float. I care about weird corner cases that
make good unit tests. Now that I've found one, I'm not going to throw it
away just because it involves that silly float type.

I do care a great deal about type double, and lmi needs to convert between
doubles and integers. If I can solve that problem, I'll probably get a
solution that works for type float as well, at no extra cost.

> GC> >  Pragmatically speaking, my preferred solution would be to not solve 
> this
> GC> > problem at all unless we really have to. So for me the immediate 
> question
> GC> > is: do we need to allow double-to-float conversions in bourn_cast<>?
> GC> 
> GC> Here's the decision tree as I see it:
> GC> 
> GC>  - Abandon the goal that value_cast should convert anything to anything,
> GC>    including floating <-> integral? I'm not willing to do that.
> 
>  It's fine to convert between int and doubles when the value of double
> represents an integer. I am not convinced that we need anything else. I'm
> more than ready to trust you if you say that we do, but are you actually
> sure about this?

I haven't thought about that question in the past couple of days, but
I think you're right: bourn_cast should convert between integers and
integer-valued doubles, while round_to is the proper tool to convert
arbitrary doubles to integer-valued doubles.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]