need to compile this ( trying to find roots of a bisection)

[anand]

************************************************** ************************************************** *******

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

void main()
{
double a,b,c,fa,fb,fc,err;
int count;
clrscr();
printf("\n enter value for %lf",a);
scanf("%lf",&a);
printf("\n enter value for %lf",b);
scanf("%lf",&b);
err = exp(-6);
printf("\n value of %lf",err);
while(fabs(a-b)<=err)
{
fa=2-(3*sin(a)*exp(a));
printf("\n the value of %lf",fa);
fb=2-(3*sin(b)*exp(b));
printf("\n the value of %lf",fb);
c=(a+b)/2;
fc=(fa+fb)/2;
If (fa!=0)
{
If ((fa>0)&&(fb>0))
a = c;
else
b = c;
}
Else
{
printf("\n the value of fa does not exist, proceed with fb");
}

If (fb != 0)
{
If (fb > 0)
If (fc > 0)
b = c;
else
a = c;
}
Else
{
printf ("\n fa,fb do not exist, cannot proceed");
}
count++
}
printf("\n the value of %lf",a);
printf("\n the value of %lf",b);
printf("\n the value of %d",count);
}

************************************************** ************************************************** ******

[Michael Mair]

anand schrieb:

************************************************** ************************************************** ******* Please state your problem in the message text, too.
BTW: "need to compile this ( trying to find roots of a bisection)"
is not very helpful.
#include<stdio.h>
#include<conio.h>
This is not a standard C header, so I will ignore it and
all functions which have no prototype in one of the other
included headers.
#include<math.h>

void main()
This is the wrong type for main().
Write either
int main (void)
or
int main (int argc, char **argv)
Read
http://c-faq.com/ansi/index.html
Question 11.12a through 11.15 {
double a,b,c,fa,fb,fc,err;
int count;
clrscr();
Unknown function.
printf("\n enter value for %lf",a);
In C89, using %lf in printf() leads to undefined behaviour.
http://c-faq.com/stdio/scanfvsprintf.html
Even if you used %f, %e, %g, you still are passing an
uninitialized variable as argument.
So you luck out in every possible way. Your program is already
dead.
scanf("%lf",&a);
Note: 1)If you want the preceding printf() to be printed out,
either terminate it by '\n' or use fflush(stdout) -- otherwise,
the output prompt might show up after the input it should
precede.
2) scanf() is not really good for interactive input.
Read the comp.lang.c FAQ on this:
http://c-faq.com/stdio/scanfhang.html
http://c-faq.com/stdio/scanfinterlace.html
printf("\n enter value for %lf",b);
scanf("%lf",&b);
dito.
err = exp(-6);
printf("\n value of %lf",err);
while(fabs(a-b)<=err)
{
fa=2-(3*sin(a)*exp(a));
printf("\n the value of %lf",fa);
fb=2-(3*sin(b)*exp(b));
printf("\n the value of %lf",fb);
c=(a+b)/2;
fc=(fa+fb)/2;
If (fa!=0)
Here you are not even trying anymore.
C is a case sensitive language, so you have to stay
with "if", "else", ... {
If ((fa>0)&&(fb>0))
a = c;
else
b = c;
}
Else
{
printf("\n the value of fa does not exist, proceed with fb");
}

If (fb != 0)
{
If (fb > 0)
If (fc > 0)
b = c;
else
a = c;
}
Else
{
printf ("\n fa,fb do not exist, cannot proceed");
}
count++
}
printf("\n the value of %lf",a);
printf("\n the value of %lf",b);
printf("\n the value of %d",count);
return 0; }

I did not look at the algorithm or at the loop contents.
Fix the above first and describe further problems.

Reading the whole comp.lang.c FAQ may help you avoid other
errors.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Martin Ambuhl]

anand wrote in the subject line "need to compile this ( trying to find
roots of a bisection)" followed by illiterate garbage claiming to be C
[mercifully snipped].

No, you need
1) To open your C text to page 1 and start over and
2) learn to not put an important part of your post in the headers, where
many people will ignore it.

[CBFalconer]

anand wrote:

************************************************** ************************************************** *******

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

