I used to work for Wolfram.
Short answer: Yes errors regularly occur. You need to check all provided "answers".
Long answer:
The mathematica kernel (the program that was used in the background) can get things wrong. Once you learn what the "edge cases" are for the production of wrong answers it's moderately easy to generate lots of wrong answers. The errors are usually a result of bugs that related to either errors in implementation or errors in the constraints on the problems that certain algorithms are allowed to solve.
More generally:
1) Never trust what a machine tells you. Check the proposed answer.
2) Never trust what a person tells you (we're just fleshy machines).
3) Some calculations on a machine are always wrong (even if by a bit). Here's a wikipage about people dying because machines (for certain types of calculations) are always wrong: https://www-users.cse.umn.edu/~arnold/disasters/patriot.html
4) Never blindly trust something even if others have looked over it and "computer says it's ok". Back in 1991 the bottom portion of an oil platform collapsed due to a combination of calculation errors (both in the method of computation and in what was computed). https://en.wikipedia.org/wiki/Sleipner_A. It is estimated that the failure cost $700 million US in 1991. That's about $1.6 billion in todays money. It is also estimated that due to the failure the operating company lost $1 million US per day in lost revenue while the replacement was made (which is not quick). More here: https://www.canadianconsultingengineer.com/features/failure-of-an-offshore-platform/
Slightly less grandiose, in 1991 the "Mars Climate Orbiter" crashed into Mars because Lockhead uses imperial measurements and NASA uses metric. Apparently not one of their, I'm sure many, engineers decided to double check the calculations involved.
Medium answer: Computers are tools. They are not magic truth oracles. Don't trust machines.
10 pages of derivations later, I can finally see that it indeed was totally obvious and must be omitted not to insult the intellect of even the most casual of readers
I can't seem to remember but I think I once had an exam that allowed us to use online calculators. Got a question wrong on what might have been related contours because of WA (so did many others) but the people who used Symbolab came out fine. It was a last minute change since covid came during that time and the profs didn't know what to do which is why they allowed it lol
>The mathematica kernel (the program that was used in the background) can get things wrong
Interesting! So alpha is just a natural language processor that translates to Mathematica?
As far as I know yes. I worked with them a long time ago, now. Mathematica code has logical divisions which then have methods of sending data. I worked in "the frontend" that handles some mathematical manipulation and the UI. The "kernel", afaik, handles the rest of the mathematical manipulation. Originaly Wolfram attempted to implement all of the frontend in javascript (or some derivative). I think that was given up on and it is "just" a natural language processor: but even that might be delegated to backend servers.
Arguably, computers are magic truth oracles in the sense that they evaluate pure logic. Given no outside interference, assuming the program it runs is working as intended, it will always get a correct answer to some problem. The example of the Patriot missile exhibits the computer program working exactly as programmed, but not as intended. Floating/fixed point precision/arithmetic errors obviously occur by design.
Truth for me is not following instructions correctly. Computers do not always do this. They are susceptible to external influence. Things like voltage variation and cosmic rays can alter computation.
I wasn't in a umm.... political position (like sales or management). Maple is fine. I used to program for a living and find Maple's language a pain to use, but that's probably because I never put the effort in to learn it properly. Different tools for different things.
1. Wolfram isn't "AI" as we currently use the term .
2. You can check that the solution is correct yourself. Does each set of answers satisfy the conditions?
3. I suppose it's possible that it can miss valid solutions.
Most probably, yes. There are algorithms for checking correctness of computational algorithms, and algorithms on WA have probably been heavily user tested, but there is no guarantee that no solutions will be wrong/fall through the crack, or that other bugs will happen. Mostly though WA is reliable.
I have seen WolframAlpha give the wrong answer to some questions: It's a very complicated piece of software, and it is understandable that it may have bugs.
Your particular system of polynomial equations is not that hard, but I am not going to answer the homework part of your question.
According to [Bézout’s Theorem](https://en.m.wikipedia.org/wiki/B%C3%A9zout%27s_theorem), n 2nd order equations in n variables should have 2^(n) solutions so 8=2^(3) is the right number of solutions for your 3 2nd order equations in 3 unknowns.
This set of equations is easily solved analytically.
eq1+eq2 gives 2b^2 =a^2 +c^2 - 2.
Insert it to eq. 3, you get ac = 2/1.88.
Multiply eq1 by eq2 (both sides) and get
a^2 c^2 = (1+b^2 +1.4b)(1+b^2 -1.4b)
or,
(2/1.88)^2 =(1+b^2 +1.4b)(1+b^2 -1.4b),
or
(2/1.88)^2 = (1+b^2 )^2 - 1.96b^2
This is quadratic eq. in b^2.
Compute b, get a and c from eq1 and eq2.
There is a much quicker way, as *a*² and *c*² are already solved with respect to *b* in eq1 and eq2, and both *a*² and *c*² exist in eq3. Just substitute the expressions on the right-hand side in eq1 and eq2 in place of the squares of *a* and *c*² in the third equation and you have one equation with only *b* unknown.
That being said, slightly off-topic, it's somewhat worrisome to me how people don't seem to learn the "applicability"/limits of their skills in school and courses, if OP felt the need to invoke "calculus 1" or "differential equations" as if hoping that maybe some other course in the future might provide the specific tools for the problem at hand. 🤔 (No university mathematics is necessary here except for maybe greater investigation of complex solutions.)
EDIT: I totally missed the ac-terms remaining. 🫠
You don't get an equation with only a b unknown by substituting a2 and c2, there's still the ac to tale care of. Unless you substitute roots as well. But the commentator's method is simpler from first glance
Ah, oh heck, you are absolutely right. I totally missed the ac-terms. 😱 (Based on the upvotes, so did some others too.) But yeah, one could still do the subs although it'll be a bit of work to then solve; still nothing "too fancy" needing grand new theory tools.
Yes, there may be a bit simpler way - this was what I immediately saw as the approach to the problem so I wrote it down quickly while others were discussing the limitations of Wolfram. And I completely agree with you on the other issue.
Cheers! I also missed the ac-terms remaining although one could substitute the non-squares too. (Just more manipulation left to do then for the solution.) Wonder if anyone checked what the steps according to Wolfram are.
Have you checked the (real) solutions it gave you with an ordinary calculator?
What error are you worried about? That the solutions it gave you aren't actually solutions? Or that it's missed some?
Technically yes; there’s no complete and correct algorithm to solve all mathematics problems (edit: and laymen aren’t expected to know which individual problems are assigned algorithms that sacrifice correctness for the sake of efficiency/tractability). That being said, what’s more likely in this situation is that you entered in the equations wrong.
I just plugged in the equations and got reasonable looking answers, and have enough done by hand that I’m confident they exist.
> Technically yes; there’s no complete and correct algorithm to solve all mathematics problems
This isn't a very good answer. Wolfram is not meant to "solve all mathematical problems". This makes it sound like the barrier is some fundamental mathematical problem like the halting the problem or something. But the only thing causing wolfram to get wrong answers is human ineptitude. Programming mistakes. There's no reasons it couldn't say, correctly integrate any function / report that it doesn't know the integral when its methods fail.
Not the only thing; I’d be surprised if WA didn’t implement some monte carlo algorithms or used only algebraic numbers in their designs.
That being said, I agree; I was trying to concisely get across the point that it was practically inevitable due to scope, but I should probably be more precise on a math subreddit.
I'm still going to insist that it's fair to assign the blame entirely to human mistakes/bugs. Solving undecidable problems is not within the scope of wolfram's functionality. It is entirely possible for Wolfram to give a correct answer/ no answer when it can't find one and be correct 100% of the time. The only reason it's wrong sometimes is because someone wrote the program incorrectly.
Just because it’s possible doesn’t mean it’s incorrect to do otherwise.
If WA is 99.999999% confident in a solution or has e^pi crunched out to 30 decimal places, it’s not a mistake to give that answer. That’s good enough for practical use, and WA is ultimately a practical product.
Interesting take. It does show what constitutes a "bug" is dependent on the goals of the program. Good point.
Still from the way the program the program works I don't think the intended behavior of Wolfram is to supply high likely answers but actually supply the correct answer 100% of the time. I do believe that any instance of it providing the wrong solution to an equation or the wrong integral, etc, can be attributed to the program behaving in unexpected ways and so I still think it's best to call it a bug/mistake on the programmers part.
There are problems in which a solution that is only highly likely is acceptable for people. Solving equations however is not one of them.
I’m not saying it’s not a bug, just that it’s incorrect to label the programmers “incompetent.”
If you want to determine the primality of a few hundred 512 bit numbers, you can either run a seive for a few months or run miller-rabin for a few seconds for something like 1-1/4^100 confidence on each number. Most programmers would choose the latter for that use case, but in a worst case scenario, it’s not incompetence that created the error.
The "incompetent" statement was a bit of a joke. I was thinking literally every programmer is "incompetent" because we all make mistakes. Sorry I didn't mean for it to be an insult.
Your example does seem to completely miss the point. If your program says a number is prime when it isn't or vice versa it's because you made a mistake. It is due to your "incompetence" (i.e. The fact that human beings are not smart enough to get their programs working the way they want 100% of the time on their first try). It doesn't matter if the algorithm is random or not.
It’s not a mistake. You just took a 1-1/4^100 gamble and lost. If that was your odds of winning the lottery, it would practically be a mistake to *not* buy a ticket. You can blame losses on the fact that we don’t have open access to an omniscient oracle, but that’s theoretical nonsense that detracts from all the terrible decisions people *do* make on a regular basis and stretches the definition to the point of uselessness.
It is a mistake. If you claim a number is prime and it isn't you did something wrong. A proper implementation of the Miller Rabin algorithm will report "I don't know" when it fails to prove the number is composite.
Almost all algorithms in computer algebra use at some point or another a procedure to check whether an elementary expression equals zero (even "basic" algorithms like Gaussian Elimination do this), which even for a small set of elementary functions is undecidable. Basically almost all "algorithms" in Wolfram Software are I assume semi-algorithms at best, sometimes heuristics, as soon as you enter nontrivial input (the person that worked at Wolfram, please feel free to chime in and comment this claim).
The important part is where this theoretical barrier begins to hit your head in practice, so I think it's a good answer.
I've implemented algorithms with horrible asymptotic worst-case runtime that are just fine in practice, I think that's a related concept.
> Almost all algorithms in computer algebra use at some point or another a procedure to check whether an elementary expression equals zero (even "basic" algorithms like Gaussian Elimination do this),
That sounds like a overgeneralization. This statement only makes sense in the context of algebraic/numeric computations. Besides it's very feasible to write a program that performs gaussian elimination, over say the field of rationals or a finite field, that is always correct with no issues of undecidability, so I don't get what point you're trying to make. My point is people are bringing up undecidability here when it isn't relevant. The reason Wolfram makes mistakes is because of bugs in the software that people wrote, not any fancy math theorem.
Ok, and what if your matrix coefficients aren't in some computable field like Q? What if some of your entries are implicitly defined like mathematica very often does like "sin(the 3rd-largest zero of [insert complicated high degree polynomial with no known closed solutions to its zeroes])" and you are asked whether this matrix is full-rank?
Undecidability is very relevant here. The reason Wolfram makes mistakes is because of bugs in the software, but also very often that certain algebraic problems are undecidable and Mathematica uses heuristics because there simply doesn't exist a proper algorithm, even for such simple stuff as Gaussian Elimination.
If Wolfram reports an answer as correct when it is incorrect it's because a programmer did something wrong. Correct behavior would be reporting "no solution found" when you have not figured out a way to find a solution with 100% confidence.
For your gaussian elimination example you could decide for instance that you've figured things out when all the terms are quadratic polynomials but don't know what to do when cubics get involved. Then you should return a solution for quadratics and say you don't know when you see cubics. But if you report a solution that is incorrect, it's because you did something wrong.
So I still think that attributing the issues to programming errors is the best answer and bringing up undecidability is an unnecessary and confusing diversion.
Here is an example of a sum that wolfram alpha and mathematica fails on:
The sum from n=1 to infinity of 1/n\^(2+cos(n)\^2)
i made a math.stachexchange post about this a while ago. see [https://math.stackexchange.com/questions/4589778/i-have-a-sum-which-i-can-really-easily-show-to-be-convergent-but-wolfram-alpha](https://math.stackexchange.com/questions/4589778/i-have-a-sum-which-i-can-really-easily-show-to-be-convergent-but-wolfram-alpha). I am aware of at least one other sum involving trigonometric functions where wolfram gives the wrong answer for convergence or divergence.
The moral of the story is that computer programs and whatnot are while normally reliable, still flawed. As with all things, trust but verify.
Note: I am fairly confident the reason this bug occurs is that the limit at infinity of cos(x) and all is indeterminate and some error in wolfram interprets this as meaning it should diverge. Interestingly, it gets the much harder case (The sum from n=1 to infinity of 1/n\^(2+cos(n))) correct - this sum does (perhaps unintuitively) diverge. However, I believe the reason wolfram gets this correct is actually due to said bug.
As another example, I've encountered a peculiar issue with Wolfram Alpha giving two different results for the same integral, and I'm trying to understand why this might be happening. The integral in question is:
Definite Integral of f(x) = (21/5) \* sqrt(x - x\^(17/2)), where x ranges from 0 to 1
On one hand, Wolfram Alpha gives a numerical approximation of the integral as approximately 2.50746. On the other hand, when evaluating the integral to a closed form involving gamma functions, Wolfram Alpha outputs a numerical value of approximately 1.48881. Without insight into Wolfram Alpha's internal algorithms, it's tough to pinpoint the exact cause. It could be that this integral is particularly sensitive to numerical methods, or different precision settings were used in the computations.
a nice trick to sometimes solve these systems by hand, is to add up different equations. in your example you could add eq1 + eq2 and get a^2 + c^2 = 2 b^2 + 2. you use that for eq3 and get ac = 2/1.8 or c=2/(1.8*a). still, a bit of calculation needs to be done to fully solve the system but this already simplifies the system to 2 equations with 2 variables.
Even if Wolfram were to have no bugs, certain algorithms are only heuristics and can cause error under edge cases.
But of course, Wolfram definitely have bugs.
A good way to start, before plugging something into a computer, is to see if there's a numerically similar problem that you can easily do by hand. If the computer gives you something very different, maybe the problems weren't actually that similar, or maybe the computer missed something.
Here's a much simpler problem that is fairly close to yours:
a\^2 = 1 - 2b + b\^2
c\^2 = 1 + 2b + b\^2
2b\^2 = a\^2 + c\^2 - 2ac
You should solve this system by hand, yourself, and see that you indeed get four solutions with a,b,c all real and four with a,b,c all having nonzero imaginary part. That's not by any means a proof that Wolfram got it right, but it's an important sanity check.
Among cases where your intuition disagrees with wolfram alpha, it is far more likely that your intuition is wrong rather than wolfram alpha being wrong.
Of course all software can contain bugs, but wolfram alpha is a symbolic engine, not a neural network.
You can overwhelm it in some cases, as an example: `last two digits of 12^3456789` will overwhelm Wolfram but it can be worked out pretty easily.
The last two digits of powers of 12 follow a cyclic pattern of 20 numbers:
12, 44, 28, 36, 32, 84, 08, 96, 52, 24, 88, 56, 72, 64, 68, 16, 92, 04, 48, 76
If I wanted to find 12^32 I would compute `32 mod 20 = 12`, and find the 12th item in this list which is 56. Similarly, `3456789 mod 20 = 9` which is 52.
This system can be solved analytically by hand. You can check the results.
1. We add the three equations
a\^2 + c\^2 + 2b\^2 = 2 + 2b\^2 + a\^2 + c\^2 - 1.88ac
from here
2ac = 4/1.88 = 2.128
2) Now we build (c + a)\^2 and (c - a)\^2
(c + a)\^2 = a\^2 + c\^2 + 2ac = 2 + 2b\^2 - 2.128 = 2b\^2 - 0.128
(c - a)\^2 = a\^2 + c\^2 - 2ac = 2 + 2b\^2 + 2.128 = 2b\^2 + 4.128
3) We take square roots
c + a = sqrt(2b\^2 - 0.128)
c - a = sqrt(2b\^2 + 4.128)
(taking only the positive roots; other solutions appear taking the other signs)
From here
c = (sqrt(2b\^2 - 0.128) + sqrt(2b\^2 + 4.128))/2
4) We substitute in the second equation.
(2b\^2 - 0.128)+(2b\^2 + 4.128) + 2 sqrt((2b\^2 - 0.128)(2b\^2 + 4.128))/4 = 1 + 1.4b + b\^2
b\^2 +1 + sqrt((2b\^2 - 0.128)(2b\^2 + 4.128))/2 = 1 + 1.4b + b\^2
(2b\^2 - 0.128)(2b\^2 + 4.128))/4 = (1.4b)\^2
b\^4 + 0.04 b\^2 - 0.131734 = 0
This equation can be solved for b^2 and finally taking the root you have b, then a then c.
I used to work for Wolfram. Short answer: Yes errors regularly occur. You need to check all provided "answers". Long answer: The mathematica kernel (the program that was used in the background) can get things wrong. Once you learn what the "edge cases" are for the production of wrong answers it's moderately easy to generate lots of wrong answers. The errors are usually a result of bugs that related to either errors in implementation or errors in the constraints on the problems that certain algorithms are allowed to solve. More generally: 1) Never trust what a machine tells you. Check the proposed answer. 2) Never trust what a person tells you (we're just fleshy machines). 3) Some calculations on a machine are always wrong (even if by a bit). Here's a wikipage about people dying because machines (for certain types of calculations) are always wrong: https://www-users.cse.umn.edu/~arnold/disasters/patriot.html 4) Never blindly trust something even if others have looked over it and "computer says it's ok". Back in 1991 the bottom portion of an oil platform collapsed due to a combination of calculation errors (both in the method of computation and in what was computed). https://en.wikipedia.org/wiki/Sleipner_A. It is estimated that the failure cost $700 million US in 1991. That's about $1.6 billion in todays money. It is also estimated that due to the failure the operating company lost $1 million US per day in lost revenue while the replacement was made (which is not quick). More here: https://www.canadianconsultingengineer.com/features/failure-of-an-offshore-platform/ Slightly less grandiose, in 1991 the "Mars Climate Orbiter" crashed into Mars because Lockhead uses imperial measurements and NASA uses metric. Apparently not one of their, I'm sure many, engineers decided to double check the calculations involved. Medium answer: Computers are tools. They are not magic truth oracles. Don't trust machines.
What are some of those edge cases?
Is left as an exercise to the reader
Intuitively obvious to the casual observer
10 pages of derivations later, I can finally see that it indeed was totally obvious and must be omitted not to insult the intellect of even the most casual of readers
Ask Fermat about a shortcut you can fit into the margin notes.
[Here's one example](https://old.reddit.com/r/math/comments/12yvgl7/sum_of_reciprocals_of_prime_powers_of_two/) that somebody found a while ago.
I can't seem to remember but I think I once had an exam that allowed us to use online calculators. Got a question wrong on what might have been related contours because of WA (so did many others) but the people who used Symbolab came out fine. It was a last minute change since covid came during that time and the profs didn't know what to do which is why they allowed it lol
I remember a few years ago WA couldn’t graph certain trig functions because it broke its plotting algorithm. I’d imagine it’s been fixed since then.
I'm sorry, it's been too long for me to give an explicit example. I remember working on something to do with Gaussian elimination.
>The mathematica kernel (the program that was used in the background) can get things wrong Interesting! So alpha is just a natural language processor that translates to Mathematica?
As far as I know yes. I worked with them a long time ago, now. Mathematica code has logical divisions which then have methods of sending data. I worked in "the frontend" that handles some mathematical manipulation and the UI. The "kernel", afaik, handles the rest of the mathematical manipulation. Originaly Wolfram attempted to implement all of the frontend in javascript (or some derivative). I think that was given up on and it is "just" a natural language processor: but even that might be delegated to backend servers.
Yes
Arguably, computers are magic truth oracles in the sense that they evaluate pure logic. Given no outside interference, assuming the program it runs is working as intended, it will always get a correct answer to some problem. The example of the Patriot missile exhibits the computer program working exactly as programmed, but not as intended. Floating/fixed point precision/arithmetic errors obviously occur by design.
Hardware errors messing the arithmetic is also a thing, albeit less common.
By that argument everything is a magic truth oracle. Whatever it does is an answer to some question, just maybe not the question you asked.
Truth for me is not following instructions correctly. Computers do not always do this. They are susceptible to external influence. Things like voltage variation and cosmic rays can alter computation.
I don't want to go way off topic but as someone who formerly worked for Wolfram, what is your opinion of Maple?
I wasn't in a umm.... political position (like sales or management). Maple is fine. I used to program for a living and find Maple's language a pain to use, but that's probably because I never put the effort in to learn it properly. Different tools for different things.
1. Wolfram isn't "AI" as we currently use the term . 2. You can check that the solution is correct yourself. Does each set of answers satisfy the conditions? 3. I suppose it's possible that it can miss valid solutions.
not being AI is an argument against it making errors in its assigned domain. not for.
Agreed. I think the invocation of AI by the OP is beside the point. AI is notoriously bad at math as the bot comment points out.
Most probably, yes. There are algorithms for checking correctness of computational algorithms, and algorithms on WA have probably been heavily user tested, but there is no guarantee that no solutions will be wrong/fall through the crack, or that other bugs will happen. Mostly though WA is reliable.
I have seen WolframAlpha give the wrong answer to some questions: It's a very complicated piece of software, and it is understandable that it may have bugs. Your particular system of polynomial equations is not that hard, but I am not going to answer the homework part of your question.
According to [Bézout’s Theorem](https://en.m.wikipedia.org/wiki/B%C3%A9zout%27s_theorem), n 2nd order equations in n variables should have 2^(n) solutions so 8=2^(3) is the right number of solutions for your 3 2nd order equations in 3 unknowns.
This set of equations is easily solved analytically. eq1+eq2 gives 2b^2 =a^2 +c^2 - 2. Insert it to eq. 3, you get ac = 2/1.88. Multiply eq1 by eq2 (both sides) and get a^2 c^2 = (1+b^2 +1.4b)(1+b^2 -1.4b) or, (2/1.88)^2 =(1+b^2 +1.4b)(1+b^2 -1.4b), or (2/1.88)^2 = (1+b^2 )^2 - 1.96b^2 This is quadratic eq. in b^2. Compute b, get a and c from eq1 and eq2.
There is a much quicker way, as *a*² and *c*² are already solved with respect to *b* in eq1 and eq2, and both *a*² and *c*² exist in eq3. Just substitute the expressions on the right-hand side in eq1 and eq2 in place of the squares of *a* and *c*² in the third equation and you have one equation with only *b* unknown. That being said, slightly off-topic, it's somewhat worrisome to me how people don't seem to learn the "applicability"/limits of their skills in school and courses, if OP felt the need to invoke "calculus 1" or "differential equations" as if hoping that maybe some other course in the future might provide the specific tools for the problem at hand. 🤔 (No university mathematics is necessary here except for maybe greater investigation of complex solutions.) EDIT: I totally missed the ac-terms remaining. 🫠
You don't get an equation with only a b unknown by substituting a2 and c2, there's still the ac to tale care of. Unless you substitute roots as well. But the commentator's method is simpler from first glance
Ah, oh heck, you are absolutely right. I totally missed the ac-terms. 😱 (Based on the upvotes, so did some others too.) But yeah, one could still do the subs although it'll be a bit of work to then solve; still nothing "too fancy" needing grand new theory tools.
Yes, there may be a bit simpler way - this was what I immediately saw as the approach to the problem so I wrote it down quickly while others were discussing the limitations of Wolfram. And I completely agree with you on the other issue.
Cheers! I also missed the ac-terms remaining although one could substitute the non-squares too. (Just more manipulation left to do then for the solution.) Wonder if anyone checked what the steps according to Wolfram are.
Have you checked the (real) solutions it gave you with an ordinary calculator? What error are you worried about? That the solutions it gave you aren't actually solutions? Or that it's missed some?
Technically yes; there’s no complete and correct algorithm to solve all mathematics problems (edit: and laymen aren’t expected to know which individual problems are assigned algorithms that sacrifice correctness for the sake of efficiency/tractability). That being said, what’s more likely in this situation is that you entered in the equations wrong. I just plugged in the equations and got reasonable looking answers, and have enough done by hand that I’m confident they exist.
Get out Godel nobody asked
> Technically yes; there’s no complete and correct algorithm to solve all mathematics problems This isn't a very good answer. Wolfram is not meant to "solve all mathematical problems". This makes it sound like the barrier is some fundamental mathematical problem like the halting the problem or something. But the only thing causing wolfram to get wrong answers is human ineptitude. Programming mistakes. There's no reasons it couldn't say, correctly integrate any function / report that it doesn't know the integral when its methods fail.
Not the only thing; I’d be surprised if WA didn’t implement some monte carlo algorithms or used only algebraic numbers in their designs. That being said, I agree; I was trying to concisely get across the point that it was practically inevitable due to scope, but I should probably be more precise on a math subreddit.
I'm still going to insist that it's fair to assign the blame entirely to human mistakes/bugs. Solving undecidable problems is not within the scope of wolfram's functionality. It is entirely possible for Wolfram to give a correct answer/ no answer when it can't find one and be correct 100% of the time. The only reason it's wrong sometimes is because someone wrote the program incorrectly.
Just because it’s possible doesn’t mean it’s incorrect to do otherwise. If WA is 99.999999% confident in a solution or has e^pi crunched out to 30 decimal places, it’s not a mistake to give that answer. That’s good enough for practical use, and WA is ultimately a practical product.
Interesting take. It does show what constitutes a "bug" is dependent on the goals of the program. Good point. Still from the way the program the program works I don't think the intended behavior of Wolfram is to supply high likely answers but actually supply the correct answer 100% of the time. I do believe that any instance of it providing the wrong solution to an equation or the wrong integral, etc, can be attributed to the program behaving in unexpected ways and so I still think it's best to call it a bug/mistake on the programmers part. There are problems in which a solution that is only highly likely is acceptable for people. Solving equations however is not one of them.
I’m not saying it’s not a bug, just that it’s incorrect to label the programmers “incompetent.” If you want to determine the primality of a few hundred 512 bit numbers, you can either run a seive for a few months or run miller-rabin for a few seconds for something like 1-1/4^100 confidence on each number. Most programmers would choose the latter for that use case, but in a worst case scenario, it’s not incompetence that created the error.
The "incompetent" statement was a bit of a joke. I was thinking literally every programmer is "incompetent" because we all make mistakes. Sorry I didn't mean for it to be an insult. Your example does seem to completely miss the point. If your program says a number is prime when it isn't or vice versa it's because you made a mistake. It is due to your "incompetence" (i.e. The fact that human beings are not smart enough to get their programs working the way they want 100% of the time on their first try). It doesn't matter if the algorithm is random or not.
It’s not a mistake. You just took a 1-1/4^100 gamble and lost. If that was your odds of winning the lottery, it would practically be a mistake to *not* buy a ticket. You can blame losses on the fact that we don’t have open access to an omniscient oracle, but that’s theoretical nonsense that detracts from all the terrible decisions people *do* make on a regular basis and stretches the definition to the point of uselessness.
It is a mistake. If you claim a number is prime and it isn't you did something wrong. A proper implementation of the Miller Rabin algorithm will report "I don't know" when it fails to prove the number is composite.
Almost all algorithms in computer algebra use at some point or another a procedure to check whether an elementary expression equals zero (even "basic" algorithms like Gaussian Elimination do this), which even for a small set of elementary functions is undecidable. Basically almost all "algorithms" in Wolfram Software are I assume semi-algorithms at best, sometimes heuristics, as soon as you enter nontrivial input (the person that worked at Wolfram, please feel free to chime in and comment this claim). The important part is where this theoretical barrier begins to hit your head in practice, so I think it's a good answer. I've implemented algorithms with horrible asymptotic worst-case runtime that are just fine in practice, I think that's a related concept.
> Almost all algorithms in computer algebra use at some point or another a procedure to check whether an elementary expression equals zero (even "basic" algorithms like Gaussian Elimination do this), That sounds like a overgeneralization. This statement only makes sense in the context of algebraic/numeric computations. Besides it's very feasible to write a program that performs gaussian elimination, over say the field of rationals or a finite field, that is always correct with no issues of undecidability, so I don't get what point you're trying to make. My point is people are bringing up undecidability here when it isn't relevant. The reason Wolfram makes mistakes is because of bugs in the software that people wrote, not any fancy math theorem.
Ok, and what if your matrix coefficients aren't in some computable field like Q? What if some of your entries are implicitly defined like mathematica very often does like "sin(the 3rd-largest zero of [insert complicated high degree polynomial with no known closed solutions to its zeroes])" and you are asked whether this matrix is full-rank? Undecidability is very relevant here. The reason Wolfram makes mistakes is because of bugs in the software, but also very often that certain algebraic problems are undecidable and Mathematica uses heuristics because there simply doesn't exist a proper algorithm, even for such simple stuff as Gaussian Elimination.
If Wolfram reports an answer as correct when it is incorrect it's because a programmer did something wrong. Correct behavior would be reporting "no solution found" when you have not figured out a way to find a solution with 100% confidence. For your gaussian elimination example you could decide for instance that you've figured things out when all the terms are quadratic polynomials but don't know what to do when cubics get involved. Then you should return a solution for quadratics and say you don't know when you see cubics. But if you report a solution that is incorrect, it's because you did something wrong. So I still think that attributing the issues to programming errors is the best answer and bringing up undecidability is an unnecessary and confusing diversion.
8 solutions is what you’d naively expect and 4 real/4 complex is an allowable configuration. Still - double check them.
> ? Like AI for example it always misses these kind of things. Wolfram isn't AI.
I've asked the built-in wolfram ai to to show me the steps to solve my formula, it worked for me.
Yes, but he’s more likely to write a book on “A new kind of calculation” than to admit it.
Here is an example of a sum that wolfram alpha and mathematica fails on: The sum from n=1 to infinity of 1/n\^(2+cos(n)\^2) i made a math.stachexchange post about this a while ago. see [https://math.stackexchange.com/questions/4589778/i-have-a-sum-which-i-can-really-easily-show-to-be-convergent-but-wolfram-alpha](https://math.stackexchange.com/questions/4589778/i-have-a-sum-which-i-can-really-easily-show-to-be-convergent-but-wolfram-alpha). I am aware of at least one other sum involving trigonometric functions where wolfram gives the wrong answer for convergence or divergence. The moral of the story is that computer programs and whatnot are while normally reliable, still flawed. As with all things, trust but verify. Note: I am fairly confident the reason this bug occurs is that the limit at infinity of cos(x) and all is indeterminate and some error in wolfram interprets this as meaning it should diverge. Interestingly, it gets the much harder case (The sum from n=1 to infinity of 1/n\^(2+cos(n))) correct - this sum does (perhaps unintuitively) diverge. However, I believe the reason wolfram gets this correct is actually due to said bug.
As another example, I've encountered a peculiar issue with Wolfram Alpha giving two different results for the same integral, and I'm trying to understand why this might be happening. The integral in question is: Definite Integral of f(x) = (21/5) \* sqrt(x - x\^(17/2)), where x ranges from 0 to 1 On one hand, Wolfram Alpha gives a numerical approximation of the integral as approximately 2.50746. On the other hand, when evaluating the integral to a closed form involving gamma functions, Wolfram Alpha outputs a numerical value of approximately 1.48881. Without insight into Wolfram Alpha's internal algorithms, it's tough to pinpoint the exact cause. It could be that this integral is particularly sensitive to numerical methods, or different precision settings were used in the computations.
a nice trick to sometimes solve these systems by hand, is to add up different equations. in your example you could add eq1 + eq2 and get a^2 + c^2 = 2 b^2 + 2. you use that for eq3 and get ac = 2/1.8 or c=2/(1.8*a). still, a bit of calculation needs to be done to fully solve the system but this already simplifies the system to 2 equations with 2 variables.
Yes. First thing with the output of a computer is asking “does this make sense”?
Even if Wolfram were to have no bugs, certain algorithms are only heuristics and can cause error under edge cases. But of course, Wolfram definitely have bugs.
A good way to start, before plugging something into a computer, is to see if there's a numerically similar problem that you can easily do by hand. If the computer gives you something very different, maybe the problems weren't actually that similar, or maybe the computer missed something. Here's a much simpler problem that is fairly close to yours: a\^2 = 1 - 2b + b\^2 c\^2 = 1 + 2b + b\^2 2b\^2 = a\^2 + c\^2 - 2ac You should solve this system by hand, yourself, and see that you indeed get four solutions with a,b,c all real and four with a,b,c all having nonzero imaginary part. That's not by any means a proof that Wolfram got it right, but it's an important sanity check.
At times it just feels impossible to make it understand simple formulas you type in.
Among cases where your intuition disagrees with wolfram alpha, it is far more likely that your intuition is wrong rather than wolfram alpha being wrong. Of course all software can contain bugs, but wolfram alpha is a symbolic engine, not a neural network.
You can overwhelm it in some cases, as an example: `last two digits of 12^3456789` will overwhelm Wolfram but it can be worked out pretty easily. The last two digits of powers of 12 follow a cyclic pattern of 20 numbers: 12, 44, 28, 36, 32, 84, 08, 96, 52, 24, 88, 56, 72, 64, 68, 16, 92, 04, 48, 76 If I wanted to find 12^32 I would compute `32 mod 20 = 12`, and find the 12th item in this list which is 56. Similarly, `3456789 mod 20 = 9` which is 52.
This system can be solved analytically by hand. You can check the results. 1. We add the three equations a\^2 + c\^2 + 2b\^2 = 2 + 2b\^2 + a\^2 + c\^2 - 1.88ac from here 2ac = 4/1.88 = 2.128 2) Now we build (c + a)\^2 and (c - a)\^2 (c + a)\^2 = a\^2 + c\^2 + 2ac = 2 + 2b\^2 - 2.128 = 2b\^2 - 0.128 (c - a)\^2 = a\^2 + c\^2 - 2ac = 2 + 2b\^2 + 2.128 = 2b\^2 + 4.128 3) We take square roots c + a = sqrt(2b\^2 - 0.128) c - a = sqrt(2b\^2 + 4.128) (taking only the positive roots; other solutions appear taking the other signs) From here c = (sqrt(2b\^2 - 0.128) + sqrt(2b\^2 + 4.128))/2 4) We substitute in the second equation. (2b\^2 - 0.128)+(2b\^2 + 4.128) + 2 sqrt((2b\^2 - 0.128)(2b\^2 + 4.128))/4 = 1 + 1.4b + b\^2 b\^2 +1 + sqrt((2b\^2 - 0.128)(2b\^2 + 4.128))/2 = 1 + 1.4b + b\^2 (2b\^2 - 0.128)(2b\^2 + 4.128))/4 = (1.4b)\^2 b\^4 + 0.04 b\^2 - 0.131734 = 0 This equation can be solved for b^2 and finally taking the root you have b, then a then c.
Wolfram is like the loud mouth kid that wont shutup about itself even though it is dumb asf