> On May 31, 11:39 pm, Mark Janssen <mpc.jans

@gmail.com> wrote:

> > n@alumni.princeton.edu schreef:

> > > On May 31, 3:24 pm, Mark Janssen <mpc.jans@gmail.com> wrote:

> > > > On May 31, 9:03 pm, n@alumni.princeton.edu wrote:

> > > > > I am not sure if it is me or our bellowed "expr" command, but I need

> > > > > someone to set me straight.

> > > > > In C the command:

> > > > > printf("%d\n", -4/3);

> > > > > gives: -1

> > > > > I searched c.l.tcl and found a post from 1/27 2005 which said:

> > > > > > set tcl_precision 17 ;# Expressly: to show imperfections with real numbers!

> > > > > > expr {4/3} ==> 1

> > > > > > expr {4/-3} ==> -1

> > > > > BUT, when I do it in tclsh itself:

> > > > > expr {-4/3} or expr {4/-3} gives -2 ???

> > > > > Has someone messed up with integer arithmetic in recent

> > > > > versions of tcl (I am running 8.4.14)

> > > > > Just tried on the older version 8.4p1 on different OS/CPU type and got

> > > > > the same.

> > > > > Now this is not an academic pursuit.

> > > > > I was coding a data translator and documentation was

> > > > > giving a particular expresion to be calculated as

> > > > > integer arithmetic and I was getting wrong answers.

> > > > > Anyone has a clue as to what is going on.

> > > > > I haven't looked at the src yet, but it may get there :-) .

> > > > > Thanks,

> > > > > Nikola

> > > > When using integer division which results in a remainder, there is no

> > > > 'correct' answer. The correct answer would be -1.333..

> > > > So then whether you round up to -1 or down to -2 is left to

> > > > definition. Most scripting languages (at least Python and Ruby) will

> > > > round down as Tcl does.

> > > While I understand that integer arithmetic is not perfect

> > > or even consistent, this is still a problem.

> > > [ side bar: IA cannot be consistent with negation and addition

> > > at the same time. For example -IA(xyz) == IA(-xyz)

> > > and IA(xyz+2) == IA(xyz)+2 cannot both be right if xyz is -4/3 ]

> > > Nowhere in the documentation is there a mention (that I could find)

> > > about a decission to implement things in this way.

> > > The code is in C so at least it could be consistent with the

> > > underlaying language.

> > > Also how come the 2 year old post has different result

> > > then the one produced by current tcl?

> > > I personally would never use integer arithmetic for anything

> > > but apparently people do and publish formulas based on it.

> > > Anyone knows the inside story abut tcl's handling of such

> > > expressions?

> > > Thanks,

> > > Nikola

> > > > In C < C99 it was not defined what the answer would be (it was

> > > > impkementation defined), but on intel HW at least it was -1. In C99 it

> > > > was defined to have the value of -1 (e.g. round towards zero, which is

> > > > unfortunately different from the rest of the world).

> > > > As to why rounding towards zero or down would be better I don't know,

> > > > but there are no doubt very good reasons for one and the other.

> > > > Seehttp://praisecurseandrecurse.blogspot.com/2006/12/division-bell-tolls...

> > > > for some nice background.

> > > > Mark

> > Oops, I missed the part that it was different in older releases. I

> > expect that in that older release the C API was used directly leading

> > to -1 on some platforms and -2 on some others. It might very well be

> > possible that this was changed when the bytecode engine was introduced

> > (somewhere around Tcl8.0)

> > Regardig the fact if this is documented, on the expr manual page it

> > states (http://www.tcl.tk/man/tcl8.4/TclCmd/expr.htm#M7):

> > The remainder will always have the same sign as the divisor and an

> > absolute value smaller than the divisor.

> > In case of downwards rounding

> > expr {-4/3} == -2

> > -2 * 3 == -6

> > therefore the remainder == 2 (-6 + 2==-4)

> > 2 has the same sign as the divisor 3

> > In case of rounding towards zero

> > expr {-4/3} == -1

> > -1*3 = =-3

> > therefore the remainder == -1 (-3 + -1 ==-4)

> > -1 does not have the same sign as the divisor 3

> > So if rounding was towards 0 the expr manpage would be violated and

> > hence it can be concluded that the current behaviour is documented

> > (although it could arguably have been stated more clearly)

> > Mark

> Note that the reply inhttp://groups.google.com/group/comp.lang.tcl/msg/b9daa050d8747126

> suggests that the rounding towards -infinity was already normal

> behaviour at this point in time. Apparently Arjen made mental

> calculations.

> It also provides a alternative that rounds to zero instead:

> proc div {n m} {

> expr (2*$n+$m)/(2*$m)

> }

> % div -4 3

> -1

> % div 4 -3

> -1

> % div 4 3

> 1

> Mark

Sorry that proc is round-to-nearest.