Mail-Followup-To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
References: <9343542E664B894484613D106D7D3F5F84AAE9@s-yellow.net.silverstroke.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <20071108090815.GA3380@irwin.vpn.uni-freiburg.de>
Date:         Thu, 8 Nov 2007 10:08:16 +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: Heiko Oberdiek <oberdiek@UNI-FREIBURG.DE>
Subject: Re: Bug in \int_div_truncate_raw:nn
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <9343542E664B894484613D106D7D3F5F84AAE9@s-yellow.net.silverstroke.de>
Precedence: list
Status: R

On Thu, Nov 08, 2007 at 09:30:06AM +0100, Jonathan Sauer wrote:

> I hope this is the right place for this.
> 
> 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. :-((

> 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

> This seems to work better.

No: -2/2 = -2

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.

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