[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.
- Re: [lmi] Is bourn_cast demonstrably correct? (+PATCH), (continued)
- Re: [lmi] Is bourn_cast demonstrably correct? (+PATCH), Greg Chicares, 2017/03/20
- Re: [lmi] Is bourn_cast demonstrably correct? (+PATCH), Vadim Zeitlin, 2017/03/20
- Re: [lmi] Is bourn_cast demonstrably correct? (+PATCH), Greg Chicares, 2017/03/20
- Re: [lmi] Is bourn_cast demonstrably correct?, Vadim Zeitlin, 2017/03/21
- Re: [lmi] Is bourn_cast demonstrably correct?, Greg Chicares, 2017/03/21
- Re: [lmi] Is bourn_cast demonstrably correct?, Vadim Zeitlin, 2017/03/21
- [lmi] Two kinds of precision loss [Was: Is bourn_cast demonstrably correct?], Greg Chicares, 2017/03/21
- Re: [lmi] Two kinds of precision loss, Vadim Zeitlin, 2017/03/22
- Re: [lmi] Two kinds of precision loss, Greg Chicares, 2017/03/22
- Re: [lmi] Two kinds of precision loss, Vadim Zeitlin, 2017/03/22
- Re: [lmi] Two kinds of precision loss,
Greg Chicares <=
- [lmi] Is DBL_MAX "adjacent" to infinity? [Was: Two kinds of precision loss], Greg Chicares, 2017/03/24
- Re: [lmi] Is DBL_MAX "adjacent" to infinity?, Vadim Zeitlin, 2017/03/24
- Re: [lmi] Is DBL_MAX "adjacent" to infinity?, Greg Chicares, 2017/03/24
- Re: [lmi] Is DBL_MAX "adjacent" to infinity?, Vadim Zeitlin, 2017/03/24