dc(1) bugs

[Jon Radel]

On 1/13/16 2:18 PM, Christian Weisgerber wrote:
> Simpler examples:
>
> $ dc -e '50k 16i .1 p'
> 0.0
> $ dc -e '50k 16i .10 p'
> .06
> $ dc -e '50k 16i .100 p'
> .062
> $ dc -e '50k 16i .1000 p'
> .0625
>
> I'll note that GNU dc(1) behaves the same way, so I think it is a
> case of poorly documented or counter-intuitive behavior rather than
> a bug.
The man page makes clear, in a slightly muddy sort of way, that scale 
set with the "k" operator can set limits on the scale of the output, but 
is not deterministic.  See the section on the ordinary arithmetic 
operators.  Base conversion, apparently, ignores the scale set with 
"k".  A bit clumsy, IMHO; for starters, 4 digits of precision in hex 
isn't exactly 4 digits of precision base 10.

Clumsy?  Well, I'd think that

$ dc -e '50k 16i .10 .1 + p'
.06
$

should really output .12, but there is a certain logic to the answer it 
does give if one assumes it converts base first and then adds.

For an example where "k" does something:

$ dc -e '3k 16i .10000 .10000 * p'
.00390
$ dc -e '6k 16i .10000 .10000 * p'
.003906
$

Bottom line?  dc might not be the best tool for hex fractions.  :-(

--Jon Radel
jon at radel.com



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3890 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20160113/1b04b079/attachment.bin>