On 7/11/14, aparsloe <[log in to unmask]> 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