Looking through my site logs, I realise that many people who find the GNU bc page are looking for something that isn't there, or they don't see it immediately when the page loads, so they think it's not there. The purpose of this page, despite it being practically verbatim from its predecessor, is here to help rectify that.
Without further ado,and in no particular order, here are some of the questions asked of search engines that people haven't found the answer to on the GNU bc page:
I reckon this is a trick question - do you guys want to use bc or not? :) Okay... Lets assume both and work from there:
You really honestly and truthfully don't want to do this, surely? The bash shell is only capable of integer arithmetic, so even if you could take a square root, you'll only get the integer portion of the answer... i.e. sqrt(10) = 3 to the nearest whole number. If that's all you need, then this shell function is for you:
sqrt() { local x=$1 s=$1 os=0;while ((s!=os));do os=$s;s=$(((s+x/s)/2));if((s>os));then s=$os;fi;done;echo $s; }
That's all on one line.
Once you've entered the above into a script or your interactive session, the command
sqrt {number} will output the square root of {number}. e.g.
sqrt 123456 will print 351.
Be warned though, the above contains no checking for negative numbers, and so the function just returns the same negative number!
The simplest way to do this is to pipe some bc syntax to bc -l:
echo 'sqrt({number})' | bc -l
...making the obvious replacement of {number}. Yes. It's that simple!
If you've been paying attention class, the answer to this has already been used in the previous answer!
bc has its own built in sqrt() function. You don't even need to
include the standard library - it's right there when you run the program... Which leads
us on to the next question...
It concerns me greatly the number of people who don't know about the scale
variable in bc. With scale, the number of decimal places of
floating point precision can be set. Including the standard library (with the
-l flag) automatically sets the scale to 20. This site's
funcs.bc library sets the same to 50 for increased accuracy.
For instance; The example from the question before last might have been written:
echo 'scale=20;sqrt({number})' | bc
Note the lack of the -l flag this time. Also; Changing that 20 will change
the number of decimal places in the answer printed.
Again... not sure whether the requestor wants bash or bc code, so it's twice the work for me :):
Bearing in mind that bash is integer-only, this shell function will return the rounded down logarithm in bash:
log(){ local x=$1 n=2 l=-1;if [ "$2" != "" ];then n=$x;x=$2;fi;while((x));do let l+=1 x/=n;done;echo $l; }
As before, it's all on one line.
Once you've entered the above into a script or your interactive session, the command
log {number} will output the logarithm of {number} to base 2.
e.g. log 123456 will print 16 (even though the log to base 2
of 123456 is nearer to 17!)
The 'clever' bit is that the command log {n1} {n2}
will output the logarithm of {n2} to base {n1}, so log 10 10000
will print 4, and log 3 9923 will print 8, etc.
Beware again - this works only when fed positive integers. Anything else is not checked for and may cause this function to behave bizarrely.
Guess what? You can pipe some bc syntax to bc -l!:
echo 'l({number})' | bc -l
or
echo 'l({n1})/l({n2})' | bc -l
...making the obvious replacements.
If you've been paying attention class, the answer to this has already been used in the previous answer! (If you're really paying attention you'll also notice I've copied and pasted that sentence from the square root question.)
bc's standard library, accessible by using the -l commandline switch
contains the l() function which returns the natural logarithm of its
parameter. The above question shows examples of how to use it to obtain logarithms
to other bases.
This site's funcs.bc library contains a more robust
log() function which supplements the standard library version.
The easiest way to do a cube root in bc is to use the cbrt() function
that - due to popular demand - can be found in this site's
funcs.bc library.
Also, pow({number},1/3) and
root({number},3) can both be used to achieve the required result.
The above functions are, at least in part, based on the following:
This line should be all you need
echo 'e(l({number})/3)' | bc -l
This works on the mathematical principle that:
n√x = x(1/n) = e(ln x)/n
The above trick can be included in a function, like so:
define qcbrt(x) { return e(l(x)/3)) }
And then use it as you would the built in sqrt().
As you might guess, the e() and l() used above are the
GNU bc exponential and natural logarithm functions respectively. Both are only
available as part of the standard library, so the -l flag is absolutely
essential for them to be usable.
You should be aware that the accuracy of this quick and dirty cube root function,
and indeed many a function written in bc, is directly affected by the value of the
scale variable.
If you've found your way across the internet to this question, chances are you're
looking for bc's equivalent of C's ^ operator.
Disturbing fact: no such thing exists in bc.
In bc, the up-arrow operator is used for integer exponentiation, that is, 2^x returns a power of 2 and not x with bit 2 flipped. If you're looking for equivalents to the bitwise operators for XOR as well as AND, OR and a few more exotic relatives, check out this site's logic.bc, and its relatives which contain functions to perform each of these.
If you're looking for a logical XOR to put in an if statement, like
logical && and ||, try using != and surrounding
your conditions with brackets. e.g.:
c=0;if((a==1)!=(b==2)){c=3}
Will set c to 3, if a is 1 or b is 2, but not if a is 1 and b is 2 at the same time
(Once upon a time, this was the secret to the internals of the
logic.bc xor() function,
but this has been superseded by a faster algorithm.)
When performing some - usually division-related - calculations in bc, especially
with the scale variable set high, the answer returned
to the console (or stored in a variable) has many trailing zeroes at the end. e.g.
the code scale=20;7/4 will cause 1.75000000000000000000
to be printed as the result.
Often this is cumbersome and makes 'obvious' numbers harder to read. The solution is the following function:
define trunc(x){auto os;os=scale;for(scale=0;scale<=os;scale++)if(x==x/1){x/=1;scale=os;return x}}
With this function you can say things like scale=20;q=7/4;q=trunc(q);q or
simply scale=20;trunc(7/4), both of which will print 1.75 as
expected.
An improved version of this, which can also deal with trailing 9's (in decimal) can be
found in output_formatting.bc, and this also
contains many other output formatting functions, including two similar to C's
printf().
Ouch. There are a number of ways to do this, and for once, bc might not be your best option depending on whether you literally have a list of numbers, or your list of numbers is a column in some larger design.
I had no idea how to do this myself until I looked into it; I usually use the method below this one. Nonetheless this seems to do the trick:
add_col() { local t;while read -a cols; do t=$((t+${cols[$1]%%.*})) ; done ; echo $t; }
You can use this function by saying add_col number < filename
or some_command | add_col number, and the function will add the
numbers in the specified column number, starting with zero for the leftmost.
Examples:
echo -e "1 4\n2 4\n4 44\n5 4" | add_col 0 # prints 12 as this is the sum of 1, 2, 4 and 5
echo -e "1 4\n2 4\n4 44\n5 4" | add_col 1 # prints 56 as this is the sum of 4, 4, 44 and 4
Caveat #1 bash is only capable of integer arithmetic and so this deliberately chops
anything off column entries that looks like a decimal point.
That's what the funky ${ %%.*} business is all about.
Caveat #2 this will choke if your column of numbers contains something that isn't actually a number.
If your system has bash and bc, you'll probably also have something called awk installed. If so, you can do something like this:
awk '{t+=$number}END{printf"%f\n",t}' < filename
This works the same way as the bash-only example above, except it's shorter, neater, and copes better with decimal points and errant data.
N.B. awk numbers columns from 1 and not 0 like our more home-brewed examples here.
This is one possible way to do it. Here's a variant of the add_cols command
we used above:
add_col() { local t="0";while read -a cols; do t="$t+${cols[$1]}" ; done ; echo $t | bc ; }
If the above question doesn't give you what you're after, you might want to check out the official GNU-bc manual's embedded checkbook program example. The link should take you to that section of the manual.
If you want to perform int(), floor(), ceil() (or ceiling)
functions in bc, then it's completely possible. Check out the first few functions in this site's
funcs.bc library.
There is no simple way to initialise an array in bc. For example:
a[] = {14, 14, 21, 35, 17, 32, 5, 8, 8} # ... does not work ...
... and so each value must be set separately. Loops may be used, of course, but the above line, having no easily programmed pattern (even though there is a pattern there) is best initialised like so:
a[0]=a[1]=14;a[2]=21;a[3]=35;a[4]=17;a[5]=32;a[6]=5;a[7]=a[8]=8
Note that some shorthand can and has been used for matching values.
There are two functions in this site's array.bc which can be
used for the purpose if required, aset8() and aset16(), setting 8
and 16 elements respectively. e.g. the above example might be written:
.=aset16(a[],0 , 14, 14, 21, 35, 17, 32, 5, 8, 8, 0, 0, 0, 0, 0, 0, 0);
The first 0 represents the first index of a[] that is to be set.
The remaining zeroes are there to fill out the required number of parameters of the
function.
bc always displays the result of a calculation on screen, which can be a problem when
calling a function which is to remain silent. The way to do this is to assign the result
of whatever is causing output into a dummy variable, or even bc's built in
'last calculated value' variable which is the period / full stop character: .
.=printroman(x)+newline() # for example
GNU bc also allows the use of the word last for this value, but the
.= method is much neater. Much of the printing / output code in these
libraries takes advantage of this trick.
At present the only way to do anything like it is to have one function rely on another with a specific name, and then redefine that specifically named function as required. This technique is used by the code in intdiff.bc to allow the numerical integration and differentiation to be able to operate on different functions.
This is useful, but since a function cannot be redefined from within another function, this makes using the generic function as a template somewhat difficult. Only the most recently defined version of the specifically named function would be active. The following, for example, will not work as expected:
define generic_() { return 1/f(x) } # expects f() to exist
define f(x) { return sin(x) }
define cosec(x) { return generic_(x) }
define f(x) { return cos(x) } # redefines f()
define sec(x) { return generic_(x) }
Immediately after this code, cosec() will behave identically to
sec(), which would be incorrect! Instead it would be nice to say
something like:
define generic_(*f()) { return 1/f(x) } # syntax error
define cosec(x) { return generic_(*sin()) } # nope
define sec(x) { return generic_(*cos()) } # invalid