Прога для решения квадратных уравнений

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

int main() {
setlocale(0,"");
double a, b, c, d, x1, x2, x, s;
cout << "Введите коэфициент a ";
cin >> a;
cout << "введите коэфициент b ";
cin >> b;
cout << "введите коэфициент c ";
cin >> c;
d = b * b - 4*a*c;
cout << " дискриминант =" << d;
s = d / d;
if (d < 0) {
    cout << " < 0, следовательно действительных корней нет!";
} else if (d = 0) {
    x = -b / (2*a);
    cout << " = 0, следовательно x1=x2="<< x; 
} else  {
/*23*/  x1 = (-b + s) / (2*a);
/*24*/  x2 = (-b - s) / (2*a);
    cout << " > 0, следовательно x1=" << x1 << ", x2=" << x2; 
}
return 0;
}

все вроде норм, но не могу понять, почему в строке 23 и 24 в скобках (-b + s) прога считает все, но не замечает этого самого «s» из за этого результат не верный

s = d / d;

смысл?

дискриминант по формуле под корнем

дискриминант по формуле под корнем

ага, делим его на себя же и получаем, что s равно 1 всегда

оу, я тупанул

а какой знак для вывода из под корня ставить тогда?

sqrt

спс:)

спс:)

пжлст:)

#include <stdio.h>
#include <math.h>

int main()
{
 int a,b,c;
 double  f,g,d,s;
scanf ("%d", &a);
scanf ("%d", &b);
scanf ("%d", &c);
d=pow(b,2)-4*a*c;
s=sqrt(d);
f=(-b+s)/(2*a);
g=(-b-s)/(2*a);
 if (f==g) { printf ("odin coren %f\n", f);}
 else {
printf ("%f\n",f);
printf ("%f\n",g);}
 if ( d<0) { printf ("cornei nety\n");}
return 0;

Вот моя прога и работает почти на 5

Вот моя прога и работает почти на 5

только вот %f — это float, а не double

только вот %f — это float, а не double

М-да? А как будет double?

%lf, но в printf'е и %f можно, там float до double расширяется, если мне память не изменяет

Я тебе ссылочку не зря дал. Для printf сочетания %lf вообще нет. А для scanf %lf — действительно для double.

Для printf сочетания %lf вообще нет.

Вот тут ты ошибаешься! Он есть, просто l в данном случае не оказывает влияния, если применяется к f, т.к. %f — это уже double

Вот тут ты ошибаешься!

М-да? Доказательства в студию!

Здесь написано, что %lf — для long double, которого вообще-то в VC++ нет )) Но это же MS!

А вот здесь написано, что для long double (там, где оно таки ж реализовано) должно использоваться %Lf.

М-да? Доказательства в студию!

пункт 7.21.6.1/7 стандарта

l (ell)
Specifies that a following d, i, o, u, x, or X conversion specifier applies to a long int or unsigned long int argument; that a following n conversion specifier applies to a pointer to a long int argument; that a following c conversion specifier applies to a wint_t argument; that a following s conversion specifier applies to a pointer to a wchar_t argument; or has no effect on a following a, A, e, E, f, F, g, or G conversion specifier.

ну и далее есть ответы на это:

написано, что %lf — для long double, которого вообще-то в VC++ нет )) Но это же MS!

А вот здесь написано, что для long double (там, где оно таки ж реализовано) должно использоваться %Lf.

long double — это %Lf, а не %lf

А вот что в стандарте написано:

L
Specifies that a following a, A, e, E, f, F, g, or G conversion specifierapplies to a long double argument.

ну и по поводу f:

f,F
A double argument representing a floating-point number is converted to decimal notation in the style [−]ddd.ddd, where the number of digits after the decimal-point character is equal to the precision specification. If the precision is missing, it is taken as 6; if the precision is zero and the # flag is not specified, no decimal-point character appears. If a decimal-point character appears, at least one digit appears before it. The value is rounded to the appropriate number of digits.
A double argument representing an infinity is converted in one of the styles [-]inf or [-]infinity — which style is implementation-defined. A double argument representing a NaN is converted in one of the styles [-]nan or [-]nan(n-char-sequence) — which style, and the meaning of any n-char-sequence, is implementation-defined.The F conversion specifier produces INF, INFINITY, or NAN instead of inf, infinity, or nan, respectively.277)

Компилятор от мелкософта — это самый гнилой компилятор по отношению к стандарту, так что приводить его в пример в 99% случаев не имеет смысла

or has no effect on a following a, A, e, E, f, F, g, or G conversion specifier.

Ну убедил. Против стандарта не попрешь.

А что я писал про MS... там должен был быть тэг <sarcasm> :)

Ну убедил. Против стандарта не попрешь.

Иногда там можно такую фигню вычитать, что в страшном сне не приснится )))