Linux-man Archive on lore.kernel.org
 help / color / Atom feed
* PRINTF(3) Miswriting
@ 2020-05-16 22:04 Rohit Saily
  2020-05-18 15:38 ` Jakub Wilk
  0 siblings, 1 reply; 3+ messages in thread
From: Rohit Saily @ 2020-05-16 22:04 UTC (permalink / raw)
  To: mtk.manpages; +Cc: linux-man

To whom it may concern,


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, instead of specifying the outcome is
always the case. This is why I suspect that this
was a case of miswriting.

Did this sentence mean to state that the digit before the decimal
point is unspecified if the number is normalized, otherwise it is
specified? I pose this because the digit cannot be deduced if the
number is not normalized but it can be deduced if the number is
normalized (by definition). I am not familliar with the details since
I am currently trying to learn them, so please let me know if
something else was meant by the sentence in question.


Thank you for your time,

Rohit Saily

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: PRINTF(3) Miswriting
  2020-05-16 22:04 PRINTF(3) Miswriting Rohit Saily
@ 2020-05-18 15:38 ` Jakub Wilk
       [not found]   ` <CAEYDfj4TK2Maoaxudhfxkx9NJGJa4CNL30Rhud-eBUnHVpFvzw@mail.gmail.com>
  0 siblings, 1 reply; 3+ messages in thread
From: Jakub Wilk @ 2020-05-18 15:38 UTC (permalink / raw)
  To: Rohit Saily; +Cc: Michael Kerrisk, linux-man

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: PRINTF(3) Miswriting
       [not found]   ` <CAEYDfj4TK2Maoaxudhfxkx9NJGJa4CNL30Rhud-eBUnHVpFvzw@mail.gmail.com>
@ 2020-05-18 19:01     ` Rohit Saily
  0 siblings, 0 replies; 3+ messages in thread
From: Rohit Saily @ 2020-05-18 19:01 UTC (permalink / raw)
  To: Jakub Wilk; +Cc: Michael Kerrisk, linux-man

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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

Linux-man Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-man/0 linux-man/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-man linux-man/ https://lore.kernel.org/linux-man \
		linux-man@vger.kernel.org
	public-inbox-index linux-man

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-man


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git