void main()
{
double a,b,c,fa,fb,fc,err;
int count;
clrscr();

It won't compile. There is no such header file as conio.h. There
is no such routine as clrscr(). main returns an int, not void. I
did not look further.

At least in C. If you are using some other language with vague
similarities to C you need to use a newsgroup that deals with that
language. This is not it.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[osmium]

"anand" writes:

************************************************** ************************************************** *******

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

void main()
{
double a,b,c,fa,fb,fc,err;
int count;
clrscr();
printf("\n enter value for %lf",a);
scanf("%lf",&a);
printf("\n enter value for %lf",b);
scanf("%lf",&b);
err = exp(-6);
printf("\n value of %lf",err);
while(fabs(a-b)<=err)
{
fa=2-(3*sin(a)*exp(a));
printf("\n the value of %lf",fa);
fb=2-(3*sin(b)*exp(b));
printf("\n the value of %lf",fb);
c=(a+b)/2;
fc=(fa+fb)/2;
If (fa!=0)

Use cut and paste, not retype. There is no reason in the world to expect
that to compile. The magic word is "if", not "If". If you repost tell us
what happens. Did it compile? Don't imply something or other by saying
"Need to compile".

<snip>

[Keith Thompson]

CBFalconer <cb********@yahoo.com> writes:

anand wrote:

[...]

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

void main()
{
double a,b,c,fa,fb,fc,err;
int count;
clrscr();

It won't compile. There is no such header file as conio.h. There
is no such routine as clrscr(). main returns an int, not void. I
did not look further.

At least in C. If you are using some other language with vague
similarities to C you need to use a newsgroup that deals with that
language. This is not it.

As I'm sure you know, there is a header file called conio.h and a
function called clrscr() *on some systems*. (Of course, there's no
reason to use either in a program that just performs some mathematical
operations.)

Declaring "void main()" makes it incorrect C, not non-C.

The use of system-specific headers and functions makes the program
non-portable (and off-topic here); it doesn't make it non-C. One of
C's greatest assets is its ability to support system-specific
extensions.

What makes the program non-C is its use of "Else" and "If" rather than
"else" and "if".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ronaldão]

As far as I could see, you may be using borland C or similar compiler
for DOS or windows environments because of the conio.h header file.

Your code will not compile because of some "If" and "Else" statemens.
You can't use capital letters on them. About your main function, there
is nothing wrong with it. It can have one of the forms:

void main(void)
int main(void)
int main(int argc, char **argv)
int main(int argc, char *argv[])
and some extensions supports the form
int main(int argc, char **argv, char **envp)

Next time you post something here, try to be more explicit about the
problems you are going through.

[CBFalconer]

Ronaldão wrote:

As far as I could see, you may be using borland C or similar
compiler for DOS or windows environments because of the conio.h
header file.

Your code will not compile because of some "If" and "Else"
statemens. You can't use capital letters on them. About your main
function, there is nothing wrong with it. It can have one of the
forms:

void main(void)
No, this is not allowed. main always returns int.
int main(void)
int main(int argc, char **argv)
int main(int argc, char *argv[])
and some extensions supports the form
int main(int argc, char **argv, char **envp)
This is not specified in the C standard. Do not assume it. See
the standard routines getenv and putenv.

Next time you post something here, try to be more explicit about
the problems you are going through.

The next time you post here try to be more accurate in your
answers.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Jordan Abel]

On 2006-02-26, CBFalconer <cb********@yahoo.com> wrote:

Ronaldão wrote:

and some extensions supports the form
int main(int argc, char **argv, char **envp)

This is not specified in the C standard. Do not assume it. See
the standard routines getenv and putenv.

putenv is only _barely_ more standard [in that it's defined in _a_
standard] than envp, and isn't likely to be supported on any
implementations where envp is not. He _did_ say it was an extension.

[Micah Cowan]

Keith Thompson <ks***@mib.org> writes:

CBFalconer <cb********@yahoo.com> writes: Declaring "void main()" makes it incorrect C, not non-C.
Well, nowadays, it makes it non-portable C, not incorrect C. :-)

'course, depending on your definition for "incorrect C", the two may
overlap... :-)
What makes the program non-C is its use of "Else" and "If" rather than
"else" and "if".

I suspect the OP was used to MS Visual Basic or somesuch.

