LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Thu, 29 May 2014 09:41:25 +1200
MIME-version:
1.0
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Content-type:
text/plain; charset=UTF-8; format=flowed
Subject:
From:
aparsloe <[log in to unmask]>
In-Reply-To:
Message-ID:
Content-transfer-encoding:
8BIT
Parts/Attachments:
text/plain (45 lines)
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 negative
>> 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 return
>> negative zero but \fp_to_decimal:n would “normalise” it; 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) = +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 (±0)±(±0) are not mandated by the 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 
expression derived, after an embarrassingly long labour, from another 
complicated trigonometric expression. Had I made a mistake in the 
working? I evaluated the expressions using l3fp. One, for a number of 
different parameter values gave 0, the other for the same parameter 
values gave -0. I concluded, ruefully, that the derivation was correct.

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

Andrew

ATOM RSS1 RSS2