FreeBSD-9.3 dc(1) ##### FIRST ##### $ dc -xe '50k16o16i.1vp' 0 $ dc -xe '50k10o16i.1vp' 0 $ dc -xe '50k10o10i.1vp' [0].31622776601683793319988935444327185337195551393252 This should be telling dc(1): a) scale is 50 (in decimal) digits. b) output in base16, base10, and base10 respectively. c) input will be in base16, base16, and base10 respectively. d) take the square root, and print it to the display. Of course, the 3rd example above is correct, but the first 2? Why 0? ###### SECOND ###### $ dc -xe '50k16o16i.4 2^p' [0].0A $ dc -xe '50k16o16i.0Avp' [0].2C572B0D5A1443EC508B9E24D8DF392750959EE138 This should be telling dc(1): a) scale is 50 (in decimal) digits. b) output in base16, input is now base16. c) square "0.4", and print it to the display (result=0.0A). d) take the square-root of "0.0A", and print it to the display. Of course, the square-root of a squared number should result in the orginal number. But, this is not happening. ##### THIRD ##### $ dc -xe '50k16o16i.4 2^p' [0].0A $ dc -xe '50k16o16i.40 2^p' [0].1000 $ dc -xe '50k16o16i.400 2^p' [0].10000 $ dc -xe '50k16o16i.4000 2^p' [0].1000000 dc(1) is supposed to be precise in the digits it calculates, but here? Something is not right about these results, or so it appears to me. ###### FOURTH ###### $ dc -xe '50k16o16i.1vp' 0 $ dc -xe '50k16o16i.10vp' [0].3EB4F9D9B6D094C33D38373D38777A7D9233A1B0FB $ dc -xe '50k16o16i.100vp' [0].3FBE55183CA5ADC8B39B27C6258E4C7E64338B909F $ dc -xe '50k16o16i.1000vp' [0].400000000000000000000000000000000000000000 Checking the result of the THIRD example, dc(1) is not outputting to the scale specified, and despite having all a scale of 50, they are all giving different results with inputs having a scale of only 1/2/3/4; Something seems broken to me. -- GNU's dc(1) is broken too (reported to GNU bc maintainer also): Thanks! I really needed a calculator to do squares and square-roots of hexadecimal fractions, and I use FreeBSD, but their dc(1) is broken too ... http://lists.freebsd.org/pipermail/freebsd-questions/2016-January/269999.html http://lists.freebsd.org/pipermail/freebsd-bugs/2016-January/065825.html I would assert scale is the number of fractional digits displayed regardless of any base. Why should anyone care about base10 or whatever other base the dc(1) author decided to assign as an across-the-board base for the scale value? That makes no sense at all for a user of dc(1). Scale is the number of fractional digits the dc(1) user wants, not what the author of dc(1) decided secretly for everybody. I don't think it was ever intended to be the "base10" fractional digits only, or whatever other scale was used "behind the scenes". Scale is a "user demand" for the result, IMHO. A modern computer should have a working calculator - at least, I think so. Thank you so much for your reply, I have some encryption-related software that depends on it. > On Tuesday 12 January 2016 23:05:41: > > > dc (GNU bc 1.06.95) 1.3.95 > > > > $ dc -e '50k16o16i.4vp' > > [0].727C9716FFB764D594A519C0252BE9AE6D00DC9192 > > > > This is not a 50-digit scale. > > It is a 50 digit scale base r10 which is of course shorter base r16. > > > $ dc -e '50k16o16i.727C9716FFB764D594A519C0252BE9AE6D00DC9192 2^p' > > [0].333333333333333333333333333333333325CC2DCA > > > > This is not even close to being the original number: 0.4. > > This appears to be true. I'll investigate why the algorithm is wrong.
The problem is simpler than you suggest. It looks like fractional input doesn't work correctly when the input base is 16. Try this: $ dc -xe 16i0.1p 0.0 $ dc -xe 16i0.8p .5 $ dc -xe 16i0.4p .2 The first and third results are wrong, and the second result is correct. I get the same results with both the FreeBSD and the GNU versions of both bc(1) and dc(1). I suspect the problem is that some number is being treated as an integer in units of base^n for n < 0 _before_ conversion to a bignum. That would explain these three results, for n=-1.
FWIW, OpenBSD has recently documented the bug: https://github.com/openbsd/src/commit/07a84ed5d032f8944e094f78671ca22370d85d94#diff-5b6538785ff0a1cae35f0be94d4853ce
A commit references this bug: Author: asomers Date: Tue Dec 5 04:22:36 UTC 2017 New revision: 326556 URL: https://svnweb.freebsd.org/changeset/base/326556 Log: dc(1): fix input of non-decimal fractional numbers Inputting fractional non-decimal numbers has never worked correctly in our OpenBSD-derived dc(1). It truncates the input to a number of decimal places equal to the number of hexadecimal (or whatever base) places given on the input. That's unacceptable, because many numbers require more precision to represent in base r10 than in their original bases. Fix this bug by using as many decimal places as needed to represent the input, up to the maximum of the global scale factor. This has one mildly surprising side effect: the scale of a number entered in non-decimal mode will no longer necessarily equal the number of hexadecimal (or whatever base) places given on the input. I think that's an acceptable behavior change, given that inputting fractional non-decimal numbers never worked in the first place, and the man page doesn't specify whether trailing zeros on the input should affect a number's scale. PR: 206230 Reported by: nibbana@gmx.us Reviewed by: pfg Differential Revision: https://reviews.freebsd.org/D13336 Changes: head/etc/mtree/BSD.tests.dist head/usr.bin/dc/Makefile head/usr.bin/dc/bcode.c head/usr.bin/dc/bcode.h head/usr.bin/dc/extern.h head/usr.bin/dc/inout.c head/usr.bin/dc/mem.c head/usr.bin/dc/tests/ head/usr.bin/dc/tests/Makefile head/usr.bin/dc/tests/inout.sh