Program Flawless, calculation wrong.

[The Brahmnic Boy]

My program to find the roots of a quadratic equation is errorless, but when i compare it with online calculators, the answer is wrong.

The variable "d" in line 19 is the discriminant. When it is less than 1, roots are imaginary as expected.
But for 8x^2 + 9x + 1 = 0,
My program gives me -8 and -64, but the roots are -0.125 and -1.
Is the order of operations wrong?
Also, I am 15, developing country, Beginner. Tell me if some lines of code are unneeded.

#include<stdio.h>
#include<iostream>
#include<conio.h>
#include<math.h>
using namespace std;

int main ()
{
	double x,y,a,b,c,d;
	cout<<"Arrange your quadratic equation in the form of {ax^2 + bx + c = 0}"<<endl<<"(On paper.)";
	cout<<endl<<"Enter values of a, b and c. Press enter after entering each value."<<endl;
	cout<<"a=";
	cin>>a;
	cout<<endl<<"b=";
	cin>>b;
	cout<<endl<<"c=";
	cin>>c;
	
	d=((b*b)- 4*a*c);
	if(d>=0)
	{
		x=((-b)+sqrt(d))/2*a;
		y=((-b)-sqrt(d))/2*a;
		cout<<endl<<"The roots of the quadratic equation are:   "<<x<<"   and    "<<y<<".";
	}
	else
	cout<<endl<<"The roots are imaginary!";
	getch();

[tpb]

You have flawlessly forgotten the parentheses around (2 * a):

        x = (-b + sqrt(d)) / (2 * a);
        y = (-b - sqrt(d)) / (2 * a);

[The Brahmnic Boy]

Right now it is midnight, (even though developers are owls, I am not yet one.)

I may check that tomorrow, but...
Why does it make a difference?
What does the compiler interpret if the parentheses is not present?

Also, thank you for you kind, sarcastic, but helpful reply.

[lastchance]

@tpb wasn't being sarcastic, he was merely citing your over-optimistic thread title back to you.

It makes a difference here because / and * have equal precedence, both in C++ and in most computer languages, so would simply be evaluated left to right.

Thus, the main bracketed term would be evaluated first.
Then, without further brackets, this would be divided by 2...
and, finally, the whole would be multiplied by a, wrongly putting a in the numerator rather than denominator.

Several lines of your code are unneeded. Remove <stdio.h>. Remove conio.h and getch(), which are non-standard. The modern header is <cmath>, not math.h.

Check your code once posted: you have omitted the final brace }.

[tpb]

I wasn't being sarcastic, not really. I just thought your title was kind of funny. But believe me, I've been there, staring at a little piece of code and just not seeing anything wrong with it, and yet it's gives the wrong answer!

It's frustrating but at the same time it's a big part of programming. Again and again you end up inadvertently creating strange little puzzles for yourself. But if you've scrutinized every detail and absolutely can't see anything wrong, then it's almost always the case that you are making an incorrect assumption. In your case, you didn't see how the parens would make a difference, so you didn't even consider that fix.

A fresh pair of eyes is a powerful tool here since seeing through your assumptions is tricky. In order to do so you either need more data (print some intermediate values or run in a debugger) or you need to take a break so you can look at it again with possibly fresh insight.

[Ganado]

In general cases, when it's logic as opposed to a particular mathematical equation that's the problem, I would do what's called "rubber duck debugging". You talk to a rubber ducky and explain each line to it. Trying to explain how something works to someone or something else can help you see where the logic is wrong. (Doesn't need to be a literal duck, but you should say stuff out-loud if possible and if you're in an environment where you can do that.)

https://youtu.be/u9hauSrihYQ?t=318
"if you snuck up on me when I didn't think anyone was around, you would overhear me explaining the most mundane stuff. It's really weird, but for me, it is a great way for me to know that I kind of know more what I'm talking about if I can verbally explain it."

[The Brahmnic Boy]

Thanks everyone,

1. For teaching more about humanity and culture. Yes, I can get too optimistic at times.

2. For explaining good programming practices.

As I said before, I am taught in a developing country, and also they began with ''Turbo C++'',
even though we were introduced to Dev C++ in 6th grade. So libraries are gonna be wrong.
I also know that high school computer science won't get me anywhere.

I must go beyond syllabus to get an idea of how to do things better.

But again, since I live in an academically centered country, I can't venture too much out of syllabus.

My goal right now is to create an algebraic and geometric calculator (linear, quadratic, cubic, complex algebra, areas, volumes, etc.) using minimum lines of code.

The problem is, To become better at programming, I must be in DEV C++ or higher like Microsft visual.

But to clear exams I go back to Turbo C++

[Ganado]

using minimum lines of code.

Use the number of lines of code it takes to produce readable code that is still maintainable. Don't try to jam things all into one line just for the sake of lowering the line count.

For maintainability, the biggest factor for me hasn't been the number of lines of code, but duplicated logic not being updated in another part of the program after being updated in one part. The issue here is DRY -- Don't Repeat Yourself. (Note: I'm not talking about your post, I'm just talking about in general for projects.)