MIME-version: 1.0
Content-type: text/plain; charset=UTF-8; format=flowed
References: <5382FD21.6040600@clear.net.nz>
            <CANQYN6zOq8dd5BUi32nCJGh9QgagZaaoj4UW1Ku3B4XWHi2PNA@mail.gmail.com>
            <A11620FE-AE5E-4CF7-A014-A5C5D4E05121@gmail.com>
            <CANQYN6zPFfu3zaS+Vp_V1Z_e_PNQHrO1xrRkutXAMFuU89yZ-w@mail.gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101
            Thunderbird/24.5.0
Message-ID:  <53865805.7030602@clear.net.nz>
Date:         Thu, 29 May 2014 09:41:25 +1200
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: aparsloe <aparsloe@CLEAR.NET.NZ>
Subject: Re: l3fp and sin(pi), cos(pi/2)
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <CANQYN6zPFfu3zaS+Vp_V1Z_e_PNQHrO1xrRkutXAMFuU89yZ-w@mail.gmail.com>
Precedence: list
Content-Transfer-Encoding: quoted-printable
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 28/05/2014 1:42 a.m., Bruno Le Floch wrote:
> Hello Will,
>
>> about the typesetting; should/can we provide an easy way to typeset ne=
gative
>> zero just as zero?
> I suppose there are two cases where one needs to display numbers: for
> typesetting, and when writing to a file (terminal, log,...).  For the
> first case, I'd advocate using siunitx, which has all the settings you
> may want, and more.  For the second case, I feel that in all contexts
> where 0 is better than -0 (e.g. pdf specials) there is also a need to
> limit the number of significant digits to less than 16.  This requires
> rounding.  We should provide formatting functions which produce a
> string of characters from floating points.  Doing this correctly is a
> bit subtle, and it is not clear what should be implemented and what
> can be left out (see e.g.
> http://www.cplusplus.com/reference/cstdio/printf/ for a long list of
> things C++ does).
>
>> When I was trying it out, I thought perhaps that \fp_eval:n would retu=
rn
>> negative zero but \fp_to_decimal:n would =E2=80=9Cnormalise=E2=80=9D i=
t; is that a crazy
>> idea?
> I'm not keen on that, but I don't have a very strong argument against
> it.  Mainly, -0 is the correct result, so I don't see what's wrong
> with it.  Actually... thinking about it, there is an easy way to get 0
> for -0: add +0 to it.  It turns out that 0+(-0) =3D +0, so for all x,
> 0+x is exactly x, except when x is -0, then 0+x is +0.  If I remember
> correctly, the signs of (=C2=B10)=C2=B1(=C2=B10) are not mandated by th=
e standard, so
> we could presumably document that 0+x does the right thing, and make
> sure that this is mentioned in the code and tested.
>
> Bruno
>
I had the experience recently of checking a complicated trigonometric=20
expression derived, after an embarrassingly long labour, from another=20
complicated trigonometric expression. Had I made a mistake in the=20
working? I evaluated the expressions using l3fp. One, for a number of=20
different parameter values gave 0, the other for the same parameter=20
values gave -0. I concluded, ruefully, that the derivation was correct.

To someone, like me, not versed in numerical analysis, the occurrence of=20
signed zero was a surprise. The 0+x trick is good to know and perhaps=20
worth mentioning in the documentation.

Andrew