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