Re: math.nroot [was Re: A brief question.]

Tim Peters <tim.peters@xxxxxxxxx> writes:

> [Michael Hudson]
> > I doubt anyone else is reading this by now, so I've trimmed quotes
> > fairly ruthlessly :)
>
> Damn -- there goes my best hope at learning how large a message gmail
> can handle before blowing up <wink>. OK, I'll cut even more.

Heh.

> [Michael]
> >>> Can't we use the stuff defined in Appendix F and header <fenv.h> of
> >>> C99 to help here? I know this stuff is somewhat optional, but it's
> >>> available AFAICT on the platforms I actually use (doesn't mean it
> >>> works, of course).
>
> [Tim]
> >> It's entirely optional part of C99.
>
> > Hmm, is <fenv.h> optional? I'm not finding those words. I know
> > Appendix F is.
>
> fenv.h is required, but the standard is carefully worded so that
> fenv.h may not be of any actual use. For example, a conforming
> implementation can define FE_ALL_EXCEPT as 0 (meaning it doesn't
> define _any_ of the (optional!) signal-name macros: FE_DIVBYZERO,
> etc). That in turn makes feclearexcept() (& so on) pretty much
> useless -- you couldn't specify any flags.

Makes sense.

> >> The most important example of a compiler that doesn't support any of
> >> that stuff is Microsoft's, although they have their own MS-specific
> >> ways to spell most of it.
>
> > OK, *that's* a serious issue.
> >
> > If you had to guess, do you think it likely that MS would ship fenv.h
> > in the next interation of VC++?
>
> Sadly not. If they wanted to do that, they had plenty of time to do
> so before VC 7.1 was released (C99 ain't exactly new anymore). As it
> says on
>
> http://en.wikipedia.org/wiki/C_programming_language
>
> MS and Borland (among others) appear to have no interest in C99.
>
> In part I expect this is because C doesn't pay their bills nearly so
> much as C++ does, and C99 isn't a standard from the C++ world.

This also makes sense, in a slightly depressing way.

> >>> In what way does C99's fenv.h fail? Is it just insufficiently
> >>> available, or is there some conceptual lack?
>
> >> Just that it's not universally supported. Look at fpectlmodule.c for
> >> a sample of the wildly different ways it _is_ spelled across some
> >> platforms.
>
> > C'mon, fpectlmodule.c is _old_. Maybe I'm stupidly optimistic, but
> > perhaps in the last near-decade things have got a little better here.
>
> Ah, but as I've said before, virtually all C compilers on 754 boxes
> support _some_ way to get at this stuff. This includes gcc before C99
> and fenv.h -- if the platforms represented in fpectlmodule.c were
> happy to use gcc, they all could have used the older gcc spellings
> (which are in fpectlmodule.c, BTW, under the __GLIBC__ #ifdef).

Um, well, no, not really. The stuff under __GLIBC___ unsurprisingly
applies to platforms using the GNU project's implementation of the C
library, and GCC is used on many more platforms than just that
(e.g. OS X, FreeBSD). This is all part of the "what exactly are you
claiming supports 754, again?" game, I guess. Even given that, the
glibc section looks mighty Intel specific to me (I don't see why
0x1372 should have any x-architecture meaning).

Now that GCC supports, or aims to support, or will one day support C99
I think you're right in that any GCC-using code can use the same
spelling.

One thing GCC doesn't yet support, it turns out, is the "#pragma STDC
FENV_ACCESS ON" gumpf, which means the optimiser is all too willing to
reorder

feclearexcept(FE_ALL_EXCEPT);
r = x * y;
fe = fetestexcept(FE_ALL_EXCEPT);

into

feclearexcept(FE_ALL_EXCEPT);
fe = fetestexcept(FE_ALL_EXCEPT);
r = x * y;

Argh! Declaring r 'volatile' made it work.

> But they didn't, so they're using "minority" compilers. I used to
> write compilers for a living, but I don't think this is an inside
> secret anymore <wink>: there are a lot fewer C compiler writers than
> there used to be, and a lot fewer companies spending a lot less
> money on developing C compilers than there used to be.

Indeed. Also, less architectures and less C libraries.

> As with other parts of C99, I'd be in favor of following its lead, and
> defining Py_ versions of the relevant macros and functions.

Makes sense!

> >> A maze of #ifdefs could work too, provided we defined a
> >> PyWhatever_XYZ API to hide platform spelling details.
>
> > Hopefully it wouldn't be that bad a maze; frankly GCC & MSVC++ covers
> > more than all the cases I care about.
>
> I'd be happy to settle for just those two at the start, As with
> threading too, Python has suffered from trying to support dozens of
> unreasonable platforms, confined to the tiny subset of abilities
> common to all of them. If, e.g., HP-UX wants a good Python thread or
> fp story, let HP contribute some work for a change. I think we have
> enough volunteers to work out good gcc and MSVC stories -- although I
> expect libm to be an everlasting headache

Well, yes. I think a 'thin wrapper' approach like some of the os
module stuff makes sense here.

Cheers,
mwh

--
I've reinvented the idea of variables and types as in a
programming language, something I do on every project.
-- Greg Ward, September 1998
.

Relevant Pages

  • Re: math.nroot [was Re: A brief question.]
    ... >>> available AFAICT on the platforms I actually use (doesn't mean it ... >> It's entirely optional part of C99. ... Ah, but as I've said before, virtually all C compilers on 754 boxes ... This includes gcc before C99 ...
    (comp.lang.python)
  • Re: A simple parser
    ... In order to get gcc to support those features, one must invoke it in a ... It has no mode in which it's as conforming to C99. ... The only way to get gcc to accept those features ...
    (comp.lang.c)
  • Re: c compilation - gcc vs visual c
    ... Microsoft is running in one platform exclusively. ... So Gcc is not likely to be good on any platform as the people who develop for other platforms will specialise in that and beat GCC? ... Microsoft along with every other compiler INCLUDING GCC is at C95 with SOME parts of C99 implemented. ...
    (comp.lang.c)
  • Re: support of C99 VLA in compilers
    ... In particular I'm interested in VLA support. ... I read that GCC had experimental VLA ... >>> support since before C99 and that it still isn't ...
    (comp.lang.c)
  • Re: function -> macro
    ... GCC and other C compilers now support many of the new features ... GCC, despite its extensive C99 support, is still not a completely ...
    (comp.lang.c)