From Newsgroup: comp.lang.awk
On Friday, April 1, 2022 at 4:33:13 AM UTC-4, Janis Papanagnou wrote:
On 29.03.2022 03:20, Kpop 2GM wrote:
@Janus :
isn't that PROCINFO prec-max thing for MPFR-only max prec ?
gawk-with-GMP's max exponent is approximately 2^36/37 ?
used to be +/- 2^30 i guess they upped it
You're replying to an old Usenet post and without context I cannot
see to what you were actually referring to and what concrete issue
your reply is supposed to address.
Janis
No I actually read the thread first.
you wanna operate on them ? sure :
gawk -nMbe '{ print PROCINFO["prec_max"]-1 }'
9223372036854775807
As for shifting, there's no inconsistency - you're still only getting double-mantissa worth of precision.
% gawk -Mnbe '{ print PROCINFO["prec_max"]-1; print sprintf("%.16X",or(7223372068549377581,1999)) }' <<<'';
% gawk -be '{ print sprintf("%.16X",or(7223372068549377581,0)) }' <<<''
% gawk -be '{ print PROCINFO["prec_max"]-1; print sprintf("%.16X",or(7223372068549377581,1999)) }' <<<''
9223372036854775807
643E92A0125D 3FEF
643E92A0125D 4000
001E92A0125D 47CF
9223372036854775808
1999 contributes the 7CF. bit-wise OR function took the best 52-bits of each input, OR them in a 64-bit fashion, then give you the lower 1+52 in the end.
print sprintf("%.16X",lshift(7223372068549377581,0)) }' <<<''
643E92A0125D4000
Same with shifting - the precision is already lost even upon input, before any shifting occurs. You're just shifting those same 52-bits.
prec_min of 2 ?
if it's less than 2, then what exactly do you want to do with a 1-bit wide exponent, especially when considering it still needs to reserve space for NaN and InF.
--- Synchronet 3.19c-Linux NewsLink 1.113