Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #142300

Re: A final word on casting.

Show all headers | View raw

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On Wednesday, March 6, 2019 at 12:33:14 PM UTC-5, Tim Rentsch wrote:
>
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>
>>> On 2/26/19 08:41, James Kuyper wrote:
>>> ...
>>>
>>>> Thinking about it some more in response to your question, I suspect that
>>>> a number slightly less than 1.0 might require slightly more significant
>>>> digits than one slightly higher than 1.0.  However, I don't have time to
>>>> confirm that right now.
>>>
>>> I was on the right track, I just had to go down one order of magnitude.
>>> The following are a consecutive pair of exactly representable double
>>> values:
>>>
>>> 0.100000000000000005551115123125782702118158340454101562500 =>
>>> 0x1.999999999999ap-4
>>> 0.100000000000000019428902930940239457413554191589355468750
>>> == 0x1.999999999999bp-4
>>>
>>> The value exactly half way between them is:
>>> 0.100000000000000012490009027033011079765856266021728515625
>>> == 0x1.999999999999a8p-4
>>>
>>> Therefore,
>>> 0.100000000000000012490009027033011079765856266021728515624 should round
>>> to 0x1.999999999999ap-4, while
>>> 0.100000000000000012490009027033011079765856266021728515626 should round
>>> to 0x1.999999999999bp-4
>>>
>>> Therefore, an implementation needs to read 57 significant digits before
>>> it can determine which way to round either of those constants.  For a
>>> constant starting with
>>> "0.100000000000000012490009027033011079765856266021728515625", it can
>>> switch over to testing whether any of the subsequent digits is non-0,
>>> but only after reading the first 57 significant digits.
>>
>> The number 2**300, which is
>>
>>  20370359763344860[...]40449354381299763336706183397376
>>
>> is exactly reprsentable.  The next representable number is
>> 2**300 + 2**248, so halfway between those is 2**300 + 2**247,
>> which is
>>
>>  2037035976334486[...]79249433607939328930471638728704
>>
>> This gets us up to 91 digits.  Can we do better?
>
> OK - now I see what you mean, and what it is that I missed.  Your
> point would have been clearer if you'd presented such an example in
> the first place, rather than presenting one for which 17 digits were
> sufficient.  Why do you have to be so cryptic?

Here are some things you could have done:

(1) Spent a few minutes (10 or 15 should have been enough)
looking on the web for papers on the subject;  or

(2) Picked two or three floating point values, chosen at random
in the space of representable floating point numbers, rather than
just one value almost smack in the middle of the exponent range;
or

(3) Tried writing a floating point conversion routine yourself,
under the guideline that you be confident it would produce
correct results in all cases.

If you had done any one of those things I think you would have
found out for yourself without my having to be involved at all.
So why didn't you?

> DBL_MAX is at least 1e37 according to the C standard, and is
> 0X1.fffffffffffffP1023 for IEEE double.  1fffffffffffff is
> 9007199254740991, and therefore not divisible by 5, so the decimal
> representation of that value won't have any trailing 0s, and
> therefore neither will the value halfway between that one and the
> previous exactly representable value.  A naive implementation
> would have to store at least 1025 bits of information to determine
> which way to round such a constant.  I won't rule out the
> possibility that a more clever algorithm might reduce the amount
> of storage needed, but I can at last finally see where the claim
> "more than 1000 bits" comes from.
>
> Why couldn't you have said so directly, rather than wasting your
> time and mine going around the back way?

A better question is, considering your history of contentious and
garrulous obtuseness, why should I have bothered responding at
all in the first place?  I must confess I don't have a good
answer to that question.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: A final word on casting. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 23:26 -0800
  Re: A final word on casting. "I Set My Girlfriend's Pantyhose on Fire" <cdalten@gmail.com> - 2019-02-26 03:12 -0800
  Re: A final word on casting. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-26 05:41 -0800
    Re: A final word on casting. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-26 19:00 -0800
      Re: A final word on casting. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-27 06:37 -0800
  Re: A final word on casting. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-28 07:45 -0500
    Re: A final word on casting. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-28 08:20 -0500
    Re: A final word on casting. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-28 15:16 +0000
      Re: A final word on casting. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-01 01:16 +0000
        Re: A final word on casting. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-02 01:10 +0000
    Re: A final word on casting. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-06 08:36 -0800
      Re: A final word on casting. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-03-06 09:04 -0800
        Re: A final word on casting. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-21 11:19 +0000
    Re: A final word on casting. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-06 09:33 -0800
      Re: A final word on casting. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-06 11:19 -0800
        Re: A final word on casting. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-23 10:49 -0700
          Re: A final word on casting. James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-25 12:06 -0700

csiph-web