FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

std.math
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic     Forum Index -> Ares
View previous topic :: View next topic  
Author Message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Tue Jan 17, 2006 12:22 pm    Post subject: std.math Reply with quote

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
View user's profile Send private message
qbert



Joined: 30 Mar 2004
Posts: 209
Location: Dallas, Texas

PostPosted: Wed Jan 18, 2006 7:21 am    Post subject: Reply with quote

Cool! Im a math dope myself, but would 'ai' stuff go into this package ?
Back to top
View user's profile Send private message MSN Messenger
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Wed Jan 18, 2006 9:41 am    Post subject: Reply with quote

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
View user's profile Send private message
gmiller



Joined: 20 Jan 2006
Posts: 4

PostPosted: Fri Jan 20, 2006 8:32 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
Don Clugston



Joined: 05 Oct 2005
Posts: 91
Location: Germany (expat Australian)

PostPosted: Wed Jan 25, 2006 2:40 am    Post subject: Reply with quote

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
View user's profile Send private message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Mon Jan 30, 2006 1:31 pm    Post subject: Reply with quote

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
View user's profile Send private message
Don Clugston



Joined: 05 Oct 2005
Posts: 91
Location: Germany (expat Australian)

PostPosted: Tue Jan 31, 2006 2:14 am    Post subject: Reply with quote

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
View user's profile Send private message
Don Clugston



Joined: 05 Oct 2005
Posts: 91
Location: Germany (expat Australian)

PostPosted: Tue Jan 31, 2006 6:11 am    Post subject: std.math function list Reply with quote

*****************
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
View user's profile Send private message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Tue Jan 31, 2006 11:17 am    Post subject: Re: std.math function list Reply with quote

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
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Tue Jan 31, 2006 11:57 am    Post subject: Reply with quote

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
View user's profile Send private message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Tue Jan 31, 2006 12:40 pm    Post subject: Reply with quote

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 Wink
Back to top
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Tue Jan 31, 2006 12:59 pm    Post subject: Reply with quote

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 Wink

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 Smile

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
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Tue Jan 31, 2006 2:52 pm    Post subject: Reply with quote

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
View user's profile Send private message
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Tue Jan 31, 2006 3:54 pm    Post subject: Reply with quote

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 Smile
Back to top
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Tue Jan 31, 2006 4:55 pm    Post subject: Reply with quote

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 Smile

True. Millions of Java programmers are OK with it Smile
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Ares All times are GMT - 6 Hours
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
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