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 this 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)

I think that would be a good idea.   But that other task didn't address this issue directly except by fiat --- as opposed to what any particular computer programming actually did   (not withstanding the   talk   page),   so I added this task as I very reluctant to change (or modify or add to) an existing and established nine year old task.     -- Gerard Schildberger (talk) 15:37, 3 November 2020 (UTC)

Hi Gérard, how about "Exponentiation parsing" or "Infix parsed exponentiation" or some such as a re-title? Up to now I've not really been aware of the issue, so I'm learning stuff. --Paddy3118 (talk) 17:22, 3 November 2020 (UTC)

Better to be long than inconcise.   I was thinking:   -n   to me, is "in" the base,   -(n)   is acting "on" the base.     Six of one, a half dozen of the other.     If you don't mention the base,   that might include such things like:     x**-2.     As I referred to, I saw examples of the use of infix operators on the base of an expression being exponentiated.   I corrected one problem by added an appropriate set of parentheses to the expression to clarify what was being intended.   I don't recall how (or if) the other two tasks were resolved/changed (or not).   One has to be careful of changing Rosetta Code tasks that are no longer in draft status, don't you know?.   It was easier for me to add a draft task addressing this specific issue rather than trying to correct an existing Rosetta Code task.   I am learning that making changes to (establish) tasks on Rosetta Code,   it's often better to ask forgiveness than ask permission.   Take this Rosetta Code (draft) task in point.   The point was to clarify how different computer programming languages deal with this issue,   an infix operator that is acting on the   base   not the exponent,   so that is why the Rosetta Code task has a longer (i.e., specific) name   (to make it ... er, ... specific).       By the way, the one Rosetta Code task's preamble that I did change, was in fact, an exponential expression   raised   to an exponential expression that had, in fact, an infix operator (within the 2^nd exponential expression, ... or 3^rd, depending how one counts expressions),   the explanation almost makes your head spin) ─── I hope that I am recalling correctly,   and I hope that it is clear as mud,   but it covers the ground ───     which you might see why I thought it needed to be clarified.   If I had asked, we still may be talking about that Rosetta Code task, and possibly,   on why it didn't need to be changed as everyone (so far at that time)   knew   what was intended,   or their computer programming language(s) used that version/meaning of the syntax,   so it made that interpretation of the syntax moot.   Everybody knows what I mean when I say,   "let's go eat Grandma".     Still, it's better, when writing, expressing it as:   "let's go eat, Grandma".     -- Gerard Schildberger (talk) 18:41, 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)

By the way, I wasn't even aware of that some computer programming languages can specify how to treat (interpret/process) infix operators   (as far as precedence).     -- Gerard Schildberger (talk) 18:47, 3 November 2020 (UTC)

<Quote>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.</End Quote>

Really? Which tasks? (Honest question. I really am curious.) In my experience, most tasks have quite a bit of leeway in how a particular language entry implements a solution and aren't so rigidly focused on exact syntax. In fact, I can't recall any off the top of my head that require specific syntax. That kind-of defeats the purpose a chrestomathy. Formatting... ok, yeah, there are some task authors who tend to specify very rigid requirements for output formatting, but again, that isn't syntax. --Thundergnat (talk) 15:51, 3 November 2020 (UTC)

The Rosetta Code task that I eluded to had to do with with compiling/interpreting/verifying/converting/parsing program statements/expressions/syntax or some such.   In particular, it had to do with (if I recall) the use of a logical infix that was contrary to what/how the language (natively) that I used,   so it made the programming (for me) difficult,   and I choose not to enter a solution and voted with me feet.   I tried searching for (the couple?) of Rosetta Code tasks that I was trying to remember,   but couldn't find it as I was apparently using the wrong search keywords.   In any case, I don't want to waste my time defending why I chose to NOT enter a programming solution.   There are some task authors who are very rigid and even contrary when their tasks are improved or re-worded or have additional information added,   I even remember an author who accused me of vandalizing the task, and in another case, even made mockery of me requiring the insertion of commas in large number for easier comparisons and perusing of some largish numbers (that are shown in the output).   Not exactly the friendliest place, but there ya have it.   Life is short enough without having to deal with such unfriendly people.   I guess it depends on how one defines   very rigid   requirements.   I do not want to argue of what I observed versus what someone else's recollection of Rosetta Code tasks that require (a) specific syntax.   As far as I've seen, almost all of the Rosetta Code tasks that deal with a specific notation use (require) a specific syntax.   Again, I don't want to belabor these points.     -- Gerard Schildberger (talk) 17:50, 3 November 2020 (UTC)