Proposal: Exponentiation operator

[dharmatech]

Consider adding an exponentiation operator that is higher in precedence than the multiplicative operators but lower in precedence than the unary operators.

In the Symbolism computer algebra library, +, *, /, and - are overloaded to create Sum, Product, Quotient, and Difference objects respectively. ^ is also overloaded to create Power objects. However ^, being the logical XOR operator, is lower in precedence than the multiplicative operators. Thus parenthesis must be used in expressions like a + b * (c ^ e).

MSDN - C# Operators

Exponentiation operator in some other languages:

Language	Operator
F#	**
VB.NET	^
TypeScript	**
JavaScript	**
Python	**
Haskell	^, ^^, **
OCaml	**
Swift	Not built-in but can be defined
FORTRAN	**
Ada	**
Nim	^
ALGOL 60	**
APL	*

[MouseProducedGames]

Why not a ** b to represent a ^ b? Prevents problems and confusion with the XOR operator, and should be quickly apparent.

[gafter]

Is this really so much better than

using static System.Math;

    var result = Pow(a, b);

[paul1956]

Yes, VB has it so it makes translation easier, also makes mathematical expression easier to read but the second point could be debated.

Sent from my iPhone
I apologize for any typos Siri might have made.
(503) 803-6077

On Aug 18, 2015, at 11:31 AM, Neal Gafter [email protected] wrote:

Is this really so much better than

using static System.Math;

var result = Pow(a, b);

—
Reply to this email directly or view it on GitHub.

[whoisj]

Why not a ** b to represent a ^ b? Prevents problems and confusion with the XOR operator, and should be quickly apparent.

👍

[dharmatech]

Yes, a ** operator would be nice.

However, would it be possible to add this operator and not interfere with the dereference operator (*)? I guess since the dereference operator works on pointers, which aren't used in exponentiation operations, this seems like it would be OK.

F# also uses **. F# - Arithmetic Operators

[HaloFour]

@paul1956

VB's ^ operator literally just translates into a call to Math.Pow so there is no additional benefit to porting between the languages. There is also nothing stipulating feature parity or direct porting of programs between the two languages and there are plenty of features between the two that cannot translate.

The second argument about math operations being easier to read is the more relevant argument in my opinion.

[LMLB]

VB's ^ operator can be used in constants.

[MgSam]

@LMLB 's argument is the most convincing to me- C# 7.0 is adding digit separators and binary literals for the "defining a constant" use case, and this seems at least as useful as either of those features.

[gregsdennis]

I think more pertinent to this specific use case is that the operator can be overloaded whereas Math.Pow() cannot.

[JeffreySax]

@gafter

Is this really so much better than

using static System.Math;

    var result = Pow(a, b);

It is.

Exponentiation is no different from addition or multiplication: it is a common mathematical operation for which there is a universal notation (including precedence rules) that is approximated in programming languages.

C doesn't have an exponentiation operator, while it does have operators for closer to the metal operations like bit-wise xor (^) and integer shifts. It seems java and C# inherited this design more or less by default without fully considering its merits. Most modern languages that are more oriented towards user-experience (Python, VB, R...) do have an exponentiation operator.

Furthermore, while operators are in scope and will be used when the defining type is in scope, this is not true for the static import in your example. It doesn't work within the scope of a type that itself defines a Pow method, such as a complex number type or a vector type.

@HaloFour

VB's ^ operator literally just translates into a call to Math.Pow

Not exactly. There are some small differences. For example, the LINQ expression tree for the VB operator uses a binary expression of type Power (where the Method is Math.Pow), while C#'s version uses a method call.

@gregsdennis It is possible to overload the VB operator from C# manually, i.e. by defining a static op_Exponent method with a SpecialName attribute. You can do the same for F#, but the operator method is called op_Exponentiation (section 4.1 of the F# language spec). This is an unfortunate and annoying inconsistency.

It would be better if this was all consistent: have all common mathematical operations available as operators that can be overloaded in the same way and that makes them accessible to all .NET languages.

[CyrusNajmabadi]

it is a common mathematical operation

Citation? :)

[CyrusNajmabadi]

Furthermore, while operators are in scope and will be used when the defining type is in scope, this is not true for the static import in your example. It doesn't work within the scope of a type that itself defines a Pow method, such as a complex number type or a vector type.

