Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Thread-Topic: Bug in \int_div_truncate_raw:nn
Thread-Index: Acgh7xLEIoe9K6q6TNepnMHk2V9BKQAADWFg
References: <9343542E664B894484613D106D7D3F5F84AAE9@s-yellow.net.silverstroke.de>
            A<20071108090815.GA3380@irwin.vpn.uni-freiburg.de>
Content-Transfer-Encoding: 8bit
Message-ID:  <9343542E664B894484613D106D7D3F5F84AAEC@s-yellow.net.silverstroke.de>
Date:         Thu, 8 Nov 2007 11:18:55 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Jonathan Sauer <Jonathan.Sauer@SILVERSTROKE.COM>
Subject: Re: Bug in \int_div_truncate_raw:nn
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
Precedence: list
Status: R

Hello,

> > Macro \int_div_truncate_raw:nn is defined in file l3int as:
> > 
> > \def_new:Npn \int_div_truncate_raw:nn #1#2 {
> >   \int_eval:n{ (2*#1 - #2) / (2* #2) } }
> > 
> > If #1 is zero and #2 is two, this macro does not expand to zero, as 
> > one would expect (0 / 2 = 0), but to -1 (since eTeX rounds negative 
> > numbers by negating them, rounding the positive number and negating 
> > the result. See function "quotient" in etex.ch).
> 
> This eTeX-rounding does not make life easier. :-((

Indeed not. Does anybody know why it was implemented in the first
place? It differs from \divide's behaviour, but surely there was a
good reason for implementing it.

> > Also, if #2 is an expression (i.e. 1+1), the calculation is not 
> > performed correctly, since #2 (and #1) is not surrounded by ( and ).
> > (I am not sure if this can happen, or if the parameters are always 
> > evaluated beforehand)
> > 
> > In my code, I use (to divide #1 by #2):
> > 
> > \numexpr((((#1)+((#2)/2))/(#2))-1)\relax
> 
> With less parentheses:
> 
> \numexpr (#1+(#2)/2)/(#2)-1\relax

Thanks! Seems like I used parentheses in a "better safe than sorry"
way and forgot basic math while at it.

> > This seems to work better.
> 
> No: -2/2 = -2

Dang! Please add "for positive numbers" in my statement above ;-)
(note to self: Add unit tests for negative numbers)

> Also both solutions have the disadvantage, that intermediate 
> results may cause an arithmetic overflow. As result the 
> accepted number range is limited unnecessarily.
>   Therefore I have choosen a more complicate route in package 
> `intcalc' by a case switch for zero, positive and negative numbers.

It looks like that is the only way to be safe.


> Yours sincerely
>   Heiko <oberdiek@uni-freiburg.de>

Jonathan