View previous topic :: View next topic |
Author |
Message |
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Tue Jan 17, 2006 12:22 pm Post subject: std.math |
|
|
Looks like it's about that time. Don outlined a basic structure here:
Quote: | I would like to see D move a little away from the C/C++ library structure -- "math.h" is a monster, it's ridiculous that the whole of mathematics gets ONE header file! It's particularly bad in D, where implementation and header are stored in one.
If I could do it from scratch, I'd make std.math a directory, and do it this way:
I see three broad categories:
(1) Special interest stuff that is not frequently used; certainly it would be rare for more than one of these to be used in a single source file. Most programmers won't use most of this.
std.math.statistics -- functions from mathemematical statistics (almost all of these are already implemented in MathExtra)
std.math.discrete -- things like factorials, primes, the nChoosek function just submitted, etc.
std.math.special -- Mathematical Special Functions. Bessel functions, Airy functions, hyperfluent geometrics, etc. A couple of these are in MathExtra.
?std.math.random -- random number generators with specific distributions, eg Poissonian. More suitable for Monte-Carlo type simulations than crypotographic ones. Uses the basic random number from somewhere else, eg std.random, (which is used for games, and is also extended by cryptographic stuff).
(2) Low level stuff, that is virtually built-in, but is computer hardware-oriented rather than genuinely mathematical.
std.math.ieee -- low-level stuff which manipulates bit patterns in IEEE reals. Includes things like isnan(), but also the stuff from "fenv.h" in C, including setting rounding modes.
(3) General purpose stuff from the C standard library, except for the things already covered above. Less sure about these. General idea being that anyone who uses these functions doesn't pull in any functions that they didn't learn about in high school.
std.math.core (?) -- elementary functions (circular and hyperbolic trig, exp, log, pow, sqrt) and basic operations on built-in types (absolute value, complex conjugates, etc).
std.math.matrix -- linear algebra
std.math.all (? except that it is NOT everything!) std.math.cmath (?? meaning the stuff that comes in C libraries. ?but it looks like "complex math" Aaargh) -- Wrapper file that publicly imports std.math.core, std.math.ieee.
Ideally, this last one would just be called std.math, but it does not seem possible to have a module name with the same as a directory name.
Some kind of arrangement like this seems to late for Phobos, but not for Ares.
Another possibility, that might work with Phobos, would be to have a subdirectory "advmath", for advanced mathematics. Then we'd have
std.advmath.statistics, std.advmath.special, etc.
but unfortunately also
std.advmath.matrix |
At the moment, I'm planning to add a new package, std.math, that will initially contain these files:
core
discrete
ieee
matrix
random
special
statistics
I don't consider myself an authority on this stuff, so if anyone has suggestions, please post them here. |
|
Back to top |
|
|
qbert
Joined: 30 Mar 2004 Posts: 209 Location: Dallas, Texas
|
Posted: Wed Jan 18, 2006 7:21 am Post subject: |
|
|
Cool! Im a math dope myself, but would 'ai' stuff go into this package ? |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Wed Jan 18, 2006 9:41 am Post subject: |
|
|
Probably the basics, yes, as game theory is a field of mathematics. Actually, with that in mind, it may be worth eventually adding support for some of the more common problem-solving algorithms--I've always like swarm theory at any rate. Though perhaps this sort of thing would be more suited to an add-on library. |
|
Back to top |
|
|
gmiller
Joined: 20 Jan 2006 Posts: 4
|
Posted: Fri Jan 20, 2006 8:32 am Post subject: |
|
|
I like the idea of breaking out the math library into the different areas. Personally I think that the core stuff should just remain in std.math while the other areas get moved around. I don't worry so much about the single huge file though it is frustrating in the absence of a really good quality documentation generator.
Being a physics guy I like the breakdown that you've given but I would hesitate to add stuff from a specific field (AI or game theory for example) into the math tree but would add them to a package of their own ( std.ai and std.game for example) |
|
Back to top |
|
|
Don Clugston
Joined: 05 Oct 2005 Posts: 91 Location: Germany (expat Australian)
|
Posted: Wed Jan 25, 2006 2:40 am Post subject: |
|
|
Great! The nice thing about the mathematical functions is that they are very well defined and uncontroversial. So there's less chance of making bad library decisions.
I think it's important that if you import std.math.core, you shouldn't experience code bloat. Bulky functions like erf() which are in std.math in phobos, should not go into std.math.core; they probably belong in std.math.special.
Actually, there's a possibility for a useful convention here:
xxx/core.d includes the most commonly used parts of the package xxx.
xxx/all.d includes everything in package xxx.
Maybe there's a better word than 'core', but it's short.
The only functions which I'm confident belong in std.math.ieee are:
nan(char [] tagp)
nextafter(),
fmin(), .. fma().
frexp() --- is this one of the ones that causes code bloat in Phobos?
ldexp() --- but note that this is an intrinsic.
Some of the others are peculiar.
isnan(x) is important enough to be std.math.core. Problem is, once you include it, you also have to include isinf(), isnormal() and issubnormal() which was my original example for std.math.ieee! But all those functions can be rewritten to avoid the low-level hacks. For example, isnan() is equivalent to x!<>0 or even (x!=x). That gives faster code, and is independent of CPU architecture. But the effect on the x87 flags register is different -- they'll set the NAN flag if the argument is a NAN -- but this might be a good thing.
bool isnan(real x) { return x!=x; }
// Note that these all return false for nan.
bool isinf(real x) { return fabs(x)==real.infinity; }
bool issubnormal(double x) { return fabs(x) < double.min; }
bool issubnormal(float x) { return fabs(x) < float.min; }
bool isnormal(float x) { return fabs(x) >= float.min; }
etc.
modf() -- isn't this the same as the ? operator? The docs say that in D, you use ? instead of modf(), so I don't think this should have been added (it came in around DMD 0.135). |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Mon Jan 30, 2006 1:31 pm Post subject: |
|
|
Don, would it be too much to ask for you to provide lists of which functions you think belong in each module? Some I know, but I suspect others would require some googling make sense of. Also, I don't suppose Tiago Gasiba would be inclined to open his functions for use as well? With their current copyright I'm hesitant to include them, but his functions cover some important areas. |
|
Back to top |
|
|
Don Clugston
Joined: 05 Oct 2005 Posts: 91 Location: Germany (expat Australian)
|
Posted: Tue Jan 31, 2006 2:14 am Post subject: |
|
|
Quote: | Don, would it be too much to ask for you to provide lists of which functions you think belong in each module?
|
I'll work on it. I'm still working out some of the details. I found a very helpful paper that was submitted to the C++ standards committee, proposing mathematical special functions, which I'm currently digesting.
One function I'm having trouble deciding about is my own feqrel(). It's clearly low-level, but I think it would see use outside of library functions.
I'm also wondering whether the locations of the intrinsics are hard-coded into the compiler. Can ldexp() be moved out of std.math, for example? If not, our hands may be tied.
Quote: | Also, I don't suppose Tiago Gasiba would be inclined to open his functions for use as well? With their current copyright I'm hesitant to include them, but his functions cover some important areas. |
He posted this to me in a private message:
Quote: |
As you know, I have recently posted a message to the D newsgroup with some contributions (routines for complex number operations and the nchoosek function) whereby I have said that the routines are GPL.
Well..., I do not wish to be a "show stopper" and I like D a lot. If, for this reason you have not included these routines in the MathExtra project, please tell me so. In this case, please consider the routines as "Public Domain".
I have initially stated that the routines are GPL because this is the licensing that I best know in Linux. |
Hmm, I should copy the email onto the public forum of MathExtra. |
|
Back to top |
|
|
Don Clugston
Joined: 05 Oct 2005 Posts: 91 Location: Germany (expat Australian)
|
Posted: Tue Jan 31, 2006 6:11 am Post subject: std.math function list |
|
|
*****************
std.math.core
(the elementary mathematical functions)
*****************
constants E, PI, etc.
PRIMITIVES
abs
conj
TRIG FUNCTIONS
cos sin tan
acos asin atan atan2
cosh sinh tanh
acosh asinh atanh
POWERS AND ROOTS
sqrt cbrt
exp expm1 exp2
log log1p log2 log10
pow
hypot
poly
ROUNDING (returning real)
floor
ceil
round
trunc
ROUNDING (return int/long)
--> see below
*****************
std.math.ieee
(these functions won't make sense to someone who doesn't know
anything about IEEE arithmetic, they will mostly be used in libraries)
*****************
rndtonl
frexp
ldexp
ilogb (and FP_ILOGB0, FP_ILOGBNAN)
logb
scalbn
nextafter
nan(char [] tagp)
fdim
fabs // intrinsic, normal user will use abs() instead
?fmax // we probably want templated max(), min() anyway
?fmin
fma
isPosZero isNegZero // change names to lowercase
isnormal issubnormal
? isfinite
? isinf
? isnan
? feqrel
? copysign
? signbit
--> some things from std.c.fenv will also go in here.
*****************
std.math.special
(these won't make sense to someone who hasn't done advanced mathematics. And, it's rare
for many of these to be used in a single program). The implementation for each of these
functions is quite large.
math.special might need to be a directory itself; but then there's the problem that
a function can't have the same name as the module it's in.
Might make more sense to have:
std.math.gammafn;
?std.math.errorfn;
*****************
erf erfc
tgamma lgamma // I'd really prefer the names gamma and
// loggamma. tgamma is an ugly historical accident.
--> bessel functions, etc will also go here
*****************
doubtful
*****************
modf -- deprecate? use ? instead.
remainder() seems like a rounding-mode-independent version of ?, and would therefore
belong in std.math.ieee
remquo() belongs with remainder, but it seems less esoteric; maybe it belongs in std.math.core.
The most important rounding function (by far) is to convert a real number
to a long or int, using the current rounding mode. This is necessary because
D is following the *ridiculous* C convention that casts from real to int use trunc()
rounding. On x87, this is *less accurate* and *much slower* than the default rounding mode!
C has billions of rounding functions, but not the most important one!
It's even more important in D, where we don't have implicit conversions real -> int.
We need a function that does this, in std.math.core.
? lrint -- this does what we want, but it's such a stupid name for something so important.
Maybe we could create such functions, call them
int rndint(real)
long rndlong(real)
and put them in std.math.core
If we had such a function, the following would probably be unnecessary, anyone who really wanted them could get them from the C library.
? rint() and nearbyint() which CONTRARY TO THEIR NAME return a real, not an integer.
? rndtol
? lround |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Tue Jan 31, 2006 11:17 am Post subject: Re: std.math function list |
|
|
Thanks! I'll see what I can do about getting all this into the next update. Anything that's listed as questionable or redundant because of D's built-in functionality I'm simply going to deprecate and see if anyone screams about it.
As for special... I suppose we'll see. I'm quite used to having large source files in C++, so I don't consider length itself to be a motivating factor for organization in most cases. I'd rather find an arrangement that makes logical sense and go from there. If it turns out later that special should be subdivided then so be it, but it sounds like doing so now might be a bit too speculative. |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Tue Jan 31, 2006 11:57 am Post subject: |
|
|
This is great, but do you think it's necessary to force everything to lowercase? Heck ~ why not just make it all uppercase instead? Really. Do you feel people are not capable of handling a combination of case? |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Tue Jan 31, 2006 12:40 pm Post subject: |
|
|
Barring objections, I was just going to camelCase where appropriate. I'll admit that one of my ulterior motives in attempting to stick to the D style guide is that by doing so it eliminates one potential objection Walter may have to Ares |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Tue Jan 31, 2006 12:59 pm Post subject: |
|
|
sean wrote: | Barring objections, I was just going to camelCase where appropriate. I'll admit that one of my ulterior motives in attempting to stick to the D style guide is that by doing so it eliminates one potential objection Walter may have to Ares |
The D style has still to evolve. If adopted by the masses, Ares and other projects like it, will ultimately guide the stylistic cues. It's quite possible that Walter didn't even give much thought to the 'guidelines' indicated on the D website? It ain't the gospel. Heck, virtually all of it is adopted from other languages anyway
I wouldn't worry about getting a blessing from Walter. He'll be perfectly happy that you're trying to do something to help. Also, take a look at what happened to DWT ... Shawn lowercased all the module names, making it harder to distinguish what's what. Personally, I think that was a small yet perhaps costly mistake.
2 cents. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Tue Jan 31, 2006 2:52 pm Post subject: |
|
|
I think Kris is right here. Capitals in the module names (in the stye of class name CamelCase) should be acceptable practice (or perhaps THE practice). I follow that naming convention in my projects.
-JJR |
|
Back to top |
|
|
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
Posted: Tue Jan 31, 2006 3:54 pm Post subject: |
|
|
I agree that CamelCase looks clearer, but the biggest objection has been that some platforms (all but win32 generally) are case sensitive, whereas windows ain't. So as long as we all make sure that we save the files using the same CamelCase, we should be alright |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Tue Jan 31, 2006 4:55 pm Post subject: |
|
|
larsivi wrote: | I agree that CamelCase looks clearer, but the biggest objection has been that some platforms (all but win32 generally) are case sensitive, whereas windows ain't. So as long as we all make sure that we save the files using the same CamelCase, we should be alright |
True. Millions of Java programmers are OK with it |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|