MIME-Version: 1.0
References: <539432A6.7030205@clear.net.nz> <5395A7A3.7040106@residenset.net>
            <5395AA02.8040704@morningstar2.co.uk>
            <CANQYN6x3K5LzThY49V2CYuDj0i6O=M1CJgby9YdS4J6ZDY5UTA@mail.gmail.com>
            <53BF9FD5.8070805@clear.net.nz>
Content-Type: text/plain; charset=UTF-8
Message-ID:  <CANQYN6y13YpuPPLM-d+He8i3v1e9P5rsG3MxeH5DpqpxZXTQ1Q@mail.gmail.com>
Date:         Fri, 11 Jul 2014 12:22:15 -0400
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: Juxtaposition in l3fp
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <53BF9FD5.8070805@clear.net.nz>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 7/11/14, aparsloe <aparsloe@clear.net.nz> wrote:
> On 11/07/2014 11:20 a.m., Bruno Le Floch wrote:
>> Hello list,
>>
>> Sorry for the >1 month delay.  This is a followup to the thread asking
>> whether letting juxtaposition denote multiplication was a good idea.
>> I think it was, but I made a big mistake in making juxtaposition be
>> multiplication with a _different precedence_ than the asterisk.
> ...
>> In l3fp, I pushed the idea to its extreme, allowing juxtaposition for
>> things other than units, and I kept the precedence as being the
>> tightest possible.
>>
>> As Lars rightfully says it's "consistent, but not necessarily
>> intuitive".  Andrew has given several cases where my choice leads to a
>> terrible behaviour for l3fp, and there is basically no case where the
>> current behaviour is better (well, there was one abusive one: with
>> this rule, exp.5ln(...) computes the square root, but now that is not
>> needed).
> Actually, I've found this "abuse" quite a handy device, and despite the
> introduction of the sqrt function to l3fp, for n-th roots, exp(1/n)ln
> has a certain convenience.

Well, that won't work once we change the precedence of juxtaposition
to be the same as normal multiplication.  But IIRC, we added (perhaps
in l3candidates?  I'll check) a way for users to define their own fp
functions.  This is still experimental.  Looking at it, it seems we
don't document \fp_function:Nw and \fp_new_function:Npn anywhere.

>> I'm keen on leaving juxtaposition = multiplication, because that
>> allows to use dimensionful numbers directly inside fp expressions (pt,
>> in, ... are defined as floating point constants).  I believe that we
>> should change the precedence of juxtaposition-as-multiplication from
>> what it currently is (the tightest) to being the same as
>> multiplication.  In other words, juxtaposition would behave exactly
>> identically to adding an asterisk.
>>
>> Would that make sense?  Am I missing something crucial (probably... I
>> didn't realize when allowing juxtaposition what a mess I was
>> creating)?
>>
>> Best regards,
>> Bruno
> Thanks for the response Bruno (but "terrible" is a strong word). The
> suggested new precedence would certainly take care of the examples that
> tripped me up and that seemed like traps for the unwary.
>
> There is one other precedence which troubles me a little. I read an
> expression like
>
>   ln(1+1/n)^n
>
> as 'raise (1+1/n) to the n-th power then take the logarithm' ( =
> n*ln(1+1/n) ). l3fp treats this as
>
>   ( ln(1+1/n) )^n
>
> I realise that in the absence of clarifying parentheses there is an
> inherent ambiguity in such forms which needs to be resolved in a fixed
> manner one way or the other. I question whether l3fp has chosen the
> intuitive way, or the way of customary practice. For instance we write
> ("incorrectly" but the practice is universal) sin^2 x rather than sin
> x^2 when we want to square the sine of x, presumably because sin x^2
> suggests the sine of x^2. In short, should the precedence levels of
> function calls and raising to a power be interchanged? With your
> proposed change to juxtaposition's precedence, this would bring l3fp
> into line with customary "habits of mind".*
>
> Andrew
>
> * Well, my mind!

No.  All programming languages in which function arguments are
surrounded with parentheses interpret ln(123)**2 as (ln(123))**2, so
l3fp should as well.

Now the question is how to implement the change in precedence in the
least destructive way.  I don't think we can have any warning (well...
that's only mostly true, I have some very experimental code for ugly
expandable warnings).  Should we just do the change brutally?

Regards,
Bruno