bug-gnulib
[Top][All Lists]
Advanced

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

Re: %a format in tests-ulc*.c


From: Bruno Haible
Subject: Re: %a format in tests-ulc*.c
Date: Sat, 22 Apr 2017 13:11:51 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-72-generic; KDE/5.18.0; x86_64; ; )

Paul Eggert wrote:
> > Why would you consider the expected result "0x1.922p+1" wrong?
> 
> The POSIX spec says "if the precision is missing and FLT_RADIX is a power of 
> 2, 
> then the precision shall be sufficient for an exact representation of the 
> value; 
> if the precision is missing and FLT_RADIX is not a power of 2, then the 
> precision shall be sufficient to distinguish values of type double, except 
> that 
> trailing zeros may be omitted". Since the spec goes to the trouble of saying 
> that trailing zeros may be omitted when FLT_RADIX is not a power of 2, and 
> does 
> not go to this trouble when FLT_RADIX is a power of 2, I inferred that when 
> FLT_RADIX is a power of 2, trailing zeros cannot be omitted.
> 
> Although your interpretation is also plausible, if it is correct then I am 
> puzzled why the "trailing zeros may be omitted" wording is present.

Two different algorithms are involved. The first case is simpler and needs less
wording. The second case involves considering the sequence of consecutive
floating-point numbers of the given format. For example, in IEEE double-float
representation and FLT_RADIX=3, the sequence is

(DECIMAL)          (FLT_RADIX=3)
3.1416015625       
1.001021102001021212212021121202001202200212000111112012201111...p+1
3.1416015625000004 
1.001021102001021212212021121202002120220202021122002022121111...p+1
3.141601562500001  
1.001021102001021212212021121202010102010122112202122102111112...p+1
3.1416015625000013 
1.001021102001021212212021121202011020100112210220012112101112...p+1
3.1416015625000018 
1.001021102001021212212021121202012001120110002000202122021120...p+1
3.141601562500002  
1.001021102001021212212021121202012212210100100011022202011120...p+1
3.1416015625000027 
1.001021102001021212212021121202020201000020121021212212001121...p+1
3.141601562500003  
1.001021102001021212212021121202021112020010212102102221221122...p+1
3.1416015625000036 
1.001021102001021212212021121202022100110001010120000001211122...p+1
3.141601562500004  
1.001021102001021212212021121202100011122221101200120011201200...p+1
3.1416015625000044 
1.001021102001021212212021121202100222212211122211010021121200...p+1
3.141601562500005  
1.001021102001021212212021121202101211002201220221200101111201...p+1
3.1416015625000053 
1.001021102001021212212021121202102122022122012002020111101201...p+1
3.1416015625000058 
1.001021102001021212212021121202110110112112110012210121021202...p+1
3.141601562500006  
1.001021102001021212212021121202111021202102201100100201011210...p+1
3.1416015625000067 
1.001021102001021212212021121202112002222022222110220211001210...p+1
3.141601562500007  
1.001021102001021212212021121202112221012020020121110220221211...p+1
3.1416015625000075 
1.001021102001021212212021121202120202102010111202001000211211...p+1
3.141601562500008  
1.001021102001021212212021121202121120122000202212121010201212...p+1
3.1416015625000084 
1.001021102001021212212021121202122101211221001000011020121212...p+1

With just "the precision shall be sufficient to distinguish values of type 
double"
the spec could be interpreted as if the result must always have the same number
of digits:

(DECIMAL)          (FLT_RADIX=3)
3.1416015625       1.0010211020010212122120211212020012p+1
3.1416015625000004 1.0010211020010212122120211212020022p+1
3.141601562500001  1.0010211020010212122120211212020101p+1
3.1416015625000013 1.0010211020010212122120211212020111p+1
3.1416015625000018 1.0010211020010212122120211212020120p+1
3.141601562500002  1.0010211020010212122120211212020200p+1
3.1416015625000027 1.0010211020010212122120211212020202p+1
3.141601562500003  1.0010211020010212122120211212020212p+1
3.1416015625000036 1.0010211020010212122120211212020221p+1
3.141601562500004  1.0010211020010212122120211212021001p+1
3.1416015625000044 1.0010211020010212122120211212021010p+1
3.141601562500005  1.0010211020010212122120211212021012p+1
3.1416015625000053 1.0010211020010212122120211212021022p+1
3.1416015625000058 1.0010211020010212122120211212021101p+1
3.141601562500006  1.0010211020010212122120211212021111p+1
3.1416015625000067 1.0010211020010212122120211212021120p+1
3.141601562500007  1.0010211020010212122120211212021200p+1
3.1416015625000075 1.0010211020010212122120211212021202p+1
3.141601562500008  1.0010211020010212122120211212021212p+1
3.1416015625000084 1.0010211020010212122120211212021221p+1

The additional sentence "except that trailing zeros may be omitted" means
that it is OK to produce this:

(DECIMAL)          (FLT_RADIX=3)
3.1416015625       1.0010211020010212122120211212020012p+1
3.1416015625000004 1.0010211020010212122120211212020022p+1
3.141601562500001  1.0010211020010212122120211212020101p+1
3.1416015625000013 1.0010211020010212122120211212020111p+1
3.1416015625000018 1.001021102001021212212021121202012p+1
3.141601562500002  1.00102110200102121221202112120202p+1
3.1416015625000027 1.0010211020010212122120211212020202p+1
3.141601562500003  1.0010211020010212122120211212020212p+1
3.1416015625000036 1.0010211020010212122120211212020221p+1
3.141601562500004  1.0010211020010212122120211212021001p+1
3.1416015625000044 1.001021102001021212212021121202101p+1
3.141601562500005  1.0010211020010212122120211212021012p+1
3.1416015625000053 1.0010211020010212122120211212021022p+1
3.1416015625000058 1.0010211020010212122120211212021101p+1
3.141601562500006  1.0010211020010212122120211212021111p+1
3.1416015625000067 1.001021102001021212212021121202112p+1
3.141601562500007  1.00102110200102121221202112120212p+1
3.1416015625000075 1.0010211020010212122120211212021202p+1
3.141601562500008  1.0010211020010212122120211212021212p+1
3.1416015625000084 1.0010211020010212122120211212021221p+1

The algorithm for the second case also applies to the first case, but
no engineer with a sane mind would apply this algorithm to the first case.
Instead every normal programmer will use the direct conversion algorithm
(which does not consider sequences) for the first case.

> Is there 
> some subtle distinction between "sufficient for an exact representation of 
> the 
> value" and "sufficient to distinguish values" that I am not getting?

The first sentence applies to a single value; "sufficient" implies that you can
omit trailing zeroes.

The second sentence can be interpreted as if "sufficient" means a number of 
digits
that is independent of the value.

Bruno




reply via email to

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