11 Sep
2014
11 Sep
'14
9:24 p.m.
Hello,
on de.comp.os.unix.shell there is a recent thread about bc(1) which
turned into a discussion about why it is called "bc". dc(1) is pretty
clearly "desk calculator" as by the man page, but the etymology of bc
seems to be unclear.
I've heard the following plausible theories:
- basic calculator (Wikipedia)
- beauty calculator (some people apparently dislike RPN)
- better calculator
- bench calculator (Wikipedia)
- b is the letter d mirrored (RPN vs algebraic)
- bundle calculator (the word "bundle" appears 97 times in bc.y of V6)
...but nobody had a really conclusive argument. Perhaps someone here
remembers the real story?
Thanks,
--
Christian Neukirchen <chneukirchen(a)gmail.com> http://chneukirchen.org
11 Sep
11 Sep
9:41 p.m.
On Sep 11, 2014, at 3:24 PM, Christian Neukirchen <chneukirchen(a)gmail.com> wrote:
Hello,
on de.comp.os.unix.shell there is a recent thread about bc(1) which
turned into a discussion about why it is called "bc". dc(1) is pretty
clearly "desk calculator" as by the man page, but the etymology of bc
seems to be unclear.
I've heard the following plausible theories:
- basic calculator (Wikipedia)
- beauty calculator (some people apparently dislike RPN)
- better calculator
- bench calculator (Wikipedia)
- b is the letter d mirrored (RPN vs algebraic)
- bundle calculator (the word "bundle" appears 97 times in bc.y of V6)
...but nobody had a really conclusive argument. Perhaps someone here
remembers the real story?
I’d always heard ‘binary calculator’ but I don’t have a good reference for that.
Warner
10:04 p.m.
On Thu, 11 Sep 2014, Warner Losh wrote:
I?d always heard ?binary calculator? but I don?t have
a good reference
for that.
I've heard "binary" because it used binary arithmetic (and limited
precision), and "basic" because it was a lot simpler than "dc" (which
I've
always thought was "decimal" calculator due to it using arbitrary
precision decimal arithmetic).
-- Dave
10:17 p.m.
Dave Horsfall scripsit:
That can't be right. Bc was just an overlay to dc that parsed bc
language, compiled it into dc language, and fed dc from a pipe (all the
output was direct from dc). So the arithmetic capabilities were exactly
the same.
I note that bc first appeared just about when bas(1) disappeared, so
perhaps there is a connection in their names.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
In the sciences, we are now uniquely privileged to sit side by side
with the giants on whose shoulders we stand. --Gerald Holton
I?d always
heard ?binary calculator? but I don?t have a good reference
for that.
I've heard "binary" because it used binary arithmetic (and limited
precision), and "basic" because it was a lot simpler than "dc" (which
I've
always thought was "decimal" calculator due to it using arbitrary
precision decimal arithmetic). 
11:34 p.m.
Well, Doug McIlroy would probably know definitively, but my memory is that
it was called "bc" because it was written by Bob Morris (senior)--thus,
Bob's calculator.
Steve
12 Sep
12 Sep
1:03 a.m.
On Thu, 11 Sep 2014, John Cowan wrote:
Hey, I never made any claim as to its veracity, and I lost my old manuals
in a house move.
On the *nix systems to which I have access, bc(1) is a standalone
program on FreeBSD and OSX, but pipes to dc(1) on OpenBSD. I cannot
check my Penguin box (Ubuntu) because its keyboard died, and I didn't
set up remote access to it.
All boxen say "arbitrary-precision arithmetic language and calculator" or
variants thereof.
-- Dave
I've
heard "binary" because it used binary arithmetic (and limited
precision), and "basic" because it was a lot simpler than "dc" (which
I've always thought was "decimal" calculator due to it using arbitrary
precision decimal arithmetic).
That can't be right. Bc was just an overlay to dc that parsed bc
language, compiled it into dc language, and fed dc from a pipe (all the
output was direct from dc). So the arithmetic capabilities were exactly
the same. 
1:37 p.m.
On Thu, Sep 11, 2014, at 21:03, Dave Horsfall wrote:
On the *nix systems to which I have access, bc(1) is a
standalone
program on FreeBSD and OSX, but pipes to dc(1) on OpenBSD.
What language does the undocumented option (assuming it is supported at
all) "bc -c" generate on FreeBSD and OSX? "Standard" bc, which
actually
pipes to dc, generates (obviously) dc when run in this way, but GNU bc
generates a completely different and as far as I know undocumented
language, which is handled by the execute function (in execute.c) but as
far as I know there is no way to make it accept it on standard input.
Standard bc:
$ echo '2+2' | bc -c
2 2+ps.
q$
GNU bc:
$ echo '2+2' | bc -c
@iK2:K2:+W@r
@i
$
(the @i and @r pseudo-instructions are printed separately from the
generated code when in -c mode [util.c], and are not part of the
language passed to the execute function.)
2:18 p.m.
On Fri, 12 Sep 2014, random832(a)fastmail.us wrote:
What language does the undocumented option (assuming
it is supported at
all) "bc -c" generate on FreeBSD and OSX? "Standard" bc, which
actually
pipes to dc, generates (obviously) dc when run in this way, but GNU bc
generates a completely different and as far as I know undocumented
language, which is handled by the execute function (in execute.c) but as
far as I know there is no way to make it accept it on standard input.
Standard bc:
$ echo '2+2' | bc -c
2 2+ps.
q$
GNU bc:
$ echo '2+2' | bc -c
@iK2:K2:+W@r
@i
$
FreeBSD 10:
$ echo '2+2'|bc -c
2 2+ps.
q$
(yeah, I run ash... I got a chroot with Debian and the different userlands
would cause conflict if I defaulted to bash)
-uso.
8:02 p.m.
On Fri, 12 Sep 2014, random832(a)fastmail.us wrote:
What language does the undocumented option (assuming
it is supported at
all) "bc -c" generate on FreeBSD and OSX? "Standard" bc, which
actually
pipes to dc, generates (obviously) dc when run in this way, but GNU bc
generates a completely different and as far as I know undocumented
language, which is handled by the execute function (in execute.c) but as
far as I know there is no way to make it accept it on standard input.
According to my trusty Mac:
DIFFERENCES
This version of bc was implemented from the POSIX P1003.2/D11 draft and
contains several differences and extensions relative to the draft and
traditional implementations. It is not implemented in the traditional
way using dc(1). This version is a single process which parses and
runs a byte code translation of the program. There is an "undocu-
mented" option (-c) that causes the program to output the byte code to
the standard output instead of running it. It was mainly used for
debugging the parser and preparing the math library.
My trusty FreeBSD box says the same thing. Well, they're both Gnu 1.06,
after all, and it's some sort of byte-code. I can sort see how it works;
single digit integers, unless wrapped by "Knnn:" etc..
Standard bc:
$ echo '2+2' | bc -c
2 2+ps.
q$
GNU bc:
$ echo '2+2' | bc -c
@iK2:K2:+W@r
@i
$
Oops; a "1" stands for itself, but other ints are bracketed:
davehorsmacbook:~ dave$ bc -c
@ibc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
1+1
11+W@r
@i2+2
K2:K2:+W@r
@i
Amusing that it treats "1" and "not 1" differently. Oh, and
"0" stands
for itself. One more test:
00+W@r
@i-1+1
1n1+W@r
So, that's something like "1 negate 1 add" - gasp, that's RPN!
I'd check
the sources if I had them (none for Mac, and I didn't bother with FBSD).
-- Dave
3517
days inactive
3518
days old
8 comments
7 participants
participants (7)
-
Christian Neukirchen -
Dave Horsfall -
John Cowan -
random832＠fastmail.us -
scj＠yaccman.com -
Steve Nickolas -
Warner Losh