Talk:Exponentiation with infix operators in (or operating on) the base: Difference between revisions
Content added Content deleted
Thundergnat (talk | contribs) (→what should non infix languages do?: examples?) |
(→Title too confused and long: new title discussion.) |
||
Line 10: | Line 10: | ||
:::: 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. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 15:37, 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. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk: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. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 17:22, 3 November 2020 (UTC) |
|||
==what should non infix languages do? == |
==what should non infix languages do? == |
Revision as of 17:23, 3 November 2020
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)
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>