References: <584139D8.1000208@clear.net.nz>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
            Thunderbird/45.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Message-ID:  <e7133ff7-d7bb-95e0-73e8-cd8b306b3d11@gmail.com>
Date:         Fri, 2 Dec 2016 09:47:58 -0500
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: Bruno Le Floch <blflatex@GMAIL.COM>
Subject: Re: Rounding quirk in l3fp
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <584139D8.1000208@clear.net.nz>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 12/02/2016 04:07 AM, Andrew Parsloe wrote:
> I stumbled on the following quirk recently:
> 
> \tl_clear:N \l_tmpa_tl
> \fp_eval:n { round( \l_tmpa_tl, 4) }
> 
> gives 4 as the answer (or whatever the rounding value is). Usually, in
> the situation where this arose, \l_tmpa_tl is a string of digits
> possibly including a decimal point. In this instance it was empty. Okay,
> I can check for that, but I wonder if l3fp should do so, and either give
> an error, as
> 
> \fp_set:Nn \l_tmpa_fp { \l_tmpa_tl }
> 
> does when the token list is empty, or give a conventional 0 as answer?
> 
> Andrew

Thanks, this is a bug.  A better behavior would be to throw an error and
give nan.

This is due to my recent commit adding random number support: to allow
for rand() I did the easiest thing which was to allow and ignore empty
arguments.

I'll fix it some time this month.

Best regards,

Bruno