In message <[EMAIL PROTECTED]>, Otto Moerbeek writes: > > bc hase some more unexpected things for the casual user: > > scale=4 > 1/3 produces 0.3333 > 2/3 produces 0.6666
Not so unexpected -- a mathematician would work out 0.3333 and 0.6667 respectively, but your excellent example is what we would expect from a tool that truncates decimal numbers as bc does. > 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. An example like 3.9/1 would certainly make people working on these rules think twice. Truncating a number is an easy way to manage these issues, but a wrong way. In any case, if SU defines that results should be truncated then these numbers must be truncated even if there is a way to get more accurate results. Standards should be followed, even if there are better ways to manage these issues. (a good reason for carefully designing standards.) > Anyway, if you want to change rounding of fractions, you're likely > bump into this truncation rule. Quite sure! Thank you very much for this detailed description of the SU rule and why this behaviour of bc is acceptable. Best regards, Igor.
