No idea why this happened. Perhaps Math.Pow(x,y) was implemented as 2**(y*log2(x)) without writing special code to deal with the case where x is negative real and y is integer?
Math.Pow(-1, 2) == -1 in Windows 11 Insider build
21–30 of 142 posts
Re: Math.Pow(-1, 2) == -1 in Windows 11 Insider build
#22Earlier quoted context omitted.
Microsoft is a many headed beast. Finding the right contact even for employees inside the beast is challenging and a skill all its own.
I'm more used to hear this kind of 'it's not our fault' crap from state bureaucracies not companies that want me to pay them...
When a company has its street named after themselves and a fleet of buses to carry employees to the company, one can start considering Microsoft as a state with all the necessary bureaucracy.
Re: Math.Pow(-1, 2) == -1 in Windows 11 Insider build
#23Earlier quoted context omitted.
Microsoft is a many headed beast. Finding the right contact even for employees inside the beast is challenging and a skill all its own.
I'm more used to hear this kind of 'it's not our fault' crap from state bureaucracies not companies that want me to pay them...
For stuff where they take money, like Azure, Microsoft has clearer lines of support. .NET and Windows are loss leaders.
Re: Math.Pow(-1, 2) == -1 in Windows 11 Insider build
#24Side note. One of the advantages of using proprietary packaged software is supposed to be a unified support and product. In this case the maintainer redirects the issue to some other team and passes the ball as if it were an open source project with 50 dependencies with thin responsibilities "no, if there's an issue with a button, you should report it to GUI-button, we do GUI-form and we just pass the button generati…
The maintainer is not a Microsoft employee. For what that’s worth.
Re: Math.Pow(-1, 2) == -1 in Windows 11 Insider build
#25Re: Math.Pow(-1, 2) == -1 in Windows 11 Insider build
#26Earlier quoted context omitted.
Clearly the issue is real and not imaginary
There are no imaginary numbers insolved in this bug, however.
Although, if (-1)^2=-1, then the question that generates imaginary numbers doesn’t even come up, right? Clearly the square root of a negative is well defined.
Re: Math.Pow(-1, 2) == -1 in Windows 11 Insider build
#27How did this happen? This feels like the easiest function in the world to write a unit test for?
Re: Math.Pow(-1, 2) == -1 in Windows 11 Insider build
#28This happens in both C# and C++ according to the report, but what's the link between OS and compiler here? As far as I remember from days when I used Windows, the version of your visual studio (which has the compiler and standard libraries) was not related to the build of your operating system
Probably isn't a link between the OS and compiler. the OS kernel is responsible for saving and restoring the floating-point environment every time there's a context switch, my hypothesis is that something went wrong there.
Re: Math.Pow(-1, 2) == -1 in Windows 11 Insider build
#29Side note. One of the advantages of using proprietary packaged software is supposed to be a unified support and product. In this case the maintainer redirects the issue to some other team and passes the ball as if it were an open source project with 50 dependencies with thin responsibilities "no, if there's an issue with a button, you should report it to GUI-button, we do GUI-form and we just pass the button generati…
The buck is passed all of the time, it simply happens internally and out of sight of the customer. In this case, it looks like an open source component managed by a commercial company. They could do everything out of sight, but the open source world also encourages transparency.
Re: Math.Pow(-1, 2) == -1 in Windows 11 Insider build
#30I disagree with the comment “Both Math.Pow and std::pow invokes the pow function in UCRT, which is shipped with Windows. The issue should be reported to MSVC instead” It’s not the job of a bug reporter to figure that out and to verify that nothing goes wrong in setting up stuff for invoking that function or in getting its output back into the C# world. That’s even more true because the dynamic nature of .NET code mak…
What do you disagree with, exactly? The bug is in an underlying library, so it should be reported to that library. That all seems correct to me, I don't see what there is to disagree with there.
The problem with the comment is it does not make ownership of the next steps clear. The maintainer should've either taken the ball ("I will report this to...") or made it clear that the reporter should hold the ball ("We can't fix this here. You should report it to..."). Instead they used the passive voice ("The issue should be reported to..."), which means no one owns it, which means it won't be done, which is a bad way to handle a bug report.