Talk:Exponentiation with infix operators in (or operating on) the base: Difference between revisions
Talk:Exponentiation with infix operators in (or operating on) the base (view source)
Revision as of 20:12, 4 February 2021
, 3 years ago→Bug in Ada: removed
m (→what should non infix languages do?: added wording.) |
m (→Bug in Ada: removed) |
||
| (3 intermediate revisions by 2 users not shown) | |||
Line 1:
==Title too confused and long==
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)
Line 12 ⟶ 13:
: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)
:: 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 <u>base</u> 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<sup>nd</sup> exponential expression, ... or 3<sup>rd</sup>, 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". -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 18:41, 3 November 2020 (UTC)
==what should non infix languages do? ==
Line 17 ⟶ 20:
: 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. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk: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). -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 18:47, 3 November 2020 (UTC)
:: <blockquote><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></blockquote> 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. --[[User:Thundergnat|Thundergnat]] ([[User talk:Thundergnat|talk]]) 15:51, 3 November 2020 (UTC)
| |||