Talk:Exponentiation with infix operators in (or operating on) the base

Title too confused and long

Suggest work out an acceptable option and then change the task name. --Paddy3118 (talk) 05:46, 3 November 2020 (UTC)

Looks to me like the actual task is: "Demonstrate operator precedence" using exponentiation and unary negation as its required operators. I would propose "Operator precedence" as a task title... but that's just me. --Thundergnat (talk) 13:55, 3 November 2020 (UTC)

There already is a Rosetta Code task:   Operator_precedence   which does the above suggestion.   But it doesn't really demonstrate the problem concerning exponentiation, at least in that three pseudo-codes have already been shown   (used on Rosetta Code)   and interpreted incorrectly.     -- Gerard Schildberger (talk) 14:47, 3 November 2020 (UTC)

A general operator precedence wasn't the goal of the task,   but specifically exponentiation when a unary (negative) operator was being used (or specified).   This was the case in which this ambiguity was actually being used (specified) in the preamble of three Rosetta Code tasks.   I know because I kept getting the wrong results until I realized that some languages must be behaving differently than the languages that I know   (as far as infix operators).   So I named/created the task to be as specific as possible to test/demonstrate just one thing, not the whole enchilada.   This situation, other than chained exponentiations   (x**y**z)   are (it seems) two of the cases where it is known to get misinterpreted   (or at least, implemented differently).   I didn't want to this task to get too general and loose focus of the (minor) difficulty that had already occurred on Rosetta Code, at least in my case.     -- Gerard Schildberger (talk) 14:47, 3 November 2020 (UTC)

Should a ref be added to [1]? Or should that task actually address the problem?--Nigel Galloway (talk) 15:01, 3 November 2020 (UTC)

what should non infix languages do?

--Paddy3118 (talk) 05:46, 3 November 2020 (UTC)

I might suggest they would add parenthesis or use whatever mechanism/method that would be most appropriate in that computer programming language.   I say  might  as I have no idea what/how  APL  (and some other programming languages for instance)   treat (or even has)   infix operators.   Take the case of:     -4 + 6.     Or, in the general case:   -x (some operator) y,   where   some operator   may be a subset of what operators are supported for any one computer programming language.   This was a problem that stopped me from adding   REXX   to a couple of Rosetta Code tasks because those tasks used     \     (not, ¬, ^, ~,   et al)   (and/or some other characters)   in general expressions.       PL/I   and   REXX   (and I'm sure, others programming languaes as well)   allow     - 6 +  - - 7       (with or without the embedded blanks and/or the addition of grouping symbols [parentheses])   for instance,   but multiple infix operators (and/or signs and/or logical   nots)   wasn't the wide scope that I wanted to address for this Rosetta Code task.     -- Gerard Schildberger (talk) 15:20, 3 November 2020 (UTC)