#include <math.h>

[Randy Howard]

Re: #include &lt;math.h&g t;

In article <ajcasvop6uf4gg uj4caago2gafgb2 sq6uc@4ax.com>,
markmcintyre@sp amcop.net says...[color=blue]
> On Wed, 26 Nov 2003 13:27:04 -0600, in comp.lang.c , Randy Howard
> <randy.howard@F OOmegapathdslBA R.net> wrote:[color=green]
> >
> >Is there an ANSI standard on Make and makefiles? Or, are we free to
> >assume that GNU make is the "one true make" and proceed thusly?[/color]
>
> Its a great assumption. It will work perfectly.
>
> Right up to the point at which you port your makefile to some other
> compiler environment. Heck, ISTR that makefiles from the C compiler
> shipped with SunOS 4.1.3 didn't work with the Sparc C++ compiler.[/color]

Seems that would be easy enough to solve. Open Source, shouldn't
be hard to port to just about any modern platform that can support
a make of its own.

--
Randy Howard _o
2reply remove FOOBAR \<,
_______________ _______()/ ()_____________ _______________ _______________ ___
SCO Spam-magnet: postmaster@sco. com

[gswork]

Re: #include &lt;math.h&g t;

Kelsey Bjarnason <kelseyb@lights peed.bc.ca> wrote in message news:<pan.2003. 11.25.02.05.07. 387424@lightspe ed.bc.ca>...[color=blue]
> On Mon, 24 Nov 2003 16:52:07 -0800, Darius Fatakia wrote:
>[color=green]
> > Hi,
> >
> > I seem to be having trouble with some of my math functions (pow, sqrt,
> > acos). They're the only ones I use in my code and they prevent the program
> > from compiling. I get a "undefined reference to 'pow'" error. Here is the
> > relevant portion of my code.[/color]
>
> Sounds like a linker error - are you linking the math libraries? There's
> a certain, popular compiler, especially widely used in the Linux world,
> which has the terminally brain-dead habit of not including the math
> libraries by default. Assuming you're using this compiler, try something
> like this:
>
> gcc -lm file.c[/color]

Out of interest and for the benefit of the OP, does the standard have
anything to say about linkage?

[Irrwahn Grausewitz]

Re: #include &lt;math.h&g t;

gswork@mailcity .com (gswork) wrote:
[color=blue]
> Kelsey Bjarnason <kelseyb@lights peed.bc.ca> wrote in message news:<pan.2003. 11.25.02.05.07. 387424@lightspe ed.bc.ca>...[color=green]
> > On Mon, 24 Nov 2003 16:52:07 -0800, Darius Fatakia wrote:
> >[color=darkred]
> > > I seem to be having trouble with some of my math functions (pow, sqrt,
> > > acos). They're the only ones I use in my code and they prevent the program
> > > from compiling. I get a "undefined reference to 'pow'" error. Here is the
> > > relevant portion of my code.[/color]
> >
> > Sounds like a linker error - are you linking the math libraries? There's
> > a certain, popular compiler, especially widely used in the Linux world,
> > which has the terminally brain-dead habit of not including the math
> > libraries by default. Assuming you're using this compiler, try something
> > like this:
> >
> > gcc -lm file.c[/color]
>
> Out of interest and for the benefit of the OP, does the standard have
> anything to say about linkage?[/color]

About /linking/ refer to ISO/IEC 9899:1999 5.1.1.2#8.

About /linkage/ refer to 6.2.2., 6.7, 6.7.4, 6.7.5.2, 6.9,
6.9.2, 6.11.2, ...

HTH
Regards
--
Irrwahn
(irrwahn33@free net.de)

[Dan Pop]

Re: #include &lt;math.h&g t;

In <MPG.1a2eba82cb ebd18f98995d@ne ws.megapathdsl. net> Randy Howard <randy.howard@F OOmegapathdslBA R.net> writes:
[color=blue]
>In article <bq24e6$lbl$14@ sunnews.cern.ch >, Dan.Pop@cern.ch says...[color=green]
>> In <3FC3EE89.18@ea rthlink.net> Joe Wright <joewwright@ear thlink.net> writes:
>>[color=darkred]
>> >out of me too. Reading the info file on make one day (I'm surprised how
>> >little I do this and how much I should) I read that ';' semicolon is
>> >also a Rule / Command separator.[/color]
>>
>> But is this a make feature or a GNU make feature?
>>
>> Dan
>>[/color]
>
>Is there an ANSI standard on Make and makefiles? Or, are we free to
>assume that GNU make is the "one true make" and proceed thusly?[/color]

