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