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.

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

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.

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

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.

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.

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.

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

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

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.