If you're in the type itself, you don't need the static import. You can just directly call "Pow(x, y)"

[JeffreySax]

If you're in the type itself, you don't need the static import. You can just directly call "Pow(x, y)"

But you can't access another type's Pow method that is statically imported without qualifying.

In the code below, class A's M method is successfully called from class B. However, in class C, the presence of the M method prevents it from being considered, unless you qualify it:

namespace N1
{
    public class A
    {
        public static void M(string x) { }
    }
}
namespace N2
{
    using static N1.A;

    public class B
    {
        public void M2()
        {
            M("Test"); // OK
        }
    }

    public class C
    {
        public static void M(int x) { }
        public void M2()
        {
            M(12); // OK
            M("Test"); // 'Argument 1: Cannot convert from string to int'
            N1.A.M("Test"); // OK
        }
    }
}

Citation? :)

This is like someone from Texas asking a Canadian for a citation that snow is a common weather phenomenon. :) Just because something isn't common in your experience doesn't mean it's not common for other people.

But since you asked: the code sample in the documentation for the static using directive contains two squares, written out as multiplications.

[MgSam]

Is exponentiation more common or important than square root? Where do you draw the line of which operations are important enough to deserve an operator?

The only benefit, IMHO, is that you can use mathematical operators statically. However, I think the constexpr feature (dotnet/roslyn#15079) is a lot more general so I'd be in favor of that to fulfill that use case rather than adding a new operator.

[iam3yal]

Related #14665 but like @MgSam said please check #15079, if you like the idea join the discussion. :)

[CyrusNajmabadi]

To me, the main issue is that Math.Pow is effectively a prefix notation.

You could add your own extension method to make this infix. then you'd have x = y.Pow(z) which reads well to me.

You full example would be:

A = (2.457 * LOG(1.0 / ((7.0 * ReInv).Pow(0.9) + 0.27 * e_over_d))).Pow(16)
B = (37530.0 * ReInv).Pow(16)

FanningFactor = 2.0 * ((8.0 * ReInv).Pow(12.0) + 1.0 / (A + B).Pow(1.5)).Pow(Exponent)

Which also reads fine to me.

[tannergooding]

There is also notably not a whole lot of difference between the two. You're basically trading ** for , and making the fact that you're doing exponentiation more clear by declaring it up front.

The entire expression as written (for either Fortran or C#) is pretty hard to read. If I saw that code in a PR to dotnet/runtime, I'd like flag it and ask for it to be explicitly broken apart so that it's easier to read and debug. I would likely also require an explanatory comment to exist which gives the mathematical algorithm it corresponds to and an explanation of how its accounting for binary floating-point inaccuracies.

[adamyakes]

To me, the main issue is that Math.Pow is effectively a prefix notation.

You could add your own extension method to make this infix. then you'd have x = y.Pow(z) which reads well to me.

That's a good idea - I think I'll write that extension method. It more or less solves the readability problem for me.

[adamyakes]

There is also notably not a whole lot of difference between the two.

I'd have to disagree with this. Let's take a simpler example. c = a**2 + b**2 reads left to right as "c is a squared plus b squared", or "c is a to the power of two plus b to the power of two", whereas c = Math.Pow(a, 2) + Math.Pow(b, 2) reads "c is the power of (?) a and two plus the power of b and two". It doesn't really work.

You're basically trading ** for ,

This makes makes my point for me - you're trading a context-giving operator, **, for a generic argument separator. You lose the context of what operation is being done.

and making the fact that you're doing exponentiation more clear by declaring it up front.

Putting something up front doesn't make it clearer, especially when sub-expressions are involved. We read infix operators as infix operators. Clarity is lost, not gained, by rearranging standard math operators to fit syntax. Note, things like sin(x) don't break this because those are read "sin of x" already. Granted, a significant portion of this issue can be resolved by writing an extension method as suggested here, but it's bending over backwards to argue that the method syntax is better.

The entire expression as written (for either Fortran or C#) is pretty hard to read. If I saw that code in a PR to dotnet/runtime, I'd like flag it and ask for it to be explicitly broken apart so that it's easier to read and debug.

Math-heavy code generally seems difficult at first, but breaking down equations doesn't always make them easier to read. You're inventing new variables for sub-expressions that don't necessarily mean anything by themselves. What about the distance formula ($\sqrt{(x_1-x_2)^2 + (y_1-y_2)^2}$)? Since we have to write Math.Sqrt(Math.Pow(x1-x2, 2) + Math.Pow(y1-y2, 2)) instead of sqrt((x1-x2)**2 + (y1-y2)**2), what are we going to break it down to? Replace x1-x2 with delta_x? Or Math.Pow(x1-x2, 2) with x_delta_squared? Not every component has a name. You're in fact obfuscating the resulting expression by splitting it up.

I would likely also require an explanatory comment to exist which gives the mathematical algorithm it corresponds to and an explanation of how its accounting for binary floating-point inaccuracies.

Sure, but has nothing to do with whether Math.Pow or ** is used. The code in question is actually inside a function named after the equation it calculates and has documentation.

[CyrusNajmabadi]

I'd have to disagree with this. Let's take a simpler example. c = a2 + b2 reads left to right as "c is a squared plus b squared", or "c is a to the power of two plus b to the power of two", whereas c = Math.Pow(a, 2) + Math.Pow(b, 2) reads "c is the power of (?) a and two plus the power of b and two". It doesn't really work.

c = a.Pow(2) + b.Pow(2) reads eft to right as "c is a to the power of two plus b to the power of two", and seems really clear to me.

but it's bending over backwards to argue that the method syntax is better.

I honestly disagree. This reads great to me. Maybe it's not 'better' per se. But it's easy and extremely clear. So there's little motivation to come up with an alternate given that.

Since we have to write Math.Sqrt(Math.Pow(x1-x2, 2) + Math.Pow(y1-y2, 2)) instead of sqrt((x1-x2)**2 + (y1-y2)**2)

Sqrt((x1-x2).Pow(2) + (y1-y2).Pow(2)) honestly seems great to me.

[tannergooding]

You lose the context of what operation is being done.

You have lost no context, the method name makes it very clear what you're doing.

In the case of a ** b you need to learn that this syntax, which is programming specific (and is not one of the universally agreed upon operators), means a to the power of b; Where-as Pow(a, b) makes it very clear that you're raising a to the power of b. You cannot program in superscript, so you cannot do ab and the more common text syntax of a^b is taken by exclusive-or, so you cannot do that either.

You then have to rationalize that ** is itself somewhat ambiguous when it comes to the overall context of the language because * is used to mean multiple and it's used to mean dereference. You then may have to rationalize what it means in context of other dual operators (++ means increment by one, for example).

Beyond that, you also have to rationalize all the problems and edge cases that exist with this operator. The fact that it's not efficient for integers, that it can trivially overflow for integers (as per a different comment above, you get around 45k valid combinations and of those, ~42.1k of them are x * x, or rather x2), that it requires a deterministic implementation for floating-point (which most runtimes don't actually provide today), etc.

Putting something up front doesn't make it clearer, especially when sub-expressions are involved.

Yes, it can make it harder to rationalize about, but so can very complex arbitrary expressions. That's why it's typical to break your code apart for readability/maintainability.

Math.Sqrt(Math.Pow(x1-x2, 2) + Math.Pow(y1-y2, 2))

This is a terrible way to implement distance. Not only is it incredibly inefficient (calling a function, Pow, for something that is x * x, which can prevent many optimizations) and so you wouldn't ever do this for such a common/core API, but it doesn't account for inaccuracies and so needlessly produces a less correct result.

Even if you were defining it naively and not accounting for precision, you would want to explicitly store x1 - x2 into a temporary so that you can just do:

double dX = x1 - x2;
double dy = y1 - y2;
return double.Sqrt((dX * dX) + (dy * dy))`

Even more ideally, you've appropriately exposed a Point or Vector2 type and exposed this via a helper API, rather than doing it inline, so all the user sees is Vector2.Distance(x, y) and the "complexity" of doing it efficiently or correctly is abstracted away (the BCL does define such an API), and so you get (naively):

public static Vector2 Distance(Vector2 x, Vector2 y)
{
    float sum = Vector2.Sum(x - y);
    return float.Sqrt(sum);
}

has documentation.

Documentation, which exists for the consumer of the API is not the same as code comments, which exists for the implementor/maintainer of an API. One is about the public surface area and the other is about the inner implementation details.

[CyrusNajmabadi]

is itself somewhat ambiguous when it comes to the overall context of the language because * is used to mean multiple and it's used to mean dereference

Note, it's not somewhat ambiguous, It's very ambiguous. For example, this is legal today:

using System;
public class C {
    public unsafe void M(int b, int* a) {
        var x = b ** a;
    }
}

:D

[tannergooding]

What might be more interesting to discuss would be if the language could allow for certain static methods exposed on the type to be accessed like instance methods.

That is to say, today you have instance methods (T M()) defined on T and so for T x you can do x.M(). You can have static methods defined on T (static T M(T value)) and can do T.M(x). You can then define static methods on another class U and define them as extension methods using the this keyword (static T M(this T value)). The extension methods can also be called as U.M(x) if a user desires.

There is, however, no way to allow for a static method defined on T to be considered as an extension method for T and thus while we've defined double.Pow(double x, double y) users are forced to call it via the static syntax.

Perhaps if the language opted to relax its lookup rules to be static class and static methods on T, then we could define double.Pow(this double x, double y) and users could choose if they prefer double.Pow(x, y) or x.Pow(y) (assuming API review also approved such support).

[adamyakes]

I'd have to disagree with this. Let's take a simpler example. c = a2 + b2 reads left to right as "c is a squared plus b squared", or "c is a to the power of two plus b to the power of two", whereas c = Math.Pow(a, 2) + Math.Pow(b, 2) reads "c is the power of (?) a and two plus the power of b and two". It doesn't really work.

c = a.Pow(2) + b.Pow(2) reads eft to right as "c is a to the power of two plus b to the power of two", and seems really clear to me.

but it's bending over backwards to argue that the method syntax is better.

I honestly disagree. This reads great to me. Maybe it's not 'better' per se. But it's easy and extremely clear. So there's little motivation to come up with an alternate given that.

Since we have to write Math.Sqrt(Math.Pow(x1-x2, 2) + Math.Pow(y1-y2, 2)) instead of sqrt((x1-x2)**2 + (y1-y2)**2)

Sqrt((x1-x2).Pow(2) + (y1-y2).Pow(2)) honestly seems great to me.

@CyrusNajmabadi My comment was quoting from and responding to @tannergooding's comment - I actually replied here and also acknowledge in replying that the infix nature of an extension method as you suggested is much more readable.

[rummelsworth]

Math-heavy code generally seems difficult at first, but breaking down equations doesn't always make them easier to read. You're inventing new variables for sub-expressions that don't necessarily mean anything by themselves. [...] Not every component has a name. You're in fact obfuscating the resulting expression by splitting it up.

I work with a lot of old ancient mathematical code on a daily basis. Decomposing expressions, complex or not, is routine for easier debugging, readability, and sometimes discovering improvements. Sometimes there are decent names for the intermediate values (deltaX isn't terrible), sometimes there aren't (e.g. cse for "common subexpression"). In all cases, obfuscation due to decomposition is easy to handle by adding comments. Sometimes it's just a citation (including equation number, page number, section heading, etc) to the paper, book, or URL source in the literature. Oftentimes the citation can be supplemented with some math markup (e.g. plain KaTeX for copy-paste previewing in VS Code, or you can try an extension like TeX Comments 2022+). These comments and the markup can be at whatever granularity the code needs to achieve readability. With this, the code can take its best shape while still being firmly tethered to the formatted presentation/description of its specific logic.

It'd be nice if C# comments (including XML doc) had more convenient built-in support for Markdown-like and/or TeX-like syntaxes. Comments are at least as important as "real code", and it feels like they're just ignored for planning and feature development.

[adamyakes]

@tannergooding I think your reply really misses the mark on the whole point of this discussion: whether an exponentiation operator would be a useful addition to the C# language. Arguing about whether a specific example is optimal in terms of speed or accuracy doesn't have anything to do with whether an operator adds value. The purpose of my examples was to show the benefit of an operator.

Yes, code needs documentation (obviously). Yes, penny pinching CPU cycles could lead someone to trade the brevity of x**3 for x * x * x. Yes, floating point precision should be weighed and accounted for. But what does that have to do with adding an operator? To that end, I won't be addressing the criticism of my specific implementation of the distance formula nor the proposed API changes.

You lose the context of what operation is being done.

You have lost no context, the method name makes it very clear what you're doing.

Here's my original example

A = Math.Pow(2.457 * Math.Log(1.0 / (Math.Pow(7.0 * ReInv, 0.9) + 0.27 * e_over_d))), 16)
// ^ what does this comma mean?

This is the context to which I was referring: the mental ability to parse what's going on. Is all the information technically there for you? Sure. Should the code be broken down? Probably! But it's (subjectively) harder to read, and thus to me serves as a good example. I will reiterate from other replies: I think the extension method (expression).Pow(expression) solves a lot of the readability concerns. But it also serves to point out we've basically invented an infix operator.

In the case of a ** b you need to learn that this syntax, which is programming specific (and is not one of the universally agreed upon operators), means a to the power of b; Where-as Pow(a, b) makes it very clear that you're raising a to the power of b. You cannot program in superscript, so you cannot do ab and the more common text syntax of a^b is taken by exclusive-or, so you cannot do that either.

You then have to rationalize that ** is itself somewhat ambiguous when it comes to the overall context of the language because * is used to mean multiple and it's used to mean dereference. You then may have to rationalize what it means in context of other dual operators (++ means increment by one, for example).

I'm not advocating for ** specifically, just something. Of course Pow is a great, explicit name, but programming is filled syntax you need to learn. Fortran uses () instead of [] for arrays, Haskell uses instead of () for function application. We've got !=, <>, and /= for inequality between languages. (And C# uses /= for compound assignment!) C# has 46 contextual keywords, allows operator overloading, and has introduced something like four new different kinds of string syntax since I've been using it. Difficulties in disambiguating ** aside, "learning syntax" itself is not a concern I share.

[CyrusNajmabadi]

But it also serves to point out we've basically invented an infix operator.

I don't really agree with this. The idea here is that we're not inventing anything. We're using what the language already has and supports. :) And our preference is that if the lang already has a good solution for a problem, we'd prefer to keep using that versus introducing a new solution (cuz now you have multiple :)). So we need strong reasons to add features. And that includes strong arguments for why the existing options available at the language level are not sufficient, and thus why something new does need to be "invented" :)

[tannergooding]

But what does that have to do with adding an operator?

A lot.

If the operator is trivially rejected because it is the wrong thing nine times out of ten or has other super common problems, then that is a reason to not expose the operator.

If there is then a simple alternative, like defining an infix API, which solves the problem and introduces less complexity to the language, that then becomes a better direction. Especially if that also gives users more flexibility for the entire set of math APIs rather than being scoped to simply Pow

// ^ what does this comma mean?

You can trivially create complex expressions even with purely using operators that are hard to read/understand and even where users will commonly get the logic wrong because they misunderstand things like order of operations.

Consider, for example, the following which is only using multiplication and addition. It is part of the real algorithm used to implement double.Log(double x):

(((r04 * C20) + ((((r * C19) + C18) * r02) + ((r * C17) + C16))) * r16) + (((((((r * C15) + C14) * r02) + ((r * C13) + C12)) * r04) + ((((r * C11) + C10) * r02) + ((r * C09) + C08))) * r08) + (((((r * C07) + C06) * r02) + ((r * C05) + C04)) * r04) + ((((r * C03) + C02) * r02) + r)

Which is much more readable, but still very verbose and hard to parse/understand, if you break it apart like this (and it could be more readable/understandable with locals and/or the surrounding comments in the actual code):

     (((r04 * C20)
    + ((((r * C19) + C18) * r02)
      + ((r * C17) + C16))) * r16)
 + (((((((r * C15) + C14) * r02)
      + ((r * C13) + C12)) * r04)
    + ((((r * C11) + C10) * r02)
      + ((r * C09) + C08))) * r08)
   + (((((r * C07) + C06) * r02)
      + ((r * C05) + C04)) * r04)
    + ((((r * C03) + C02) * r02) + r)

Code has to be broken apart for readability/legibility. This is even true in real math and is the whole reason Algebra has named variables.

[GeirGrusom]

is itself somewhat ambiguous when it comes to the overall context of the language because * is used to mean multiple and it's used to mean dereference

Note, it's not somewhat ambiguous, It's very ambiguous. For example, this is legal today:

using System;
public class C {
    public unsafe void M(int b, int* a) {
        var x = b ** a;
    }
}

:D

The probably one (now two) people who wrote a line that looked like that can afford a compilation error I think :)

I have felt the few times I write exponentiation it does look ugly, and tears up expressions a bit, especially when I'm translating from a math formula. Not a hill I would die on, but I wouldn't mind an exponentiation operator either.

[heartacker]

• pow:
  *^, e.g. 2 *^ 3 = 8, Math.Pow(2, 3)

• sqrt:
  /^ e.g. 8 /^ 3 = 2 , (another : 8 *^ (1/3) = 2)

This avoids pointer problems and is also readable

[heartacker]

Indeed, you are right. We do not necessarily need this operator, but we hope to make the C# language more modern and convenient. That is the reason we are having this discussion. While we are not language design experts or compiler engineers, we have a simple and practical request: to make C# better by adopting and improving upon excellent features.

The issues you mentioned are indeed significant, and some are critical and must be addressed. Through this discussion, we aim to better understand these issues and find reasonable solutions.

Let’s revisit the topic:

• Is the pow operator a feature that developers are looking forward to?
  I believe it is. Otherwise, we wouldn’t be discussing it here, and we can also observe that other mainstream languages have already introduced similar features.

• Can we find a suitable operator?
  Yes, we can. Even if some people may feel that the chosen operator is not elegant enough, it is not entirely unacceptable.

• How should it be implemented? Is it worth developing this feature?
  This is the core of our debate and requires further in-depth exploration.

Rather than continuing to argue in this thread, let’s take a step back and think through this systematically. Let’s assume we do need to implement this feature. As an expert in this field, could you list all the relevant issues, potential risks, and possible solutions? We can organize these into a table, covering topics such as priority, type conversion, precision, and so on. Then we can review them one by one to see if there are ways to address them.

Additionally, we can learn from how other languages have implemented similar features. For instance, MATLAB, a leader in mathematics, engineering, algorithms, and simulation, has a pow operator. It has achieved industry-accepted standards of precision and performance. If MATLAB can do it, we believe C# can achieve even better results.

C# is a language I deeply love. I believe we should not only adopt excellent features from other languages but strive to implement them in a way that surpasses others.

[tannergooding]

Is the pow operator a feature that developers are looking forward to?

This notably needs to be quantified more as every feature has some number of developers that would look forward to it. There are often many more users that don't care either way and some number of users that would actively dislike such a feature.

The more meaningful question tends to be what the impact of such a feature would be; how does it impact the entire community/ecosystem via both pros and cons, etc.

Can we find a suitable operator?

"Suitable" is also a bit up for debate. Some operator could indeed be found, the suitability comes down to some level of opinion and general attempt to quantify the impact of such an operator being used.

Let’s assume we do need to implement this feature.

This is a faulty position to start from as there isn't a need. While I understand what you're trying to get at here, proposals need to come from the right direction and premise in the first place, not from a theoretical position.

There is fundamentally no "need" and so the right place to start is by listing out concrete examples (not theoretical ones) of where such an operator would get used in your code bases. You then need to additionally provide information on how this provides substantial benefit to the code, particularly in contrast to existing alternatives and why those existing alternatives are painful.

As an expert in this field, could you list all the relevant issues, potential risks, and possible solutions

I've listed a great many of these above, it would be ideal if someone who's actively interested in the proposal (rather than actively opposed) would do the legwork to try and aggregate the issues/concerns listed and drive meaningful solutions.

I'm happy to follow up and help ensure that the bits raised are generally accurately captured; but I have zero interest in spending more direct time investment in a feature that I truly believe is dead on arrival.

A (non encompassing) summary of the issues raised are that:

• For any of the fixed-width integer types
  • I believe exposing is a non-starter
  • the common needs (pow2, pow10) have much simpler/cheaper implementations
  • almost any other input will cause an overflow in practice
• For BigInteger
  • There is potential for such an operator
  • but it's similarly a case where the common cases are better handled by explicit alternative helpers as they are specialized to be much more efficient so its often the "wrong" thing to use
• For floating-point
  • there is potential for such an operator
  • however, there are concerns around the complexity of a correct implementation (which is required for constant folding)
    • most C pow implementations are not strictly IEEE 754 compliant and produce results that may differ by several ULP (units in last place) based on hardware
    • implementing a correct pow function is very expensive and can not be backported to older framework versions
    • implementing a correct pow function is also tricky, and getting it "wrong" means added risk as means any constant folding could be incorrect
  • there are also concerns over there being multiple IEEE 754 defined pow functions (pow, powr, and pown; plus powd for decimal)
    • each of these has slightly different semantics and while the main we expose is pow there are plans to expose the others in the future
    • having multiple means that the operator can only pick one and the others will be stuck with calling a function
  • you also have the same general concern of pow often being undesirable to call, more frequently you want x * x for pow(x, 2), you want to do a cheaper x * x * x and account for rounding error for pow(x, 3), you want to use alternative functions like Exp2 for pow(2, x) or Exp10 for pow(10, x), etc
• There is then the consideration around the operator being used
  • The most obvious ^ is taken to mean exclusive-or and cannot be used; this is also the case in most languages and is why they don't use it
    • correspondingly you don't want to use ^^ which might get confused to mean something similar to || and &&
  • The next most obvious is ** and is what many other languages use. This is sensical because pow is like multiplication to the next level
    • however, this cannot be used because it causes potential ambiguities and breaks in the existing syntax, particularly around pointer dereferences
    • even though pointer dereferences are rare, as is not having spacing around the variables and operators; it's not the type of break that can be taken
  • This leaves deciding on a new operator, this new operator will be functionally unique across all languages and so already starts at a disadvantage
    • this includes a disadvantage to readability, to understandability, to approachability, etc
• There is then the consideration about potential ambiguities
  • every language interprets chains of powers differently, so x ** y ** z and what it means needs to be determined (even if unlikely to be encountered)
  • it's precedence in relation to other operators, including unary operators, needs to be determined
    • in particular there is a subtle ambiguity that occurs, especially in programming languages, around -x ** y and whether that is (-x) ** y or -(x ** y)
    • depending on how the logic is written, then -float.Pow(x, y) and -x ** y may produce different results, leading to potential bugs
• I know I've written a lot of other details elsewhere above, calling out various problems, issues, and beyond; I also know there's others that I haven't called out at all yet but which still exist and need to be considered as part of any design effort.
   

For instance, MATLAB, a leader in mathematics, engineering, algorithms, and simulation, has a pow operator. It has achieved industry-accepted standards of precision and performance. If MATLAB can do it, we believe C# can achieve even better results.

Different languages and different ecosystems have different designs and different considerations. One or even many languages supporting something is not necessarily a good reason for another to do the same.

MATLAB for instance is targeting a very specific domain and userbase, the types and operations it exposes are doing a lot of "extra" stuff to allow it to be used for mathematical operations and so that mathematical expressions work and can be simplified in a way that matches "real math".

Python similar is designed to abstract more of the type system away and defaults to everything being a "BigInteger" and in general doing operations with "unbounded range". There are both pros and cons to this, but it fits for the design of their ecosystem.

C# on the other hand is a member of the C family of languages and its general syntax, type system, and other elements are much lower level correspondingly. You get fixed-width integers, fixed-width binary floating-point types, things that cleanly map to simple CPU instructions, type layouts that allows clean blittable interop with the underlying platform ABI, etc. You get a lot more control with an expansive base class library that provides helper methods for doing common operations.

What this means is that things like pow which work in MATLAB and Python do not work well in C# (and is also why such operators aren't found in C, C++, Java, or other "similar" languages).

Similarly some of the core features C# has like unsafe code, explicit struct types, fixed sized types, checked arithmetic, pointers, simple interop with C, and many other considerations are amazing in C#, but would not translate well into MATLAB, Python, or even Java.

[heartacker]

Thank you for your continuous explanations.

I don't know much about programming language design, compilers and other fields.
I hope that more professionals in these aspects can keep following up and doing research.
As an csharplang user, I really want this feature. Especially with my continuous efforts in scripts, like dotnet/interactive.

However, as we all can see, we don't have this feature now, and it's impossible to have it in a short time either.
So we still have to write code using function interfaces instead of operators. It's particularly cumbersome when writing interactive scripts, but there's nothing I can do about it.

If anyone now knows how to add illegal operators in the C# language (for example, by means of Source Generators), I will not hesitate to use it in my personal projects. After all, my projects may not involve special, high-precision scenarios. I'm just doing basic calculations. It's enough to directly replace Math.Pow.

Thank you all for the discussion. I've learned a lot here.

[Rekkonnect]

Let's take a step back and assess what drives this desire in the first place. More often than not, as a user, I hate having to type Math.Pow because it breaks my fluent flow in other areas in the code. And for floats, I must resort to MathF.Pow.

What I do in these cases is define some extensions to make it easier to type out and less confusing when coming up with the code. So I can then write x.Square() and it hides x * x.

The must-haves from what I've encountered at least are Pow, Square and Sqrt. And sometimes I don't even have to define them generically, or even for more than one type.

The only annoying part really is that you don't have many useful mathematical operations to perform on numeric types by dotting the expression. This is just a lack of expressivity and it's more profound after the introduction of generic math, which revolutionized the way we can abstract common operators. It follows that we can have such extensions simply and extensibly defined over INumber.

I see that you're very focused on the exponentiation operator itself, rather than the need it covers. For most languages like Tanner explained, it's just a natural fit. For C# it's a forced fit. And I, as a user, would rarely remember its existence. I'd much rather have proper instance or extension methods to apply on an expression of a number type, rather than a baked-in opinionated operator (see algorithm implementation concerns).

My personal view as a user at least is that the operator doesn't quite fit the language, if there're so many needles to avoid and so much discussion to be had. Far from it in fact, all we really lack is discoverability and quickness in writing that down.

Plus, operators are generally not my cup of tea. If it's not standard arithmetic or bitwise operators, I don't even consider their presence, unless the API forces me to use them for whatever reason. Naturally I favor named functions much more than operators, especially since they break the fluent flow as I also mentioned above.

[tannergooding]

I hate having to type Math.Pow because it breaks my fluent flow in other areas in the code. And for floats, I must resort to MathF.Pow.

Notably, since .NET 7 you have double.Pow(x, y) and float.Pow(x, y). In general you also have access to T.Pow(x, y) for anything where T : IPowerFunctions<T> (namely the IFloatingPointIeee754<T> types).

I'd much rather have proper instance or extension methods to apply on an expression of a number type, rather than a baked-in opinionated operator (see algorithm implementation concerns).

I do personally think, as was covered in another thread above, this is a more interesting aspect. Ultimately the decision for things like Sqrt(x) vs x.Sqrt() is namely a stylistic one, but it's currently limited by what the BCL exposes. There's in part an aspect where getting API review to approve exposing both is unlikely, but there's another aspect in that it requires duplicating API surface area in a generally undesirable way as you need both the T.Pow(T x, T y) and some extension method on a static class T Pow(this T x, T y), so they cannot be the "same API".

If the language had some feature that allowed us to say that the extension method could be the member that's defined on T, that might be an easier sell.

---

Something that can be done in the interim, however, is someone could define a 3rd party package that provides the necessary extensions:

public static class FluentPowerFunctions
{
    public static T Pow<T>(this T x, this T y)
        where T : IPowerFunctions<T>
    {
        return T.Pow(x, y);
    }
}

public static class FluentRootFunctions
{
    public static T Cbrt<T>(this T x)
        where T : IRootFunctions<T>
    {
        return T.Cbrt(x);
    }

    public static T RootN<T>(this T x, int n)
        where T : IRootFunctions<T>
    {
        return T.Root(x, n);
    }

    public static T Sqrt<T>(this T x)
        where T : IRootFunctions<T>
    {
        return T.Sqrt(x);
    }
}

I'd be happy to expose such a 3rd party library if enough people thought it worthwhile. If I exposed it as part of my TerraFX project (which is in scope to many of the other libraries/helpers I provide) then I can even ensure that it is signed, versioned, etc