[Richard G. Riley]

On 2006-02-27, Micah Cowan <mi***@cowan.name> wrote:

Keith Thompson <ks***@mib.org> writes:

CBFalconer <cb********@yahoo.com> writes:

Declaring "void main()" makes it incorrect C, not non-C.

Well, nowadays, it makes it non-portable C, not incorrect C. :-)

'course, depending on your definition for "incorrect C", the two may
overlap... :-)

What makes the program non-C is its use of "Else" and "If" rather than
"else" and "if".

I suspect the OP was used to MS Visual Basic or somesuch.

It makes it non "standard" : and CBF was, as is his wont, pointing
that out.

The ANSI ISO 9899 standard says that main must be defined to return
type of int.

--
Remove evomer to reply

[Keith Thompson]

"Richard G. Riley" <rg****@gmail.com> writes:
[...]

The ANSI ISO 9899 standard says that main must be defined to return
type of int.

That's not exactly true. Grab a copy of n1124.pdf (which incorporates
the C99 standard plus TC1 and TC2) to see exactly what it says.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard G. Riley]

On 2006-02-27, Keith Thompson <ks***@mib.org> wrote:

"Richard G. Riley" <rg****@gmail.com> writes:
[...]

The ANSI ISO 9899 standard says that main must be defined to return
type of int.

That's not exactly true. Grab a copy of n1124.pdf (which incorporates
the C99 standard plus TC1 and TC2) to see exactly what it says.

I need practice reading standards.

Doesnt the "or in some other implementation-defined manner" make a
mockery of the first two? On first read I thought that referred to the
parameters to the function.
--
Remove evomer to reply

[Keith Thompson]

"Richard G. Riley" <rg****@gmail.com> writes:

On 2006-02-27, Keith Thompson <ks***@mib.org> wrote:

"Richard G. Riley" <rg****@gmail.com> writes:
[...]

The ANSI ISO 9899 standard says that main must be defined to return
type of int.

That's not exactly true. Grab a copy of n1124.pdf (which incorporates
the C99 standard plus TC1 and TC2) to see exactly what it says.

I need practice reading standards.

Doesnt the "or in some other implementation-defined manner" make a
mockery of the first two?

No, it doesn't. Look up the definition of "implementation-defined".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Micah Cowan]

Keith Thompson <ks***@mib.org> writes:

"Richard G. Riley" <rg****@gmail.com> writes:

On 2006-02-27, Keith Thompson <ks***@mib.org> wrote:

"Richard G. Riley" <rg****@gmail.com> writes:
[...]
The ANSI ISO 9899 standard says that main must be defined to return
type of int.

That's not exactly true. Grab a copy of n1124.pdf (which incorporates
the C99 standard plus TC1 and TC2) to see exactly what it says.

I need practice reading standards.

Doesnt the "or in some other implementation-defined manner" make a
mockery of the first two?

No, it doesn't. Look up the definition of "implementation-defined".

Actually, I'm somewhat inclined to agree with Mr Riley on this
point. It does kind of make a mockery of the first two. Or maybe it's
just a mockery of us.

For years on this group, we had been saying, "main() always returns an
int." Many of us still do this, but thanks to the '99 committee, it's
no longer strictly true.

Regardless, a void-returning main is still outside the scope of this
NG. It just changes the way we have to say that. :-/

[Keith Thompson]

Micah Cowan <mi***@cowan.name> writes:

Keith Thompson <ks***@mib.org> writes:

"Richard G. Riley" <rg****@gmail.com> writes:

> On 2006-02-27, Keith Thompson <ks***@mib.org> wrote:
>> "Richard G. Riley" <rg****@gmail.com> writes:
>> [...]
>>> The ANSI ISO 9899 standard says that main must be defined to return
>>> type of int.
>>
>> That's not exactly true. Grab a copy of n1124.pdf (which incorporates
>> the C99 standard plus TC1 and TC2) to see exactly what it says.
>
> I need practice reading standards.
>
> Doesnt the "or in some other implementation-defined manner" make a
> mockery of the first two?

No, it doesn't. Look up the definition of "implementation-defined".

Actually, I'm somewhat inclined to agree with Mr Riley on this
point. It does kind of make a mockery of the first two. Or maybe it's
just a mockery of us.

