[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. Cheers, Igor.
