On Sun, Nov 26, 2017 at 07:51:13PM +0000, kshe wrote:
> Hi,
>
> The following behaviour seems unacceptable to me.
>
> $ dc -e '16dio .C .C0 f'
> .C0
> .B
>
> $ dc -e '8dio .3 .30 .300 f'
> .3000
> .275
> .23
>
> This bug affects all bases other than 10 and increasing the scale with
> the `k' command does not prevent it. The only reliable way to input a
> rational number in these bases is therefore to input an integer first,
> and then divide it by the appropriate factor; alternatively, as
> illustrated above, adding meaningless zeros to the digit expansion can
> help, although I have not verified that this works in all cases nor how
> many zeros would need to be added to guarantee the expected result
> every time.
>
> I could try to provide a patch for this, but I dislike how the current
> code gives special privileges to base 10 at the expense of all the
> others, even though it is supposed to accept input in any base; so my
> patch would probably be deemed too invasive as I would want to change
> too many things at once, including in areas irrelevant to this
> particular issue.
>
> If a less intrusive workaround is not possible, then perhaps at least a
> warning about fractional input being essentially broken in bases other
> than 10 could be added to the manual.
>
> Regards,
>
> kshe
I implemented dc(1) to stay as close as possible to the original dc(1)
and GNU dc(1). Any change in the way fractional numbers are handled
(even though you might consider it broken) will break existing
programs.
-Otto
