On Aug 28, 2015, at 9:50 AM, Gordon Messmer <gordon.messmer at gmail.com> wrote:> > On 08/28/2015 07:15 AM, Mike - st257 wrote: >> Thoughts as to why my BC functions aren't properly converting between bases? >> >> Decimal to binary or hex works fine, but not binary or hex to decimal and >> so forth. > > I'm not an expert in bc, so I might be wrong, but it looks like setting the ibase inside a function is simply too late. ibase affects how bc interprets input.Yes, and it?s a serious design mistake in bc, IMHO. No other programmable system I?ve ever used changes how numbers in program text are interpreted based on prior commands to the system. I wrote a long answer explaining this on the Unix & Linux Stack Exchange here: http://unix.stackexchange.com/a/199620
On Fri, Aug 28, 2015 at 4:14 PM, Warren Young <wyml at etr-usa.com> wrote:> On Aug 28, 2015, at 9:50 AM, Gordon Messmer <gordon.messmer at gmail.com> > wrote: > > > > On 08/28/2015 07:15 AM, Mike - st257 wrote: > >> Thoughts as to why my BC functions aren't properly converting between > bases? > >> > >> Decimal to binary or hex works fine, but not binary or hex to decimal > and > >> so forth. > > > > I'm not an expert in bc, so I might be wrong, but it looks like setting > the ibase inside a function is simply too late. ibase affects how bc > interprets input. >Thanks Gordon. Big bummer given that behavior. :-/ I had (and did test) definitions for other conversions (though I didn't post them), but this one also drives it home. ~]$ grep bin_to_hex ~/.bcrc define bin_to_hex(b) { obase=16; ibase=2; return b; } ~]$ echo "bin_to_hex(10101011)" | bc 9A2113 # so we're sending in a string with implied base10 ... sure enough matches what BC errantly decided to do ~]$ echo "obase=16; 10101011" | bc 9A2113 ~]$ echo "obase=16; ibase=2; 10101011" | bc AB> > Yes, and it?s a serious design mistake in bc, IMHO. No other programmable > system I?ve ever used changes how numbers in program text are interpreted > based on prior commands to the system. > > I wrote a long answer explaining this on the Unix & Linux Stack Exchange > here: > > http://unix.stackexchange.com/a/199620 > >Thanks Warren. The order of obase and ibase definitely are bizarre and tripped me up the first time around. I expected I should set ibase first and no no no that was not the case! ;-) To all: I suppose my only options for this are to use shell functions or write a script using a language that handles things properly (sanely?). Thanks for the input everyone! Best, -- ---~~.~~--- Mike // SilverTip257 //
On Aug 31, 2015, at 6:55 AM, Mike - st257 <silvertip257 at gmail.com> wrote:> > I suppose my only options for this are to use shell functions or write a > script using a language that handles things properly (sanely?).No, there?s a fairly common hack around this problem: ibase=A and obase=A *always* means ?base 10? regardless of the current base, due to a quirk in the way values for these settings are interpreted. Thus you can always force your way back to sanity. My objection is that this is even necessary in the first place.
On 08/31/2015 05:55 AM, Mike - st257 wrote:>>> I'm not an expert in bc, so I might be wrong, but it looks like setting >> >the ibase inside a function is simply too late. ibase affects how bc >> >interprets input. >> > > Thanks Gordon. > Big bummer given that behavior. :-/I suppose that depends on what you're trying to accomplish. Most conversions you can do entirely within bash, if that's your goal. function dec_to_hex () { printf '%x\n' $1; } function hex_to_dec() { printf '%d\n' $(( 16#$1 )); } function hex_to_bin() { echo 'obase=2;' $(( 16#$1 )) | bc; } $ dec_to_hex 10 a $ hex_to_dec a 10 $ hex_to_bin a 1010