Why does it have to be an ANSI standard? C99 is an ANSI standard, yet
C99 code is extremely non-portable, due to lack of implementations .

According to the HP-UX man page:

STANDARDS CONFORMANCE
make: SVID2, SVID3, XPG2, XPG3, XPG4, POSIX.2

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Dan Pop]

Re: #include &lt;math.h&g t;

In <MPG.1a2f303f4f 298a2e989960@ne ws.megapathdsl. net> Randy Howard <randy.howard@F OOmegapathdslBA R.net> writes:
[color=blue]
>In article <ajcasvop6uf4gg uj4caago2gafgb2 sq6uc@4ax.com>,
>markmcintyre@s pamcop.net says...[color=green]
>> On Wed, 26 Nov 2003 13:27:04 -0600, in comp.lang.c , Randy Howard
>> <randy.howard@F OOmegapathdslBA R.net> wrote:[color=darkred]
>> >
>> >Is there an ANSI standard on Make and makefiles? Or, are we free to
>> >assume that GNU make is the "one true make" and proceed thusly?[/color]
>>
>> Its a great assumption. It will work perfectly.
>>
>> Right up to the point at which you port your makefile to some other
>> compiler environment. Heck, ISTR that makefiles from the C compiler
>> shipped with SunOS 4.1.3 didn't work with the Sparc C++ compiler.[/color]
>
>Seems that would be easy enough to solve. Open Source, shouldn't
>be hard to port to just about any modern platform that can support
>a make of its own.[/color]

"Shouldn't be hard to port" and "isn't hard to port" are two completely
different things.

Between merely having to compile and install gnu make and writing portable
makefiles I'll choose the latter without a second's hesitation. I had
no problem using well written Unix makefiles with Microsoft's NMAKE when
I had to port the project to Windows + the VC++ toolchain.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Dan Pop]

Re: #include &lt;math.h&g t;

In <81f33a98.03112 70205.31bf14a4@ posting.google. com> gswork@mailcity .com (gswork) writes:
[color=blue]
>Out of interest and for the benefit of the OP, does the standard have
>anything to say about linkage?[/color]

Quite a lot. But it is quite quiet about linking.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Les Cargill]

Re: #include &lt;math.h&g t;

Joe Wright wrote:[color=blue]
>
> Dan Pop wrote:[color=green]
> >
> > In <3FC3EE89.18@ea rthlink.net> Joe Wright <joewwright@ear thlink.net> writes:
> >[color=darkred]
> > >out of me too. Reading the info file on make one day (I'm surprised how
> > >little I do this and how much I should) I read that ';' semicolon is
> > >also a Rule / Command separator.[/color]
> >
> > But is this a make feature or a GNU make feature?
> >[/color]
> Certainly GNU make because I read it there and tried it and it worked. I
> cannot know and don't care much about all other make programs. By the
> same token I don't know that TAB is the separator other make programs.
> To the extent that TAB was chosen by make's original author (Who?)[/color]

Richard Stallman.
[color=blue]
> it
> seems arbitrary and badly chosen.[/color]

It's a way. Python seems to have reinvented this "error".
[color=blue]
> --
> Joe Wright http://www.jw-wright.com
> "Everything should be made as simple as possible, but not simpler."
> --- Albert Einstein ---[/color]


--
Les Cargill

[Jeremy Yallop]

Re: #include &lt;math.h&g t;

Les Cargill wrote:[color=blue]
> Joe Wright wrote:[color=green]
>> By the same token I don't know that TAB is the separator other make
>> programs. To the extent that TAB was chosen by make's original
>> author (Who?) it seems arbitrary and badly chosen.[/color]
>
> It's a way. Python seems to have reinvented this "error".[/color]

Python accepts both tabs and spaces as indentation. There's no need
to use tabs if you don't want to.

Jeremy.

[Les Cargill]

Re: #include &lt;math.h&g t;

Jeremy Yallop wrote:[color=blue]
>
> Les Cargill wrote:[color=green]
> > Joe Wright wrote:[color=darkred]
> >> By the same token I don't know that TAB is the separator other make
> >> programs. To the extent that TAB was chosen by make's original
> >> author (Who?) it seems arbitrary and badly chosen.[/color]
> >
> > It's a way. Python seems to have reinvented this "error".[/color]
>
> Python accepts both tabs and spaces as indentation. There's no need
> to use tabs if you don't want to.[/color]

Right! I meant it's still indentation-based, which is odd in this
day and age.
[color=blue]
>
> Jeremy.[/color]


--
Les Cargill

[August Derleth]

Re: #include &lt;math.h&g t;

