www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.math - contribution

reply Tiago Gasiba <tiago.gasiba gmail.com> writes:
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
next sibling parent reply Tomás Rossi <Tomás_member pathlink.com> writes:
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
parent Tiago Gasiba <tiago.gasiba gmail.com> writes:
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
prev sibling next sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
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: 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) { #int main() { (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[]) { #alias _sum!(cdouble[]) sum; #alias _sum!(double[]) sum; #alias _sum!(int[]) sum; /Oskar
Nov 18 2005
parent Tiago Gasiba <tiago.gasiba gmail.com> writes:
Oskar Linde schrieb:

 
 You can implement almost this syntax yourself:
 
 #import std.stdio;

 #double sum(double[] x) {






 #int main() {




 
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
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
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
next sibling parent reply Tiago Gasiba <tiago.gasiba gmail.com> writes:
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
parent J C Calvarese <technocrat7 gmail.com> writes:
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
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
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
next sibling parent reply Tiago Gasiba <tiago.gasiba gmail.com> writes:
Sean Kelly schrieb:

 Would it be alright if these functions were added to Ares as well?
 
Yes! Definitively. And I would encourage you to do so. 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
parent reply "Tony" <ignore nowhere.com> writes:
"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?
Yes! Definitively. And I would encourage you to do so. 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
next sibling parent J C Calvarese <technocrat7 gmail.com> writes:
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?
Yes! Definitively. And I would encourage you to do so. 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
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
prev sibling parent Sean Kelly <sean f4.ca> writes:
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
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
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
parent Sean Kelly <sean f4.ca> writes:
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