Is anyone working, or planning to do work, on std.complex?  If not, and if it is desirable, I could take a look at it.  I guess the main thing that is needed is to add overloaded operators.  Is there anything else?

Also, I wonder:  How do you feel about renaming "modulus" and "angle" to "mod" and "arg"?  I seldom hear or use the term "angle" in relation to complex numbers.  "Argument" and "phase" are much more common, and the standard mathematical notation for the argument of a complex number is Arg(z).  Also, "mod" and "arg" are nice and short, like "re" and "im".

-Lars


-- 
Lars Tandle Kyllingstad
@: lars at kyllingen.net
#: 40233221
w: http://www.kyllingen.net

Good call! Walter mentioned he should transfer some knowledge to Don in the matter. Walter, please let us know how we can plan this.

Don suggested that the polar representation is very seldom used so we may as well throw it away. I like it because it illustrates how library is more flexible than built-in...


Andrei

On 03/25/2010 04:03 PM, Lars Tandle Kyllingstad wrote:
> Is anyone working, or planning to do work, on std.complex?  If not, and if it is desirable, I could take a look at it. I guess the main thing that is needed is to add overloaded operators. Is there anything else?
>
> Also, I wonder: How do you feel about renaming "modulus" and "angle" to "mod" and "arg"? I seldom hear or use the term "angle" in relation to complex numbers. "Argument" and "phase" are much more common, and the standard mathematical notation for the argument of a complex number is Arg(z). Also, "mod" and "arg" are nice and short, like "re" and "im".
>
> -Lars
>
>

On 25 March 2010 22:54, Andrei Alexandrescu <andrei at erdani.com> wrote:
> Good call! Walter mentioned he should transfer some knowledge to Don in the matter. Walter, please let us know how we can plan this.
>
> Don suggested that the polar representation is very seldom used so we may as well throw it away.

That's not the direct reason. The issue is that it's difficult to do
polar representation in a way which preserves numerically desirable
properties. For instance, the invariant   if (x==x) assert( x == -
(-x)); MUST be preserved, but isn't true for a naive polar
representation. This rules out the use of floating point for the arg
-- you probably want to use some form of fixed point. Then you have
the problem that PI isn't exactly representable as a floating-point
number. And it's downhill from there.
And this is the reason why polar representation is seldom used -- it's
virtually always a bad idea.
Generally speaking the best way of doing polar representation is to
put a wrapper over a cartesian complex type!

> I like it because it illustrates how library is more flexible than built-in...

More convincing I think will be when we have things like BigFloat implemented, and can do complex!(BigFloat).


>
>
> Andrei
>
> On 03/25/2010 04:03 PM, Lars Tandle Kyllingstad wrote:
>>
>> Is anyone working, or planning to do work, on std.complex? ?If not, and if it is desirable, I could take a look at it. I guess the main thing that is needed is to add overloaded operators. Is there anything else?
>>
>> Also, I wonder: How do you feel about renaming "modulus" and "angle" to "mod" and "arg"? I seldom hear or use the term "angle" in relation to complex numbers. "Argument" and "phase" are much more common, and the standard mathematical notation for the argument of a complex number is Arg(z). Also, "mod" and "arg" are nice and short, like "re" and "im".
>>
>> -Lars
>>
>>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

Sounds good to me.

Walter, what steps do we need to take to extricate complex from the language and put the related code in the stdlib with Don's help?


Thanks,

Andrei

On 03/25/2010 08:34 PM, Don Clugston wrote:
> On 25 March 2010 22:54, Andrei Alexandrescu<andrei at erdani.com>  wrote:
>> Good call! Walter mentioned he should transfer some knowledge to Don in the matter. Walter, please let us know how we can plan this.
>>
>> Don suggested that the polar representation is very seldom used so we may as well throw it away.
>
> That's not the direct reason. The issue is that it's difficult to do
> polar representation in a way which preserves numerically desirable
> properties. For instance, the invariant   if (x==x) assert( x == -
> (-x)); MUST be preserved, but isn't true for a naive polar
> representation. This rules out the use of floating point for the arg
> -- you probably want to use some form of fixed point. Then you have
> the problem that PI isn't exactly representable as a floating-point
> number. And it's downhill from there.
> And this is the reason why polar representation is seldom used -- it's
> virtually always a bad idea.
> Generally speaking the best way of doing polar representation is to
> put a wrapper over a cartesian complex type!
>
>> I like it because it illustrates how library is more flexible than built-in...
>
> More convincing I think will be when we have things like BigFloat implemented, and can do complex!(BigFloat).
>
>
>>
>>
>> Andrei
>>
>> On 03/25/2010 04:03 PM, Lars Tandle Kyllingstad wrote:
>>>
>>> Is anyone working, or planning to do work, on std.complex?  If not, and if it is desirable, I could take a look at it. I guess the main thing that is needed is to add overloaded operators. Is there anything else?
>>>
>>> Also, I wonder: How do you feel about renaming "modulus" and "angle" to "mod" and "arg"? I seldom hear or use the term "angle" in relation to complex numbers. "Argument" and "phase" are much more common, and the standard mathematical notation for the argument of a complex number is Arg(z). Also, "mod" and "arg" are nice and short, like "re" and "im".
>>>
>>> -Lars
>>>
>>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Andrei Alexandrescu wrote:
> Sounds good to me.
>
> Walter, what steps do we need to take to extricate complex from the language and put the related code in the stdlib with Don's help?
>
>

It's pretty trivial. You can use the complex support code in dmd as a good starting point.

