© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
7020100
(Get the code!)
Bernard,
BC is quit consistent. Your example doesn't clearly show what's wrong. People are not very good at reading base-22 output. So I suggest that you keep the input and output base the same....
bc 1.06
ibase=16
obase=10
.126
.122
Note that I set the output base to "10" which, because I've already changed the input base, means "16(decimal)". (you could also do: obase=16 ; ibase=16; Which for first-timers is clearer than my way of doing things. After getting used to my way, I prefer "obase=10", because that guarantees that input and output base are the same... )
What I suspect is that internally bc works base-10. So when I type .126, this is converted to base-10 with (incorrectly) 3 digits behind the hex-point (it in't a decimal point :-) )
So 0.126 (hex) becomes 0.071 decimal while in fact it should be: .07177734375 (it isn't even rouding correctly!)
Converting .07177734375 from decimal to hex gives .126 (correct) while .071(dec) becomes 0.122(hex).
OK. I just found another one. Even more significant.
with input base set to decimal (10), 4*a(1) yields 4 * atan (1) = PI = 3.14. Which, in hex is written 3.24 (i haven't checked it, but it's about right). If I set the input base to 16, (hex), 1 remains 1. 4 remains 4, but a(1)*4 makes pi come out just below two: 1.E1 !