In message <[EMAIL PROTECTED]>, Tom Cosgrove writes:
>
> What is happening here is that when you enter
>
> ibase=16
> l(0.1)
>
> you get "0.0" passed to the l() function, which gives -infinity. (I
> would call that the expected result under the circumstances.)
>
> If you enter
>
>
Please, drop my last example about how bc works on Solaris... bc was
on base 16, not on base 10, when run that test... it seems this is a bad
and very long day! :-)
$ bc -l
l(0.0625000)
-2.77258872223978123766
Now all is clear,
Igor.
>>> Igor Sobrado 29-Jan-07 14:36 >>>
>
> But I want to note that the difference between Solaris' bc and
> the bc flavours available on NetBSD (GNU bc) and OpenBSD (its own bc
> implementation) for numbers near zero is probably a bug.
>
> In fact, Solaris' bc returns comparable numbers for l(0.1) a
In message <[EMAIL PROTECTED]>, Otto Moerbeek writes:
>
> On Mon, 29 Jan 2007, Igor Sobrado wrote:
>
> > (I suppose that setting obase=10 after setting the input base to 16d
> > means that the output base is set to 0x10...)
>
> indeed.
>
> In the last example Solaris does no seem to truncate 0.
On Mon, 29 Jan 2007, Igor Sobrado wrote:
> Hi again.
>
> Of course, Karel Kulhavy is the one to provide feedback on this patch.
> But I have tried it too (after upgrading src/usr.bin/bc) and seems to
> be working fine for this case (NetBSD and Solaris are running their own
> flavours of bc):
>
>
On Mon, 29 Jan 2007, Michael Schmidt wrote:
> I want to be hoonest, I am not involved in bc problems, but reading these
> mails, just as an idea:
>
> Why not creating a new bc, or in other words changing the bc of today and
> correcting that math stuff. Name the new, corrected bc something like b
Hi again.
Of course, Karel Kulhavy is the one to provide feedback on this patch.
But I have tried it too (after upgrading src/usr.bin/bc) and seems to
be working fine for this case (NetBSD and Solaris are running their own
flavours of bc):
For OpenBSD:
$ bc -l
ibase=4
obase=10
scale=100
l(1.031)
Igor Sobrado wrote:
I have tested these base 11 to base 10 translations on other bc
versions and all show the same behaviour. I agree, this behaviour
is historically consistent. But this handling of non-decimal
fractions is wrong from the point of view of mathematics. In other
words:
- 0.1 p
In message <[EMAIL PROTECTED]>, Otto Moerbeek writes:
>
> bc hase some more unexpected things for the casual user:
>
> scale=4
> 1/3 produces 0.
> 2/3 produces 0.
Not so unexpected -- a mathematician would work out 0. and 0.6667
respectively, but your excellent example is what we wou
Here's a complete diff. Not that it is relative the whitespace cleanup
diff I comitted a few hours ago. So make sure your tree is up-to-date
before patching.
-Otto
Index: bc.library
===
RCS file: /cvs/src/usr.bin/bc/bc.librar
On Mon, 29 Jan 2007, Igor Sobrado wrote:
> [copied and pasted, I am currently not subscribed to [EMAIL PROTECTED]
>
> On Mon, 29 Jan 2007, Otto Moerbeek wrote:
> > Note that some of your tests still
> > produce strange results, but that is due to weird handling of
> > non-decimal fractions wrt sc
[copied and pasted, I am currently not subscribed to [EMAIL PROTECTED]
On Mon, 29 Jan 2007, Otto Moerbeek wrote:
> Note that some of your tests still
> produce strange results, but that is due to weird handling of
> non-decimal fractions wrt scale:
>
> For example, with ibase=11
> 0.1 produces 0.0
On Mon, 29 Jan 2007, Otto Moerbeek wrote:
> On Mon, 29 Jan 2007, Otto Moerbeek wrote:
>
> > On Mon, 29 Jan 2007, Karel Kulhavy wrote:
> >
> > > I just found three bugs in the OpenBSD 4.0 "bc" program.
> >
> >
> > All three bugs seem to related to the use of a non-decimal input base
> > in comb
On Mon, 29 Jan 2007, Otto Moerbeek wrote:
> On Mon, 29 Jan 2007, Karel Kulhavy wrote:
>
> > I just found three bugs in the OpenBSD 4.0 "bc" program.
>
>
> All three bugs seem to related to the use of a non-decimal input base
> in combination with using the -l lib.
>
> This is because the stor
On Mon, 29 Jan 2007, Karel Kulhavy wrote:
> I just found three bugs in the OpenBSD 4.0 "bc" program.
All three bugs seem to related to the use of a non-decimal input base
in combination with using the -l lib.
This is because the stored routines interpret the number according to
the base at exe
I just found three bugs in the OpenBSD 4.0 "bc" program.
0) some "evil" numbers make bc hang:
[EMAIL PROTECTED]:~$ bc -l
ibase=4
obase=10
scale=100
l(1.031)
.023311001002311221102233202
(immediate reply)
l(1.03)
[ - HANG at least for 11 minutes - ]
PID USERNAME PRI NICE SIZE RES STATEWAIT
16 matches
Mail list logo
