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

[Michael Hudson]

Tim Peters <tim.peters at gmail.com> 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