Les Cargill <lcargill@world net.att.net> wrote in message news:<3FC6554F. 615F5BA3@worldn et.att.net>...[color=blue]
> Jeremy Yallop wrote:[color=green]
> >
> > Les Cargill wrote:[color=darkred]
> > > Joe Wright wrote:
> > >> By the same token I don't know that TAB is the separator other make
> > >> programs. To the extent that TAB was chosen by make's original
> > >> author (Who?) it seems arbitrary and badly chosen.
> > >
> > > It's a way. Python seems to have reinvented this "error".[/color]
> >
> > Python accepts both tabs and spaces as indentation. There's no need
> > to use tabs if you don't want to.[/color]
>
> Right! I meant it's still indentation-based, which is odd in this
> day and age.[/color]

But Python's indentation rules follow the informal format of all other
Algol-based languages. What you are forced to do in Python is merely
what you should be doing in C and Pascal and such anyway.

If you absolutely despise whitespace, one space character works just
fine. There's no concept of sacred columns that Fortran and other
punch-card-based languages plagued us all with Back In The Day.

A small example:

def my_abs(x):
if x <= 0:
return x
else:
return -x

There. Done. That's as obnoxious as the rules get. Emacs even does it
for you (the newline key is electric in Python mode, so Emacs will
auto-indent whenever you end a line).

[gswork]

Re: #include &lt;math.h&g t;

Irrwahn Grausewitz <irrwahn33@free net.de> wrote in message news:<rtqbsvo3k 4tlfo3gmek81d8l o3mqli59v0@4ax. com>...[color=blue]
> gswork@mailcity .com (gswork) wrote:
>[color=green]
> > Kelsey Bjarnason <kelseyb@lights peed.bc.ca> wrote in message news:<pan.2003. 11.25.02.05.07. 387424@lightspe ed.bc.ca>...[color=darkred]
> > > On Mon, 24 Nov 2003 16:52:07 -0800, Darius Fatakia wrote:
> > >
> > > > I seem to be having trouble with some of my math functions (pow, sqrt,
> > > > acos). They're the only ones I use in my code and they prevent the program
> > > > from compiling. I get a "undefined reference to 'pow'" error. Here is the
> > > > relevant portion of my code.
> > >
> > > Sounds like a linker error - are you linking the math libraries? There's
> > > a certain, popular compiler, especially widely used in the Linux world,
> > > which has the terminally brain-dead habit of not including the math
> > > libraries by default. Assuming you're using this compiler, try something
> > > like this:
> > >
> > > gcc -lm file.c[/color]
> >
> > Out of interest and for the benefit of the OP, does the standard have
> > anything to say about linkage?[/color]
>
> About /linking/ refer to ISO/IEC 9899:1999 5.1.1.2#8.
>
> About /linkage/ refer to 6.2.2., 6.7, 6.7.4, 6.7.5.2, 6.9,
> 6.9.2, 6.11.2, ...
>
> HTH
> Regards[/color]

Thanks for the references

[Richard Bos]

Re: #include &lt;math.h&g t;

libertarian2320 03@yahoo.com (August Derleth) wrote:
[color=blue]
> Les Cargill <lcargill@world net.att.net> wrote in message news:<3FC6554F. 615F5BA3@worldn et.att.net>...[color=green]
> > Jeremy Yallop wrote:
> >[color=darkred]
> > > Python accepts both tabs and spaces as indentation. There's no need
> > > to use tabs if you don't want to.[/color]
> >
> > Right! I meant it's still indentation-based, which is odd in this
> > day and age.[/color]
>
> But Python's indentation rules follow the informal format of all other
> Algol-based languages. What you are forced to do in Python is merely
> what you should be doing in C and Pascal and such anyway.[/color]

No, it isn't.

I'm not sure if Python's equivalent of this is legal...

int function(struct object * const first_source,
struct object * const second_source,
struct object * destination)
{
/* Do something */
}

....but Python's equivalent of this certainly isn't...

if (first_object ->wibble_count er > maximum_wibbles ||
second_object->wibble_count er > maximum_wibbles )
return -1;

....and if a language doesn't allow me to make my code more readable by
being creative with indentation like that, it goes into the bin for
being too uppity for its own good.

One of the reasons why I like C is that, if _I_ decide something is more
legible the way I like it, the language doesn't stop me from maintaining
my code in a year or two.

Richard

[Jeremy Yallop]

Re: #include &lt;math.h&g t;

Richard Bos wrote:[color=blue]
> I'm not sure if Python's equivalent of this is legal...
>
> int function(struct object * const first_source,
> struct object * const second_source,
> struct object * destination)
> {
> /* Do something */
> }[/color]

