MIME-version: 1.0
Content-type: text/plain; charset=utf-8; format=flowed
Content-transfer-encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
            Thunderbird/38.7.2
Message-ID:  <584139D8.1000208@clear.net.nz>
Date:         Fri, 2 Dec 2016 22:07:36 +1300
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: Andrew Parsloe <aparsloe@CLEAR.NET.NZ>
Subject: Rounding quirk in l3fp
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

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

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus