Re: Integer arithmetic problem

On May 31, 3:24 pm, Mark Janssen <mpc.jans...@xxxxxxxxx> wrote:
On May 31, 9:03 pm, n...@xxxxxxxxxxxxxxxxxxxx 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


.

Relevant Pages

  • Re: Integer arithmetic problem
    ... So then whether you round up to -1 or down to -2 is left to ... round down as Tcl does. ... In C < C99 it was not defined what the answer would be (it was ... As to why rounding towards zero or down would be better I don't know, ...
    (comp.lang.tcl)
  • Re: About Tcl syntax...
    ... Mathematics is sadly not consistent in it's notations. ... I didn't propose to change that fundamentally, but rather to have it consistent in a programming language. ... Tcl is more consistent regarding the prefix notation than many others. ...
    (comp.lang.tcl)
  • Re: Functions Optional Parameters
    ... It seems the group is so busy that none had answered my question. ... Anyway i'll be asking this here in TCL, ... case2: myProgram -r someFileToLoad ... handle optional arguments (including zero), or are you asking if a Tcl based *program* can handle optional command line arguments? ...
    (comp.lang.tcl)
  • Re: Integer arithmetic problem
    ... round down as Tcl does. ... proc div { ...
    (comp.lang.tcl)
  • Re: [Q] Problem with Expect and migration to AIX 4.3.3.
    ... > Mewtwo wrote: ... >>solution only addressed WRITE of zero bytes by Tcl not READ of zero bytes ... >>by Tcl so it is quite different to my Expect problem. ... So should this be another bug report then? ...
    (comp.lang.tcl)