digitalmars.D - std.math - contribution
- Tiago Gasiba <tiago.gasiba gmail.com> Nov 18 2005
- Tomás Rossi <Tomás_member pathlink.com> Nov 18 2005
- Tiago Gasiba <tiago.gasiba gmail.com> Nov 18 2005
- Oskar Linde <oskar.lindeREM OVEgmail.com> Nov 18 2005
- Tiago Gasiba <tiago.gasiba gmail.com> Nov 18 2005
- Don Clugston <dac nospam.com.au> Nov 18 2005
- Tiago Gasiba <tiago.gasiba gmail.com> Nov 18 2005
- J C Calvarese <technocrat7 gmail.com> Nov 18 2005
- Sean Kelly <sean f4.ca> Nov 18 2005
- Tiago Gasiba <tiago.gasiba gmail.com> Nov 18 2005
- "Tony" <ignore nowhere.com> Nov 19 2005
- J C Calvarese <technocrat7 gmail.com> Nov 19 2005
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Nov 19 2005
- Sean Kelly <sean f4.ca> Nov 19 2005
- Don Clugston <dac nospam.com.au> Nov 21 2005
- Sean Kelly <sean f4.ca> Nov 21 2005
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8Bit
Hi all,
In my work I use a lot of complex number computations.
It's great that D has a native support for them but, the std.math is still
missing a lot of functions for complex math.
Attached you can find a small file with some routines that I hope to be
integrated in future std.math versions.
These routines might need a bit workout, but they are working fine right now
. At least in my code - have not stress tested the routines.
Additionally I have the following suggestions to improve the D language:
- Allow a native .conj. For example have the following code
cdouble x = 1+2i;
cdouble y = x.conj;
- Allow the power of numbers to be written like ** or something similar,
e.g.
y = y**2; or even y**=2; (means, square y and store in y)
- Allow summations like:
cdouble[] x;
cdouble s;
x.length = 20;
...
s = x.sum; (equivalent to for(s=0, i=0; i<x.length; i++ )
s+=x[ii] )
- Allow max/min finding
double[] x;
double max, min;
...
s = x.max; (equivalent to for(max=0, i=0; i<x.length; i++ ) if(
max<x[ii] ) max=x[ii]; )
s = x.min; (similar to above)
- Allow initializations like (syntax similar to Matlab)
double[] x;
x[] = 1 : 1e-2 : 10;
(equivalent to the following:)
x.length = 901;
for( idx=0, double t=1.0; t<=10.0; t+=1e-2 )
x[ idx++ ] = t;
Since the .sort got incorporated into the language why can't also .sum, .min,
.max, etc?
The above proposals essentially make scientific programming in D much easier.
Finally, the function toString() produces correct, but ugly results. For
example:
printf("%.*s\n",toString(1-2i));
produces the following output: 1+-2i
Wouldn't it be much better to have 1-2i ?
As for routines with complex numbers, the more I need during my work, the
more contributions I'll be posting!
Best,
Tiago
--
Tiago Gasiba (M.Sc.) - http://www.gasiba.de
Everything should be made as simple as possible, but not simpler.
Nov 18 2005
In article <dlkl8v$15up$1 digitaldaemon.com>, Tiago Gasiba says...- Allow the power of numbers to be written like ** or something similar, e.g. y = y**2; or even y**=2; (means, square y and store in y)
Wouldn't that clash (or create ambiguities) with * token? (pointer, dereference unary operator). Though I always dreamed with that pow operator I have to say (or maybe another symbol if that isn't possible).Finally, the function toString() produces correct, but ugly results. For example: printf("%.*s\n",toString(1-2i)); produces the following output: 1+-2i Wouldn't it be much better to have 1-2i ?
Yes, agree. Tom
Nov 18 2005
Tomás Rossi schrieb:In article <dlkl8v$15up$1 digitaldaemon.com>, Tiago Gasiba says...- Allow the power of numbers to be written like ** or something similar, e.g. y = y**2; or even y**=2; (means, square y and store in y)
Wouldn't that clash (or create ambiguities) with * token? (pointer, dereference unary operator). Though I always dreamed with that pow operator I have to say (or maybe another symbol if that isn't possible).
Agree. That would would create parsing problems. How about something like: y ^^ = 2; Syntax looks a bit clumsy but no better idea is occouring me right now. Tiago -- Tiago Gasiba (M.Sc.) - http://www.gasiba.de Everything should be made as simple as possible, but not simpler.
Nov 18 2005
In article <dlkl8v$15up$1 digitaldaemon.com>, Tiago Gasiba says...Additionally I have the following suggestions to improve the D language: - Allow a native .conj. For example have the following code cdouble x = 1+2i; cdouble y = x.conj;
Yes. This looks nicer than conj(x). I may be in a minority, but I kind of like the current ability to inject methods in array-types: # int myfunc(int[] arr) { return 1; } if x is int[], x.myfunc() is equivalent to myfunc(x). If this could somehow be made possible for non-array types too, a library could define x.conj() (or maybe even x.conj)- Allow the power of numbers to be written like ** or something similar, e.g. y = y**2; or even y**=2; (means, square y and store in y) - Allow summations like: cdouble[] x; cdouble s; x.length = 20; ... s = x.sum; (equivalent to for(s=0, i=0; i<x.length; i++ ) s+=x[ii] )
You can implement almost this syntax yourself: #import std.stdio; # #double sum(double[] x) { # double r = 0; # foreach(double d; x) # r += d; # return r; #} # #int main() { # static double t[] = [1.2,2.4,4.8]; # writef("sum of %s is %s\n",t,t.sum()); # return 0; #} (I'm not sure why t.sum() works, but not t.sum)- Allow max/min finding double[] x; double max, min; ... s = x.max; (equivalent to for(max=0, i=0; i<x.length; i++ ) if( max<x[ii] ) max=x[ii]; ) s = x.min; (similar to above)
Same as above.- Allow initializations like (syntax similar to Matlab) double[] x; x[] = 1 : 1e-2 : 10; (equivalent to the following:) x.length = 901; for( idx=0, double t=1.0; t<=10.0; t+=1e-2 ) x[ idx++ ] = t;
It is currently possible to implement with this syntax: x = ArrayRange!(double)(1,1e-2,10);Since the .sort got incorporated into the language why can't also .sum, .min, .max, etc? The above proposals essentially make scientific programming in D much easier.
Those are easy to implement in a library for all basic types: #template _sum(T:T[]) { # T _sum(T[] x) { # T r = 0; # foreach(T v; x) # r += v; # return r; # } #} # #// Implicit template instantiation for a predefined subset of parameters :) #alias _sum!(cdouble[]) sum; #alias _sum!(double[]) sum; #alias _sum!(int[]) sum; #// etc... /Oskar
Nov 18 2005
Oskar Linde schrieb:You can implement almost this syntax yourself: #import std.stdio; # #double sum(double[] x) { # double r = 0; # foreach(double d; x) # r += d; # return r; #} # #int main() { # static double t[] = [1.2,2.4,4.8]; # writef("sum of %s is %s\n",t,t.sum()); # return 0; #}
Oh! Amazing! The more I learn D, the more I can not imagine myself without it :) Thanks! Tiago -- Tiago Gasiba (M.Sc.) - http://www.gasiba.de Everything should be made as simple as possible, but not simpler.
Nov 18 2005
Tiago Gasiba wrote:Hi all, In my work I use a lot of complex number computations. It's great that D has a native support for them but, the std.math is still missing a lot of functions for complex math. Attached you can find a small file with some routines that I hope to be integrated in future std.math versions. These routines might need a bit workout, but they are working fine right now . At least in my code - have not stress tested the routines.
Yes, we definitely need to get into the standard before 1.0. I've also got some complex number stuff in http://www.dsource.org/projects/mathextra/ go to the SVN repository, and look at complex.html, code in complex.d. Some of the functions are not yet implemented (although all the statistics stuff is). Needs some more unit tests too. Might be good to combine our code (and confirm they both give the same results!), and get it up to submission standard. I could definitely use nChoosek in some of my statistics unit tests. One issue you'll find is that there is currently a problem with D implicit conversions of literals. sin(1.0) could be sin(real) or sin(creal). I've requested implicit conversion real -> creal be removed, but it hasn't happened yet. Hopefully my code will give you a boost.
Nov 18 2005
Don Clugston schrieb:Yes, we definitely need to get into the standard before 1.0. I've also got some complex number stuff in http://www.dsource.org/projects/mathextra/ go to the SVN repository, and look at complex.html, code in complex.d.
Don, thanks alot for your message. I have tried to contact you through your email, but was not successfull. If you do not wish to publish your address online, could you please send me an email so that I can contact you back? Thanks! (Sorry for posting this in the DigitalMars Newsgroup). Tiago -- Tiago Gasiba (M.Sc.) - http://www.gasiba.de Everything should be made as simple as possible, but not simpler.
Nov 18 2005
In article <dlktst$1eqq$1 digitaldaemon.com>, Tiago Gasiba says...Don Clugston schrieb:Yes, we definitely need to get into the standard before 1.0. I've also got some complex number stuff in http://www.dsource.org/projects/mathextra/ go to the SVN repository, and look at complex.html, code in complex.d.
Don, thanks alot for your message. I have tried to contact you through your email, but was not successfull. If you do not wish to publish your address online, could you please send me an >email so that I can contact you back? Thanks!
If you're afraid of cluttering up the this newsgroup discussing MathExtra, you might post to the MathExtra forum at dsource: http://www.dsource.org/forums/viewforum.php?f=75 jcc7
Nov 18 2005
Don Clugston wrote:Tiago Gasiba wrote:Hi all, In my work I use a lot of complex number computations. It's great that D has a native support for them but, the std.math is still missing a lot of functions for complex math. Attached you can find a small file with some routines that I hope to be integrated in future std.math versions. These routines might need a bit workout, but they are working fine right now . At least in my code - have not stress tested the routines.
Yes, we definitely need to get into the standard before 1.0.
Would it be alright if these functions were added to Ares as well? Sean
Nov 18 2005
Sean Kelly schrieb:Would it be alright if these functions were added to Ares as well?
The routines that I have posted previously are GPL. As for MathExtra Don can tell you about that, licensing, etc! As I said before, I'll post a few more routines after some time. Those you can also add to Ares as well. :) Best, Tiago -- Tiago Gasiba (M.Sc.) - http://www.gasiba.de Everything should be made as simple as possible, but not simpler.
Nov 18 2005
"Tiago Gasiba" <tiago.gasiba gmail.com> wrote in message news:dllbpq$1rda$1 digitaldaemon.com...Sean Kelly schrieb:Would it be alright if these functions were added to Ares as well?
The routines that I have posted previously are GPL. As for MathExtra Don can tell you about that, licensing, etc! As I said before, I'll post a few more routines after some time. Those you can also add to Ares as well. :) Best, Tiago
Ok this really worries me. I assumed that all code which is accepted into the standard library would be covered under a single license. In particular, one which allows for commercial, closed-source development. Is this the case, or do we have a hodge podge of different licensing schemes? Tony Melbourne, Australia
Nov 19 2005
In article <dlmu0v$3ci$1 digitaldaemon.com>, Tony says..."Tiago Gasiba" <tiago.gasiba gmail.com> wrote in message news:dllbpq$1rda$1 digitaldaemon.com...Sean Kelly schrieb:Would it be alright if these functions were added to Ares as well?
The routines that I have posted previously are GPL. As for MathExtra Don can tell you about that, licensing, etc! As I said before, I'll post a few more routines after some time. Those you can also add to Ares as well. :) Best, Tiago
Ok this really worries me. I assumed that all code which is accepted into the standard library would be covered under a single license. In particular, one which allows for commercial, closed-source development. Is this the case, or do we have a hodge podge of different licensing schemes? Tony Melbourne, Australia
I can't find the post, but I think Walter requested that contributions either be "contributed to Digital Mars" or "public domain". But I could be remembering it wrong. Since the DMD front-end source is licensed as dual GPL and Artistic something has to be done to keep it consistent. I think Phobos has similar license conditions. jcc7
Nov 19 2005
Tony wrote:Ok this really worries me. I assumed that all code which is accepted into the standard library would be covered under a single license. In particular, one which allows for commercial, closed-source development. Is this the case, or do we have a hodge podge of different licensing schemes?
It used to be a real hodge-podge, but it's getting better... Most of it is now under the BSDish "zlib/libpng" license: http://www.prowiki.org/wiki4d/wiki.cgi?PhobosLicenseIssues (if there are changes lately, feel free to update that page) --anders
Nov 19 2005
Tony wrote:Ok this really worries me. I assumed that all code which is accepted into the standard library would be covered under a single license. In particular, one which allows for commercial, closed-source development. Is this the case, or do we have a hodge podge of different licensing schemes?
Anything accepted into Ares will be covered under a single license, which has yet to be determined. I'd expect it to be some variant of the BSD license however. I know Walter has accepted things into Phobos in the past that had their own license requirements (the old std.math), but I don't expect that to continue unless there's something highly specialized that needs to be in which simply has no free implementation available. Sean
Nov 19 2005
Sean Kelly wrote:Don Clugston wrote:Tiago Gasiba wrote:Hi all, In my work I use a lot of complex number computations. It's great that D has a native support for them but, the std.math is still missing a lot of functions for complex math. Attached you can find a small file with some routines that I hope to be integrated in future std.math versions. These routines might need a bit workout, but they are working fine right now . At least in my code - have not stress tested the routines.
Yes, we definitely need to get into the standard before 1.0.
Would it be alright if these functions were added to Ares as well?
Sean, everything in mathextra is public domain, and the project description specifically mentions Ares. (In fact, part of the reason I've made it as a seperate project is to ensure there's a public domain version of it, to make it easy to plug into Ares). Have a look, several of these functions are already there, with a reasonable level of documentation. ----- 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 --- Sorry everyone, I've realised that probably belongs in the Ares forum, (although it is also relevant for Phobos). I just think that this is something that C got badly wrong, and is worth further thought. -Don.
Nov 21 2005
Don Clugston wrote:Sean, everything in mathextra is public domain, and the project description specifically mentions Ares. (In fact, part of the reason I've made it as a seperate project is to ensure there's a public domain version of it, to make it easy to plug into Ares). Have a look, several of these functions are already there, with a reasonable level of documentation.
Thanks! I will. Sean
Nov 21 2005









Tiago Gasiba <tiago.gasiba gmail.com> 