Don Clugston wrote:
> On 25 March 2010 22:54, Andrei Alexandrescu <andrei at erdani.com> wrote:
>> Good call! Walter mentioned he should transfer some knowledge to Don in the matter. Walter, please let us know how we can plan this.
>>
>> Don suggested that the polar representation is very seldom used so we may as well throw it away.
> 
> That's not the direct reason. The issue is that it's difficult to do polar representation in a way which preserves numerically desirable properties. For instance, the invariant   if (x==x) assert( x == - (-x)); MUST be preserved, but isn't true for a naive polar representation. This rules out the use of floating point for the arg -- you probably want to use some form of fixed point. Then you have the problem that PI isn't exactly representable as a floating-point number. And it's downhill from there.

Good points.  When you think about it, most no-ops will end up being ops for polar-form complex FP numbers if done na?vely.

   -(-z)
   z + 0
   z.toCartesian.toPolar


> And this is the reason why polar representation is seldom used -- it's
> virtually always a bad idea.
> Generally speaking the best way of doing polar representation is to
> put a wrapper over a cartesian complex type!

I agree.  I think having arg() and mod() as @properties of a Cartesian complex type is good enough.  They could even be setter properties, as long as the documentation mentions the computational cost and numerical error.

-Lars



>> On 03/25/2010 04:03 PM, Lars Tandle Kyllingstad wrote:
>>> Is anyone working, or planning to do work, on std.complex?  If not, and if it is desirable, I could take a look at it. I guess the main thing that is needed is to add overloaded operators. Is there anything else?
>>>
>>> Also, I wonder: How do you feel about renaming "modulus" and "angle" to "mod" and "arg"? I seldom hear or use the term "angle" in relation to complex numbers. "Argument" and "phase" are much more common, and the standard mathematical notation for the argument of a complex number is Arg(z). Also, "mod" and "arg" are nice and short, like "re" and "im".
>>>
>>> -Lars
>>>
>>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Walter Bright wrote:
> 
> 
> Andrei Alexandrescu wrote:
>> Sounds good to me.
>>
>> Walter, what steps do we need to take to extricate complex from the language and put the related code in the stdlib with Don's help?
>>
>>
> 
> It's pretty trivial. You can use the complex support code in dmd as a good starting point.

http://www.dsource.org/projects/dmd/browser/trunk/src/complex_t.h http://www.dsource.org/projects/dmd/browser/trunk/src/backend/bcomplex.c

Would these contain the code you are referring to?

Both look like standard, straightforward implementations of complex arithmetic operations.  Are there optimisations hidden in other parts of the code that I'm not seeing?

-Lars

Here's a start:

http://github.com/kyllingstad/ltk/blob/master/ltk/complex.d

Would this be usable?

-Lars


Andrei Alexandrescu wrote:
> Good call! Walter mentioned he should transfer some knowledge to Don in the matter. Walter, please let us know how we can plan this.
> 
> Don suggested that the polar representation is very seldom used so we may as well throw it away. I like it because it illustrates how library is more flexible than built-in...
> 
> 
> Andrei
> 
> On 03/25/2010 04:03 PM, Lars Tandle Kyllingstad wrote:
>> Is anyone working, or planning to do work, on std.complex?  If not, and if it is desirable, I could take a look at it. I guess the main thing that is needed is to add overloaded operators. Is there anything else?
>>
>> Also, I wonder: How do you feel about renaming "modulus" and "angle" to "mod" and "arg"? I seldom hear or use the term "angle" in relation to complex numbers. "Argument" and "phase" are much more common, and the standard mathematical notation for the argument of a complex number is Arg(z). Also, "mod" and "arg" are nice and short, like "re" and "im".
>>
>> -Lars
>>
>>

On 03/26/2010 09:02 AM, Lars Tandle Kyllingstad wrote:
> Here's a start:
>
> http://github.com/kyllingstad/ltk/blob/master/ltk/complex.d
>
> Would this be usable?
>
> -Lars

I assume you meant to send this to the list, so I'm adding it now.

Looks like a good start. A few comments:

* Instead of R, you may want to remove it and use FPTemporary defined in std.numeric

* Use auto instead of T when you can, e.g.:

T absRe = abs(re);

should be

auto absRe = abs(re);

Probably using auto throughout may even obviate the need for FPTemporary (I defer to Don).

* Some asserts before division by zero would be helpful. Carrying through with silent NaNs annoy the heck out of anyone.

* All opOpAssign should return ref Complex, not Complex

Thanks for your work!


Andrei

Andrei Alexandrescu wrote:
> On 03/26/2010 09:02 AM, Lars Tandle Kyllingstad wrote:
>> Here's a start:
>>
>> http://github.com/kyllingstad/ltk/blob/master/ltk/complex.d
>>
>> Would this be usable?
>>
>> -Lars
> 
> I assume you meant to send this to the list, so I'm adding it now.

Yeah, it took a while before I realised I hadn't.


> Looks like a good start. A few comments:
> 
> * Instead of R, you may want to remove it and use FPTemporary defined in std.numeric

I didn't know such a thing existed.  That's very clever!


> * Use auto instead of T when you can, e.g.:
> 
> T absRe = abs(re);
> 
> should be
> 
> auto absRe = abs(re);

Ok.


> Probably using auto throughout may even obviate the need for FPTemporary (I defer to Don).
> 
> * Some asserts before division by zero would be helpful. Carrying through with silent NaNs annoy the heck out of anyone.

I agree.


> * All opOpAssign should return ref Complex, not Complex

I learn something new every day. :)

-Lars