You can certainly write something equivalent to that in Python, since
most objects are mutable, and calling a function passes references to
arguments by value. By this I mean that when you pass an argument to
a function the object (e.g. the "struct") is bound to the parameter
name within the function body. Consequently, the object is available
for modification within the function, but if the parameter name
appears on the left side of an assignment expression then the name is
simply rebound and the object is not modified. It's rather similar to
what you have above: the effects of assignments to destination->foo
are visible outside the function, but assignments to destination
itself are not.

class Foo:
def __init__(self, val):
self.value = val

# set the value of `output' to the sum of the values of
# `first_source' and `second_source' . Return half of the final
# value of `output'
def function(first_ source, second_source, output):
# modify the object to which `output' is bound.
output.value = first_source.va lue + second_source.v alue
return output.value / 2

# Probably not what was intended
def function_2(firs t_source, second_source, output):
# rebind output within `function_2'. No effect once the
# function returns
output = first_source, second_source

[color=blue]
> ...but Python's equivalent of this certainly isn't...
>
> if (first_object ->wibble_count er > maximum_wibbles ||
> second_object->wibble_count er > maximum_wibbles )
> return -1;[/color]

This is written

if (first_object .wibble_counter > maximum_wibbles or
second_object.w ibble_counter > maximum_wibbles ):
return -1

Jeremy.

[Les Cargill]

Re: #include &lt;math.h&g t;

August Derleth wrote:[color=blue]
>
> Les Cargill <lcargill@world net.att.net> wrote in message news:<3FC6554F. 615F5BA3@worldn et.att.net>...[color=green]
> > Jeremy Yallop wrote:[color=darkred]
> > >
> > > Les Cargill wrote:
> > > > Joe Wright wrote:
> > > >> By the same token I don't know that TAB is the separator other make
> > > >> programs. To the extent that TAB was chosen by make's original
> > > >> author (Who?) it seems arbitrary and badly chosen.
> > > >
> > > > It's a way. Python seems to have reinvented this "error".
> > >
> > > Python accepts both tabs and spaces as indentation. There's no need
> > > to use tabs if you don't want to.[/color]
> >
> > Right! I meant it's still indentation-based, which is odd in this
> > day and age.[/color]
>
> But Python's indentation rules follow the informal format of all other
> Algol-based languages. What you are forced to do in Python is merely
> what you should be doing in C and Pascal and such anyway.
>[/color]

That doesn't matter. It's like designing a TV video section that
can only support PAL and not NTSC - it's an unnecessary constraint.

In this day and age of language design tools, it's unnecessary. Any
resonance with card image formatting is archaic.
[color=blue]
> If you absolutely despise whitespace,[/color]

I don't, and that is not the point at all.

Curly braces are cheap, explicit and very visible. They make fine
delimiters.
[color=blue]
> one space character works just
> fine. There's no concept of sacred columns that Fortran and other
> punch-card-based languages plagued us all with Back In The Day.
>
> A small example:
>
> def my_abs(x):
> if x <= 0:
> return x
> else:
> return -x
>
> There. Done. That's as obnoxious as the rules get.[/color]

It's not that onerous, but the fine details add up.
[color=blue]
> Emacs even does it
> for you (the newline key is electric in Python mode, so Emacs will
> auto-indent whenever you end a line).[/color]


--
Les Cargill

[Richard Bos]

Re: #include &lt;math.h&g t;

Jeremy Yallop <jeremy@jdyallo p.freeserve.co. uk> wrote:
[color=blue]
> Richard Bos wrote:[color=green]
> > I'm not sure if Python's equivalent of this is legal...
> >
> > int function(struct object * const first_source,
> > struct object * const second_source,
> > struct object * destination)
> > {
> > /* Do something */
> > }[/color]
>
> You can certainly write something equivalent to that in Python, since
> most objects are mutable, and calling a function passes references to
> arguments by value.[/color]

I wasn't talking about the semantics, merely about the indentation.
[color=blue][color=green]
> > ...but Python's equivalent of this certainly isn't...
> >
> > if (first_object ->wibble_count er > maximum_wibbles ||
> > second_object->wibble_count er > maximum_wibbles )
> > return -1;[/color]
>
> This is written
>
> if (first_object .wibble_counter > maximum_wibbles or
> second_object.w ibble_counter > maximum_wibbles ):
> return -1[/color]

Like bloody hell it is. That is _not_ as legible. In fact, it isn't even
in the same ballpark. And that's even without considering three levels
of indentation.

Richard