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