search for: bin_to_hex

On Aug 31, 2015, at 10:05 AM, Mike - st257 <silvertip257 at gmail.com> wrote: > > On Mon, Aug 31, 2015 at 11:15 AM, Warren Young <wyml at etr-usa.com> wrote: > >> ibase=A and obase=A > > Not sure how this helps me with my most recent example of bin_to_hex where > the ibase within the define clause wasn't honored. That?s because your bin_to_hex function is erroneously assuming that its input is just a string of digits that has no base interpretation, so that it can set ibase *after* bc has already seen the value, and that this will change the...

...1, 2015, at 10:05 AM, Mike - st257 <silvertip257 at gmail.com> wrote: > > > > On Mon, Aug 31, 2015 at 11:15 AM, Warren Young <wyml at etr-usa.com> wrote: > > > >> ibase=A and obase=A > > > > Not sure how this helps me with my most recent example of bin_to_hex > where > > the ibase within the define clause wasn't honored. > > That?s because your bin_to_hex function is erroneously assuming that its > input is just a string of digits that has no base interpretation, so that > it can set ibase *after* bc has already seen the value,...

...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 "obas...

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

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

...k 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. > Not sure how this helps me with my most recent example of bin_to_hex where the ibase within the define clause wasn't honored. Working with bc interfactively or by piping produce the desired/correct values. Testing indicates the ibase is defaulted or overrode as base10 despite what is specified in the define clause. :-( > > My objection is that this is e...