On 27 November 2013 22:29, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> On 26/11/13 17:28, Andrei Alexandrescu wrote:
>>
>> On 11/26/13 3:22 AM, Joseph Rushton Wakeling wrote:
>>>
>>> So, as other people have suggested, really the only thing we can reasonably do is to define a separate Imaginary type
>>
>>
>> I agree. Let's move forward with this.
>
>
> I've started work, code is here: https://github.com/WebDrake/phobos/tree/imaginary
>
> Feedback, forks/pull requests, etc. welcome.

That repo doesn't seem to exist (must by my imagination).

On 29/11/13 08:50, Iain Buclaw wrote:
> That repo doesn't seem to exist (must by my imagination).

It's just the branch "imaginary" in my regular Phobos repo (I always use feature branches for new stuff).

The link works for me, what goes wrong for you?

On 29 November 2013 08:57, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> On 29/11/13 08:50, Iain Buclaw wrote:
>>
>> That repo doesn't seem to exist (must by my imagination).
>
>
> It's just the branch "imaginary" in my regular Phobos repo (I always use feature branches for new stuff).
>
> The link works for me, what goes wrong for you?
>

Turned out the RJ45 cable in my computer was imaginary. :o)

On 29 November 2013 11:50, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> On 29 November 2013 08:57, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
>> On 29/11/13 08:50, Iain Buclaw wrote:
>>>
>>> That repo doesn't seem to exist (must by my imagination).
>>
>>
>> It's just the branch "imaginary" in my regular Phobos repo (I always use feature branches for new stuff).
>>
>> The link works for me, what goes wrong for you?
>>
>
> Turned out the RJ45 cable in my computer was imaginary. :o)

Fixed by switching to real. :-P

On 26/11/13 17:28, Andrei Alexandrescu wrote:
> On 11/26/13 3:22 AM, Joseph Rushton Wakeling wrote:
>> So, as other people have suggested, really the only thing we can
>> reasonably do is to define a separate Imaginary type
>
> I agree. Let's move forward with this.

Provisional code:
https://github.com/D-Programming-Language/phobos/pull/1797

I also realized there was no explicit issue report, so created one:
https://d.puremagic.com/issues/show_bug.cgi?id=11787

On 2013-12-20 16:25:53 +0000, Joseph Rushton Wakeling said:

> On 26/11/13 17:28, Andrei Alexandrescu wrote:
>> On 11/26/13 3:22 AM, Joseph Rushton Wakeling wrote:
>>> So, as other people have suggested, really the only thing we can
>>> reasonably do is to define a separate Imaginary type
>> 
>> I agree. Let's move forward with this.
> 
> Provisional code:
> https://github.com/D-Programming-Language/phobos/pull/1797
> 
> I also realized there was no explicit issue report, so created one:
> https://d.puremagic.com/issues/show_bug.cgi?id=11787

Awesome.   Thank you!

-Shammah

On 19/11/2013 02:03, Andrei Alexandrescu wrote:> On 11/18/13 5:44 PM, Craig Dillabaugh wrote:
<snip>
>> Is there any reason why complex numbers in D's standard lib must
>> be of non-integral types?  I believe in C++ the type is optimized
>> for floating point values, but allows other types.
>
> The simple reason is we couldn't find appropriate applications.
<snip>

I don't understand.  At the moment Complex appears to me to be type-agnostic - as long as a type supports the standard arithmetic operators and assignment of the value 0 to it, it will work.  The only thing preventing it from working at the moment is this line

    struct Complex(T)  if (isFloatingPoint!T)

So why do you need an appropriate application in order not to have this arbitrary restriction?  Or have I missed something?

It isn't just integer types.  Somebody might want to use complex with a library (fixed-point, arbitrary precision, decimal, etc.) numeric type.  Fractal generators, for example, are likely to use this a lot.

Or even more exotically, use Complex!(Complex!real) to implement hypercomplex numbers.

Stewart.

On Tuesday, 26 November 2013 at 21:11:25 UTC, David Nadlinger wrote:
> IEEE 754 includes infinity as an actual value, contrary to the usual definition of real numbers in mathematics.

A bit late, but AFAIK inf represents either overflow or N/0... And 0 represents either underflow or zero. Computations on those values should be conservative unless you trap overflow/underflow exceptions and handle those as special cases. You want to preserve overflow... Then you have the denormal numbers (underflow where you retain some digits). It is tempting to think of FP as real numbers, but they are not, of course, so libraries should IMO be conservative.

On Wednesday, 1 January 2014 at 12:29:35 UTC, Stewart Gordon wrote:
> I don't understand.  At the moment Complex appears to me to be type-agnostic - as long as a type supports the standard arithmetic operators and assignment of the value 0 to it, it will work.  The only thing preventing it from working at the moment is this line
>
>     struct Complex(T)  if (isFloatingPoint!T)
>
> So why do you need an appropriate application in order not to have this arbitrary restriction?  Or have I missed something?

There are binary operations on complex numbers where the only sensible outcome seems to be non-integral real and imaginary parts. Addition, subtraction and multiplication are OK with integral types, but division really seems unpleasant to implement absent floating point, exponentiation even more so.

I imagine there are ways to resolve this, but it certainly simplifies implementation to assume floating-point, and absent a compelling application there is not much reason to avoid that simplification.

> It isn't just integer types.  Somebody might want to use complex with a library (fixed-point, arbitrary precision, decimal, etc.) numeric type.
>  Fractal generators, for example, are likely to use this a lot.

I agree that such any numeric type that effectively models a real number should be supported. In principle it ought to be sufficient to check that the required "floating-point-ish" operations (including sin and cos) are supported, plus maybe some tweaks to how internal temporary values are handled.

However, I think relaxing the template constraints like this would best be done in the context of a library float-esque type (e.g. BigFloat) being implemented in Phobos, which could then be used to provide both proof-of-concept and the primary test case.

> Or even more exotically, use Complex!(Complex!real) to implement hypercomplex numbers.

Perhaps best implemented as a type in its own right? :-)

On Tuesday, 19 November 2013 at 01:44:32 UTC, Craig Dillabaugh wrote:
> The complex type in std.complex restricts the real/imaginary
> parts of the number to be float/double/real.  I am curious to
> know if there is a reason why integral types are not permitted. I
> checked the C++ equivalent and it does not have the same
> requirement.

Quoting the C++ standard, §26.4:

"The effect of instantiating the template complex for any type other than float, double, or long double is unspecified."

So even if some implementations support it, it is *not* standard C++.

Lars