Talk:Exponentiation with infix operators in (or operating on) the base: Difference between revisions
Content added Content deleted
Thundergnat (talk | contribs) (→Title too confused and long: my two cents) |
(→Title too confused and long: added wording.) |
||
Line 2: | Line 2: | ||
Suggest work out an acceptable option and then change the task name. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 05:46, 3 November 2020 (UTC) |
Suggest work out an acceptable option and then change the task name. --[[User:Paddy3118|Paddy3118]] ([[User talk: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. --[[User:Thundergnat|Thundergnat]] ([[User talk:Thundergnat|talk]]) 13:55, 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. --[[User:Thundergnat|Thundergnat]] ([[User talk: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. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk: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. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 14:47, 3 November 2020 (UTC) |
|||
==what should non infix languages do? == |
==what should non infix languages do? == |
Revision as of 14:49, 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 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)