For years on this group, we had been saying, "main() always returns an
int." Many of us still do this, but thanks to the '99 committee, it's
no longer strictly true.

Regardless, a void-returning main is still outside the scope of this
NG. It just changes the way we have to say that. :-/

void main() continues to be invalid (invoking undefined behavior)
*unless* the implementation supports it as an extension. That means
it has to document it.

Whether that's a "mockery" depends on what you mean by "mockery". It
doesn't make the two well-defined forms of main() meaningless.

On the other hand, I would say that C99 4p6:

A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any strictly conforming program.

makes a mockery of the permission to define other forms of main(). Or
perhaps the "or in some other implementation-defined manner" is merely
intended for completeness, in an indirect acknowledgement of 4p6.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Micah Cowan]

Keith Thompson <ks***@mib.org> writes:

Micah Cowan <mi***@cowan.name> writes:

Keith Thompson <ks***@mib.org> writes:

"Richard G. Riley" <rg****@gmail.com> writes:
> On 2006-02-27, Keith Thompson <ks***@mib.org> wrote:
>> "Richard G. Riley" <rg****@gmail.com> writes:
>> [...]
>>> The ANSI ISO 9899 standard says that main must be defined to return
>>> type of int.
>>
>> That's not exactly true. Grab a copy of n1124.pdf (which incorporates
>> the C99 standard plus TC1 and TC2) to see exactly what it says.
>
> I need practice reading standards.
>
> Doesnt the "or in some other implementation-defined manner" make a
> mockery of the first two?

No, it doesn't. Look up the definition of "implementation-defined".
Actually, I'm somewhat inclined to agree with Mr Riley on this
point. It does kind of make a mockery of the first two. Or maybe it's
just a mockery of us.

For years on this group, we had been saying, "main() always returns an
int." Many of us still do this, but thanks to the '99 committee, it's
no longer strictly true.

Regardless, a void-returning main is still outside the scope of this
NG. It just changes the way we have to say that. :-/

void main() continues to be invalid (invoking undefined behavior)
*unless* the implementation supports it as an extension. That means
it has to document it.

Sure. That's what implementation-defined means.
Whether that's a "mockery" depends on what you mean by "mockery". It
doesn't make the two well-defined forms of main() meaningless.
Never meant to imply that it does.
On the other hand, I would say that C99 4p6:

A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any strictly conforming program.

makes a mockery of the permission to define other forms of main(). Or
perhaps the "or in some other implementation-defined manner" is merely
intended for completeness, in an indirect acknowledgement of 4p6.

I don't see how it makes a mockery of it. By definition, a strictly
conforming program could never use those other forms of main(), so 4p6
has no impact whatever upon them.

My understanding would be that 4p6 is designed to prohibit extensions
such as recognizing "new" as a keyword, or defining additional
functions whose names collide with functions such a program could
legally define.

[Keith Thompson]

Micah Cowan <mi***@cowan.name> writes:

Keith Thompson <ks***@mib.org> writes: [snip]

On the other hand, I would say that C99 4p6:

A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any strictly conforming program.

makes a mockery of the permission to define other forms of main(). Or
perhaps the "or in some other implementation-defined manner" is merely
intended for completeness, in an indirect acknowledgement of 4p6.

I don't see how it makes a mockery of it. By definition, a strictly
conforming program could never use those other forms of main(), so 4p6
has no impact whatever upon them.

Sure, but most programs aren't strictly conforming.
My understanding would be that 4p6 is designed to prohibit extensions
such as recognizing "new" as a keyword, or defining additional
functions whose names collide with functions such a program could
legally define.

Yes, that's part of what 4p6 does. It specifically *permits*
extensions (and places restrictions on what those extensions can look
like). In the absence of that permission, many extensions, even those
that don't affect strictly conforming programs, would arguably render
an implementation non-conforming.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ben Pfaff]

Micah Cowan <mi***@cowan.name> writes:

For years on this group, we had been saying, "main() always returns an
int." Many of us still do this, but thanks to the '99 committee, it's
no longer strictly true.

I just changed my wording to "int is the only portable return
type for main()."
--
"A lesson for us all: Even in trivia there are traps."
--Eric Sosman