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 scale:
> >
> > For example, with ibase=11
> > 0.1 produces 0.0
> > 0.10 produces .09
> > 0.100 produces 0.090
> >
> > As far as I remember, this is consistent behaviour compared to
> > historic versions of bc.
>
> 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 produces 0, but should return .1
> - 0.10 produces .09, it is right
> - 0.100 produces .090, but should return .091
> - 0.1000 produces 0.0909, it is ok too
> - 0.10000 produces 0.09090, but should return 0.09091 instead...
>
> A mathematician would say that this behaviour is wrong and must be
> fixed even if it is historically right. As a physics graduate and
> Ph.D. is CS I agree with mathematicians too. But there are some
> questions that must be answered:
>
> - will fixing this *wrong* behaviour break compatibility with other
> bc implementations? -- how many scripts will break then?
> - how will a fix for this issue affect performance of bc?
> - will it be difficult to implement?
>
> I am certainly against a "compatibility" option... what would be the
> default behaviour for bc? The right one or the wrong one?
>
> In short, would it make sense fixing this bug even if it means
> releasing an incompatible bc flavour?
>
> As the original poster observed, this bug seriously affects other
> calculations done with bc. If SU does not say anything about how
> non-decimal fractions must be handled I would choose the right
> approach from a mathematical sense. Of course, I am thinking that
> "if SU says nothing about this fact, it means that we are free to
> choose how non-decimal numbers must be managed". Perhaps it is
> wrong, but increasing precision on bc makes sense to me.
bc hase some more unexpected things for the casual user:
scale=4
1/3 produces 0.3333
2/3 produces 0.6666
now the fact is that SU defines that results should be truncated:
"When an exact result is not achieved (for example, scale=0; 3.2/1),
the result shall be truncated."
IMO, 3.9/1 would have been a more instructive example.
Anyway, if you want to change rounding of fractions, you're likely
bump into this truncation rule.
-Otto
