linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rohit Saily <rohit@rohitsaily.com>
To: Jakub Wilk <jwilk@jwilk.net>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>, linux-man@vger.kernel.org
Subject: Re: PRINTF(3) Miswriting
Date: Mon, 18 May 2020 15:01:11 -0400	[thread overview]
Message-ID: <CAEYDfj57-whcLRn9OVTbMQz9jJNfCnAnNH9j7RGO8b4AxeUx3A@mail.gmail.com> (raw)
In-Reply-To: <CAEYDfj4TK2Maoaxudhfxkx9NJGJa4CNL30Rhud-eBUnHVpFvzw@mail.gmail.com>

Hi Jakub,


> I believe the wording is correct. The outcome is not always the same:
> the leading digit zero is allowed only for non-normalized numbers.

If I am understanding this correctly, shouldn't the man page say:

"The digit before the decimal point is specified for nonnormalized
numbers, and nonzero numbers but other‐wise unspecified for normalized
numbers."

I replaced the first occurence of "unspecified" with "specified" and
inserted "numbers"
after "nonzero". To make it even simpler:

"The digit before the decimal point is unspecified when the number is
normalized and the digit is zero; otherwise, the digit is specified."

Is this correct?

Also, why is it possible that the following numbers are printed if
the floating-point number is 1.0?

0x8.0p-3
0x4.0p-2
0x2.0p-1

Why are there multiple possibilities if the IEEE 754 standard is being
used? I did not know that was a possibility.


Thank you for your time,

Rohit Saily


On Mon, May 18, 2020 at 2:49 PM Rohit Saily <rohit@rohitsaily.com> wrote:
>
> Hi Jakub,
>
>
> > I believe the wording is correct. The outcome is not always the same:
> > the leading digit zero is allowed only for non-normalized numbers.
>
> If I am understanding this correctly, shouldn't the man page say:
>
> The digit before the decimal point is specified for nonnormalized
> numbers, and nonzero numbers but other‐wise unspecified for normalized
> numbers.
>
> I replaced the first occurence of unspecified with specified and inserted numbers
> after nonzero. To make it even simpler:
>
> The digit before the decimal point is unspecified when the number is
> normalized and the digit is zero; otherwise, the digit is specified.
>
> Is this correct?
>
> Also, why is it possible that the following numbers are printed if
> the floating-point number is 1.0?
>
> 0x8.0p-3
> 0x4.0p-2
> 0x2.0p-1
>
> Why are there multiple possibilities if the IEEE 754 standard is being
> used? I did not know that was a possibility.
>
>
> Thank you for your time,
>
> Rohit Saily
>
>
> On Mon, May 18, 2020 at 11:38 AM Jakub Wilk <jwilk@jwilk.net> wrote:
>>
>> Hi Rohit!
>>
>> * Rohit Saily <rohit@rohitsaily.com>, 2020-05-16, 18:04:
>> >I am having difficulty understanding a sentence in the PRINTF(3) man
>> >page's explanation of the 'a' and 'A' conversion specifiers, more
>> >specifically it is the following sentence:
>> >
>> >>The digit before the decimal point is unspecified for nonnormalized
>> >>numbers, and nonzero but other‐wise unspecified for normalized
>> >>numbers.
>> >
>> >My confusion arises due to the fact that the two posible cases are
>> >described with the same outcome,
>>
>> I believe the wording is correct. The outcome is not always the same:
>> the leading digit zero is allowed only for non-normalized numbers.
>>
>> For example, printf("%a", 1.0) could produce any of these outputs:
>>
>>    0x8.0p-3
>>    0x4.0p-2
>>    0x2.0p-1
>>    0x1.0p+0
>>
>> but not:
>>
>>    0x0.8p+1
>>
>> On the other hand, assuming the IEEE 754 binary64 format,
>> printf("%a\n", 0x0.8p-1022) could produce any of these:
>>
>>    0x8.0p-1026
>>    0x4.0p-1025
>>    0x2.0p-1024
>>    0x1.0p-1023
>>    0x0.8p-1022
>>
>> --
>> Jakub Wilk

      parent reply	other threads:[~2020-05-18 19:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-16 22:04 PRINTF(3) Miswriting Rohit Saily
2020-05-18 15:38 ` Jakub Wilk
     [not found]   ` <CAEYDfj4TK2Maoaxudhfxkx9NJGJa4CNL30Rhud-eBUnHVpFvzw@mail.gmail.com>
2020-05-18 19:01     ` Rohit Saily [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAEYDfj57-whcLRn9OVTbMQz9jJNfCnAnNH9j7RGO8b4AxeUx3A@mail.gmail.com \
    --to=rohit@rohitsaily.com \
    --cc=jwilk@jwilk.net \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).