www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.complex

reply "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
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.

I mention this because some of my work is done with radar
satellite images. All pixels in such an images are stored as
complex numbers, but in all cases I am aware of they are stored a
short int values. Most software that operates on the images uses
complex<short> (most of it is C++).

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.
Nov 18 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/18/13 5:44 PM, 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.

 I mention this because some of my work is done with radar
 satellite images. All pixels in such an images are stored as
 complex numbers, but in all cases I am aware of they are stored a
 short int values. Most software that operates on the images uses
 complex<short> (most of it is C++).

 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. If you make a good argument, we'll include integral types as well. Submit an enhancement request on bugzilla including your example and let's take it from there. Andrei
Nov 18 2013
next sibling parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Tuesday, 19 November 2013 at 02:03:05 UTC, Andrei Alexandrescu
wrote:
 On 11/18/13 5:44 PM, 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.

 I mention this because some of my work is done with radar
 satellite images. All pixels in such an images are stored as
 complex numbers, but in all cases I am aware of they are 
 stored a
 short int values. Most software that operates on the images 
 uses
 complex<short> (most of it is C++).

 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. If you make a good argument, we'll include integral types as well. Submit an enhancement request on bugzilla including your example and let's take it from there. Andrei
I will see if I can put something together. Regards, Craig
Nov 18 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 19 November 2013 02:03, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 On 11/18/13 5:44 PM, 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.

 I mention this because some of my work is done with radar
 satellite images. All pixels in such an images are stored as
 complex numbers, but in all cases I am aware of they are stored a
 short int values. Most software that operates on the images uses
 complex<short> (most of it is C++).

 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. If you make a good argument, we'll include integral types as well. Submit an enhancement request on bugzilla including your example and let's take it from there.
Gaussian integers / Graph plotting? IMO I don't see a reason why not to support in the library if it requires no change on the compiler side. Regards Iain,
Nov 26 2013
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Jan 01 2014
next sibling parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
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? :-)
Jan 01 2014
next sibling parent "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Wednesday, 1 January 2014 at 19:55:58 UTC, Joseph Rushton 
Wakeling wrote:
 On Wednesday, 1 January 2014 at 12:29:35 UTC, Stewart Gordon 
 wrote:
 [...] 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.
I agree completely. This is the main reason why I chose to explicitly disallow integral types when I wrote std.complex.
 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.
Agreed. Any "floating point-like" library type which is to be supported by std.complex must either have cos(), sin(), hypot(), etc. as member functions (since std.complex cannot import non-std modules), or the type needs to be supported by std.math as well. If so, std.math is the place to start, not std.complex.
Jan 01 2014
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 01/01/2014 19:55, Joseph Rushton Wakeling wrote:
<snip>
 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,
Then why not just disable division if it's a non-float type, rather than preventing the whole complex template from being used with that type? This is like cutting off somebody's arm because they have a sore thumb. Moreover, we have no way in the general case of determining whether T is an integral type, a library float-esque type, or (for example) a Galois field type. So disabling it _just in case_ division doesn't work is crazy. There must be better ways to do it.
 exponentiation even more so.
Exponentiation by a non-negative integer is straightforward. So we should at least support this case for Gaussian integers. <snip>
 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.
What do you mean by "in the context of", exactly? Restricting it to some float-esque type that is in Phobos would still be overly restrictive.
 Or even more exotically, use Complex!(Complex!real) to implement
 hypercomplex numbers.
Perhaps best implemented as a type in its own right?
It would, but removing the restriction would simplify the implementation of Hypercomplex(T) by enabling it to be a wrapper for Complex!(Complex!T). Stewart.
Jan 02 2014
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Thursday, 2 January 2014 at 18:12:56 UTC, Stewart Gordon wrote:
 Then why not just disable division if it's a non-float type, 
 rather than preventing the whole complex template from being 
 used with that type? This is like cutting off somebody's arm 
 because they have a sore thumb.
Because that also seems to me to be an unpleasant option. A complex number implementation that fails to support ordinary arithmetic operations in all circumstances is pretty non-intuitive and will probably lead to unpleasant bugs in users' code.
 Moreover, we have no way in the general case of determining 
 whether T is an integral type, a library float-esque type, or 
 (for example) a Galois field type.  So disabling it _just in 
 case_ division doesn't work is crazy.  There must be better 
 ways to do it.
I don't follow your point here. We can constrain T however we see fit. The point isn't to have some perfect representation of every mathematical possibility, it's to have useful code that serves a good range of use-cases while being robust and easy to maintain. Restricting T to floating point types is a useful simplification here that has few costs in terms of expected use-cases.
 Exponentiation by a non-negative integer is straightforward.  
 So we should at least support this case for Gaussian integers.
Again, I don't see it as being useful to have a Complex!T whose support for binary operations may vary depending on the type of T.
 What do you mean by "in the context of", exactly?  Restricting 
 it to some float-esque type that is in Phobos would still be 
 overly restrictive.
No, I mean that until you have at least one actual float-esque type to test with, it is probably unwise to relax the template constraints that currently mandate built-in FP types.
 It would, but removing the restriction would simplify the 
 implementation of Hypercomplex(T) by enabling it to be a 
 wrapper for Complex!(Complex!T).
And complicate the implementation of Complex itself, for the sake of a likely very marginal special interest that could be supported quite well by an independent type.
Jan 02 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 2 January 2014 at 19:32:32 UTC, Joseph Rushton 
Wakeling wrote:
 No, I mean that until you have at least one actual float-esque 
 type to test with, it is probably unwise to relax the template 
 constraints that currently mandate built-in FP types.
Fixed-point support might not be important on x86, but it has been needed and used for complex numbers in the past on other CPUs.
Jan 02 2014
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Thursday, 2 January 2014 at 19:50:46 UTC, Ola Fosheim Grøstad 
wrote:
 Fixed-point support might not be important on x86, but it has 
 been needed and used for complex numbers in the past on other 
 CPUs.
I agree that should be supported. I just think that template constraints should only be relaxed in the context of concrete test cases, otherwise you're making promises you don't know you can keep.
Jan 02 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 2 January 2014 at 19:58:27 UTC, Joseph Rushton 
Wakeling wrote:
 I agree that should be supported. I just think that template 
 constraints should only be relaxed in the context of concrete 
 test cases, otherwise you're making promises you don't know you 
 can keep.
Yes, that is very true. Fixed-point is very sensitive to precision-loss so it requires some careful thinking, so it is definitively not a drop-in replacement type. (It is actually useful on x86 too when you want reproducible results across binaries and hardware, such as in peer-to-peer syncing of computed state.)
Jan 02 2014
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 02/01/2014 19:32, Joseph Rushton Wakeling wrote:
 On Thursday, 2 January 2014 at 18:12:56 UTC, Stewart Gordon wrote:
 Then why not just disable division if it's a non-float type, rather
 than preventing the whole complex template from being used with that
 type? This is like cutting off somebody's arm because they have a sore
 thumb.
Because that also seems to me to be an unpleasant option. A complex number implementation that fails to support ordinary arithmetic operations in all circumstances is pretty non-intuitive and will probably lead to unpleasant bugs in users' code.
The compiler rejecting the code is the most pleasant bug that's possible IMO.
 Moreover, we have no way in the general case of determining whether T
 is an integral type, a library float-esque type, or (for example) a
 Galois field type.  So disabling it _just in case_ division doesn't
 work is crazy.  There must be better ways to do it.
I don't follow your point here. We can constrain T however we see fit. The point isn't to have some perfect representation of every mathematical possibility, it's to have useful code that serves a good range of use-cases while being robust and easy to maintain.
Not being overly restrictive in what types you will allow it to be used with is an important part of serving a good range of use cases. <snip>
 What do you mean by "in the context of", exactly?  Restricting it to
 some float-esque type that is in Phobos would still be overly
 restrictive.
No, I mean that until you have at least one actual float-esque type to test with, it is probably unwise to relax the template constraints that currently mandate built-in FP types.
I'm sure we have a small handful already. We just need to find them. For instance, given the time I could probably dig up my rational number implementation and update it to current D.
 It would, but removing the restriction would simplify the
 implementation of Hypercomplex(T) by enabling it to be a wrapper for
 Complex!(Complex!T).
And complicate the implementation of Complex itself, for the sake of a likely very marginal special interest that could be supported quite well by an independent type.
How would it complicate the implementation? Removing the undocumented rule whereby Complex!(Complex!T) folds to Complex!T would be a slight simplification. Maybe the right course of action is to have a parameter to the template that suppresses the type restriction and the folding rule, so that people who want to use it on a type that might not work properly can do so. This would be a relatively small change. Stewart.
Jan 02 2014
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Thursday, 2 January 2014 at 20:23:40 UTC, Stewart Gordon wrote:
 The compiler rejecting the code is the most pleasant bug that's 
 possible IMO.
It's still unpleasant relative to the intuitive expectation that numerical types should support all basic numerical operations.
 Not being overly restrictive in what types you will allow it to 
 be used with is an important part of serving a good range of 
 use cases.
It's a question of balance: breadth of support vs. ease of implementation and maintenance. Some use cases may be better served in other ways than rolling them into one "catch-all" type.
 I'm sure we have a small handful already.  We just need to find 
 them. For instance, given the time I could probably dig up my 
 rational number implementation and update it to current D.
I'd really like to see that anyway, for its own sake; I've been working on a std.rational based on David Simcha's work, it would be good to compare.
 How would it complicate the implementation?  Removing the 
 undocumented rule whereby Complex!(Complex!T) folds to 
 Complex!T would be a slight simplification.
It would involve non-trivial revisions to the internals of Complex. If you want to submit a pull request supporting this I'm sure it'll be considered carefully, but it is not something to be done casually.
 Maybe the right course of action is to have a parameter to the 
 template that suppresses the type restriction and the folding 
 rule, so that people who want to use it on a type that might 
 not work properly can do so.  This would be a relatively small 
 change.
I do not know how familiar you are with the internals of std.complex.Complex but I think it would be a good idea to go through them in some detail before asserting that changes like this would be "relatively small".
Jan 02 2014
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 02/01/2014 21:10, Joseph Rushton Wakeling wrote:
 On Thursday, 2 January 2014 at 20:23:40 UTC, Stewart Gordon wrote:
<snip>
 How would it complicate the implementation?  Removing the undocumented
 rule whereby Complex!(Complex!T) folds to Complex!T would be a slight
 simplification.
It would involve non-trivial revisions to the internals of Complex.
Please be specific. <snip>
 Maybe the right course of action is to have a parameter to the
 template that suppresses the type restriction and the folding rule, so
 that people who want to use it on a type that might not work properly
 can do so.  This would be a relatively small change.
I do not know how familiar you are with the internals of std.complex.Complex but I think it would be a good idea to go through them in some detail before asserting that changes like this would be "relatively small".
Oh yes, some of the templated functions that take or return a complex would need this extra parameter adding. Another way it could be done is to have a Complex template that implements these rules and which programmers would normally use, and have this aliasing ComplexImpl which actually provides the implementation and which programmers can use directly if they want to bypass the restrictions. The difficulty is documenting it in a way that would make sense to normal users.... Stewart.
Jan 02 2014
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 03/01/14 00:33, Stewart Gordon wrote:
 Please be specific.
You know, I'm starting to find your tone irritating. You are the one who's asking for functionality that goes beyond any Complex implementation that I'm aware of in any other language, and claiming that these things would be trivial to implement. I would expect a person who claims with confidence that something is trivial, to actually know the internals of the code well enough to understand what parts of it would need to be modified. On the basis of what you've written, I have no reason to believe that you do. There are numerous places inside current std.complex.Complex where temporary values are used mid-calculation. Those are all of type FPTemporary (which in practice means real). So, to handle library types (whether library floating-point types such as a BigFloat implementation, or a Complex!T so as to support hypercomplex numbers) you'd either have to special-case those functions or you'd have to provide an alternative Temporary template to handle the temporary internal values in the different cases. You'd also need to address questions of closure under operations (already an issue for the Imaginary type), and precision-related issues -- see e.g. the remarks by Craig Dillabaugh and Ola Fosheim Grøstad elsewhere in this thread. While it could be done, I don't think it would be simple to get right and I would regard it as a major revision of std.complex. I'd also be concerned that generalizing Complex in this way might lead to performance regressions for the standard Complex!T use-cases, due to the more complicated templates involved.
 Oh yes, some of the templated functions that take or return a complex would
need
 this extra parameter adding.
No. The internals would need significant rewriting, for reasons I've already elaborated.
 Another way it could be done is to have a Complex template that implements
these
 rules and which programmers would normally use, and have this aliasing
 ComplexImpl which actually provides the implementation and which programmers
can
 use directly if they want to bypass the restrictions.  The difficulty is
 documenting it in a way that would make sense to normal users....
If you want these things done in these ways, then I think the onus is on you to provide code which works and doesn't damage existing std.complex functionality. I don't personally see any rationale for implementing hypercomplex numbers as a specialization of Complex given that they can be just as well implemented as a type in their own right.
Jan 02 2014
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 03/01/2014 00:03, Joseph Rushton Wakeling wrote:
 On 03/01/14 00:33, Stewart Gordon wrote:
 Please be specific.
You know, I'm starting to find your tone irritating. You are the one who's asking for functionality that goes beyond any Complex implementation that I'm aware of in any other language, and claiming that these things would be trivial to implement.
I wasn't asking for it to go beyond the existing complex implementation or any other. I was proposing that the arbitrary restriction be removed so that the implementation we already have would work on them. As I said originally:
 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?
OK, so division has now been mentioned. And you have now mentioned the use of FPTemporary. However....
 I would expect a person who claims with confidence that something is
 trivial, to actually know the internals of the code well enough to
 understand what parts of it would need to be modified. On the basis
 of what you've written, I have no reason to believe that you do.
I had read the code before I made that comment, and from reading it I did believe at the time that the implementation was ready for types other than float, real and double. So the use of FPTemporary is something I missed, but it's taken you this long to point it out to me. However....
 There are numerous places inside current std.complex.Complex where
 temporary values are used mid-calculation.  Those are all of type
 FPTemporary (which in practice means real).So, to handle library
 types (whether library floating-point types such as a BigFloat
 implementation, or a Complex!T so as to support hypercomplex numbers)
 you'd either have to special-case those functions or you'd have to
 provide an alternative Temporary template to handle the temporary
 internal values in the different cases.
FPTemporary is a template. At the moment it's defined only for the built-in floating point types. So what we really need is to define FPTemporary for other types. For int and smaller integral types, we can define it as real just as we do for float/double/real. Whether it's adequate for long would be platform-dependent. For other types, I suppose we can reference a property of the type, or just use the type itself if such a property isn't present. One possible idea (untested): ----- template FPTemporary(F) if (is(typeof(-F.init + F.init * F.init - F.init))) { static if (isFloatingPoint!F || isIntegral!F) { alias real FPTemporary; } else static if (is(F.FPTemporary)) { alias F.FPTemporary FPTemporary; } else { alias F FPTemporary; } } ----- Of course, this isn't a completely general solution, and I can see now that whatever type we use would need to have trigonometric functions in order to support exponentiation. So unless we conditionalise the inclusion of this operation....
 You'd also need to address questions of closure under operations
 (already an issue for the Imaginary type), and precision-related issues
 -- see e.g. the remarks by Craig Dillabaugh and Ola Fosheim Grøstad
 elsewhere in this thread.
Oh yes, and it would be crazy to try and make it work for unsigned integer types. But even if we were to resolve the issues with FPTemporary and that, it would still fall under my earlier suggestion of making it so that if people want to use Complex on an unsupported type then they can explicitly suppress the type restriction, but should understand that it might not work properly. <snip>
 I don't personally see any rationale for implementing hypercomplex
 numbers as a specialization of Complex given that they can be just as
 well implemented as a type in their own right.
Really, I was just thinking that somebody who wants a quick-and-dirty hypercomplex number implementation for some app might try to do it that way. Stewart.
Jan 03 2014
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 03/01/14 14:32, Stewart Gordon wrote:
 I wasn't asking for it to go beyond the existing complex implementation or any
 other.  I was proposing that the arbitrary restriction be removed so that the
 implementation we already have would work on them.
Yes, but it isn't an arbitrary restriction. Template constraints are fundamentally a promise to users about what can be expected to work. Integral types, or library types, won't work without significant modifications to the internals of the code. It would be a false promise to relax those constraints.
 FPTemporary is a template.  At the moment it's defined only for the built-in
 floating point types.  So what we really need is to define FPTemporary for
other
 types.  For int and smaller integral types, we can define it as real just as we
 do for float/double/real.  Whether it's adequate for long would be
 platform-dependent.  For other types, I suppose we can reference a property of
 the type, or just use the type itself if such a property isn't present.

 One possible idea (untested):
 -----
 template FPTemporary(F)
          if (is(typeof(-F.init + F.init * F.init - F.init))) {
      static if (isFloatingPoint!F || isIntegral!F) {
          alias real FPTemporary;
      } else static if (is(F.FPTemporary)) {
          alias F.FPTemporary FPTemporary;
      } else {
          alias F FPTemporary;
      }
 }
 -----
Yes, it ought to be possible to redefine FPTemporary (or define an alternative) to determine proper internal temporaries for any "float-esque" case. I was toying with something along the lines of, template FPTemporary(F) if (isNumeric!F || isFloatLike!F) { alias typeof(real.init * F.init) FPTemporary; } ... where isFloatLike would test for appropriate floating-point-like properties of F -- although this is probably far too simplistic. E.g. how do you handle the case of a float-like library type implemented as a class, not a struct? In any case, absent an appropriate test-case in Phobos, it would be premature to generalize the constraints for Complex or the design of FPTemporary.
 Oh yes, and it would be crazy to try and make it work for unsigned integer
 types.  But even if we were to resolve the issues with FPTemporary and that, it
 would still fall under my earlier suggestion of making it so that if people
want
 to use Complex on an unsupported type then they can explicitly suppress the
type
 restriction, but should understand that it might not work properly.
People who want to use Complex on an unsupported type can quite readily copy-paste the code and remove the constraints, if that's what they want to do. I think that's better than giving them an option which is essentially an invitation to shoot themselves in the foot, and which has very little chance of actually working. It doesn't matter if you document it as "This might not work", by providing the option you are still essentially saying, "This is an OK way to use the type." I think that's essentially an encouragement of bad code and a violation of the design principle that the easy thing to do should be the right thing to do.
 Really, I was just thinking that somebody who wants a quick-and-dirty
 hypercomplex number implementation for some app might try to do it that way.
I understand that, but quick-and-dirty solutions are often bad ones, and in this case, it just wouldn't work given the internals of Complex. If you would like to revise std.complex to support this approach, I'm sure your pull request will be considered carefully, but personally I don't see it as an effective way to pursue hypercomplex number support when there are other options on the table.
Jan 03 2014
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 03/01/2014 17:04, Joseph Rushton Wakeling wrote:
 On 03/01/14 14:32, Stewart Gordon wrote:
 I wasn't asking for it to go beyond the existing complex
 implementation or any other. I was proposing that the arbitrary
 restriction be removed so that the implementation we already have
 would work on them.
Yes, but it isn't an arbitrary restriction. Template constraints are fundamentally a promise to users about what can be expected to work. Integral types, or library types, won't work without significant modifications to the internals of the code. It would be a false promise to relax those constraints.
But I believed the restriction to be arbitrary at the time I made my original point, hence my point. <snip>
 Yes, it ought to be possible to redefine FPTemporary (or define an
 alternative) to determine proper internal temporaries for any
 "float-esque" case.  I was toying with something along the lines of,

      template FPTemporary(F)
          if (isNumeric!F || isFloatLike!F)
      {
          alias typeof(real.init * F.init) FPTemporary;
      }

 ... where isFloatLike would test for appropriate floating-point-like
 properties of F -- although this is probably far too simplistic.
How can isFloatLike be implemented? And how can we test for bigint or Galois field types?
 E.g. how do you handle the case of a float-like library type
 implemented as a class, not a struct?
What's the difficulty here? <snip>
 It doesn't matter if you document it as "This might not work", by
 providing the option you are still essentially saying, "This is an OK
 way to use the type."

 I think that's essentially an encouragement of bad code and a violation
 of the design principle that the easy thing to do should be the right
 thing to do.
There are already violations of this principle in D, such as being able to cast away const.
 Really, I was just thinking that somebody who wants a quick-and-dirty
 hypercomplex number implementation for some app might try to do it
 that way.
I understand that, but quick-and-dirty solutions are often bad ones, and in this case, it just wouldn't work given the internals of Complex.
Addition, subtraction and multiplication would work. So the programmer could just copy the code and reimplement division and exponentiation so that they work (or just get rid of them if they aren't needed). Stewart.
Jan 03 2014
parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 03/01/14 21:21, Stewart Gordon wrote:
 How can isFloatLike be implemented?
I'm not sure. It's something that needs to be thought about and of course it also depends on whether you want it to test just for basic properties, or whether it is supported by mathematical operations (sin, cos, abs, exp, etc.). I think testing for basic properties should be enough, because if mathematical functions are needed but not supported, there will be a compilation error anyway.
 And how can we test for bigint or Galois field types?
For BigInt, it's conceivable to define an isIntegerLike template (David Simcha did this for his std.rational) that will handle library as well as built-in integral types. For Galois field types, I suggest that there needs to be an implementation before one talks about how to support them in std.complex.
 There are already violations of this principle in D, such as being able to cast
 away const.
Casting away const has valid applications and is a bit different from allowing the user to manually ignore template constraints on a library type, which will most likely almost always lead to problematic behaviour. I'm not aware of any library type in Phobos that does this, and if you _really_ want to override the template constraints, you can always copy and modify the code. Then, if it turns out to work well, you can submit patches to allow that case in Phobos too.
 Addition, subtraction and multiplication would work.
They wouldn't, because when you relaxed the template constraints to allow Complex!(Complex!T), the code would fail to compile. And I don't think you should correct that by stripping out basic arithmetic operations.
 So the programmer could just copy the code and reimplement division and
exponentiation so that they work
 (or just get rid of them if they aren't needed).
As I keep saying, you're asking for extra complication to be added to a type that supports its intended (probably the vast majority of) use cases well, for the sake of a niche use case _that can be implemented without any problem as an entirely independent type_. What you perceive as conceptual/notational elegance -- Complex!(Complex!T) -- isn't worth it.
Jan 03 2014
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Wednesday, 1 January 2014 at 12:29:35 UTC, Stewart Gordon 
wrote:
  [...]

 Or even more exotically, use Complex!(Complex!real) to 
 implement hypercomplex numbers.
This is an extremely marginal use case. Currently Complex!(Complex!T) folds to Complex!T. I thought this was specified in the module documentation, but if it was, it's been removed. It is explained in a comment in the source code, though: /* Makes Complex!(Complex!T) fold to Complex!T. The rationale for this is that just like the real line is a subspace of the complex plane, the complex plane is a subspace of itself. Example of usage: --- Complex!T addI(T)(T x) { return x + Complex!T(0.0, 1.0); } --- The above will work if T is both real and complex. */ template Complex(T) if (is(T R == Complex!R)) { alias T Complex; }
Jan 01 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/1/14 3:12 PM, Lars T. Kyllingstad wrote:
 On Wednesday, 1 January 2014 at 12:29:35 UTC, Stewart Gordon wrote:
  [...]

 Or even more exotically, use Complex!(Complex!real) to implement
 hypercomplex numbers.
This is an extremely marginal use case. Currently Complex!(Complex!T) folds to Complex!T.
What was the motivation? Andrei
Jan 01 2014
parent "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Thursday, 2 January 2014 at 02:59:05 UTC, Andrei Alexandrescu
wrote:
 On 1/1/14 3:12 PM, Lars T. Kyllingstad wrote:
 Currently Complex!(Complex!T)
 folds to Complex!T.
What was the motivation?
To simplify generic code, where you have a function that takes both real and complex arguments and returns a complex number, e.g.: Complex!T fun(T)(T x) { return x * someComplexNumber; } In the above, T may be real or complex.
Jan 02 2014
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 01/01/2014 23:12, Lars T. Kyllingstad wrote:
<snip>
 /*  Makes Complex!(Complex!T) fold to Complex!T.

      The rationale for this is that just like the real line is a
      subspace of the complex plane, the complex plane is a subspace
      of itself. Example of usage:
This doesn't seem to make sense - _any_ set is a subspace of itself. But I suppose one way to look at it is that Complex!T means the minimal vector space containing x and i*x for all x in T.
      ---
      Complex!T addI(T)(T x)
      {
          return x + Complex!T(0.0, 1.0);
      }
      ---
So the point is to enable templated functions to accept a real or complex argument and return a complex number.
      The above will work if T is both real and complex.
 */
T is "both real and complex"? How is this possible? Stewart.
Jan 02 2014
prev sibling next sibling parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Wednesday, 1 January 2014 at 12:29:35 UTC, Stewart Gordon
wrote:
 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.
Since I originally proposed this I should chime in again. My use-case for non floating point, complex numbers is radar image processing, where the radar intensity/phase are stored as complex numbers which are quantized as 16-bit integer values. Andrei suggested I come up with a proposal for non-FP complex, but reading this thread, and my experience working with integer valued complex values in C++ has now reversed my opinion. I think the current D requirement is good. Just a small example, the norm() method calculates the squared magnitude of the complex number (eg. you get a single real value). This is an operation that we use extensively in our work. This created problems with generating lots of NaN values due to integer overflows, that were somewhat tricky to find. I can imagine numerous issues like this popping up if using integral values with complex numbers.
Jan 02 2014
prev sibling parent reply =?UTF-8?B?U2ltZW4gS2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On 2014-01-01 12:29, Stewart Gordon wrote:
 Or even more exotically, use Complex!(Complex!real) to implement
 hypercomplex numbers.
For a more generic solution to this, see Cayley-Dickson construction[1] and my implementation of such: https://github.com/Biotronic/Collectanea/blob/master/biotronic/CayleyDickson2.d It's nowhere near finished, has some bugs, and I haven't worked on it for at least a year, but it's an interesting way to create complex, hypercomplex, dual, and split-complex numbers (and combinations thereof). [1]: http://en.wikipedia.org/wiki/Cayley-Dickson_construction -- Simen
Jan 02 2014
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 02/01/2014 15:38, Simen Kjærås wrote:
 On 2014-01-01 12:29, Stewart Gordon wrote:
 Or even more exotically, use Complex!(Complex!real) to implement
 hypercomplex numbers.
For a more generic solution to this, see Cayley-Dickson construction[1] and my implementation of such:
Hypercomplex numbers are outside the scope of Cayley-Dickson construction. The latter defines quaternions, octonions and so on. Though it is confusing as there are at least two definitions of "hypercomplex number": (a) a element of any number system that extends the complex numbers (b) an element of a particular such number system, which is what I was using it to mean. The hypercomplex numbers to which I was referring are as Fractint uses the term, and briefly described at http://mathworld.wolfram.com/HypercomplexNumber.html ij = k, i^2 = j^2 = -1, k = 1. Multiplication is commutative. But the distinctive thing about these is that they can be represented as an ordered pair of complex numbers, and then the complex multiplication formula works on them, hence my suggestion.
 https://github.com/Biotronic/Collectanea/blob/master/biotronic/CayleyDickson2.d


 It's nowhere near finished, has some bugs, and I haven't worked on it
 for at least a year, but it's an interesting way to create complex,
 hypercomplex, dual, and split-complex numbers (and combinations thereof).
<snip> So it's a generalisation of Cayley-Dickson construction to produce a range of 2^n-dimensional algebras over the reals. I'll have to look at it in more detail when I've more time. Stewart.
Jan 02 2014
prev sibling next sibling parent reply Shammah Chancellor <anonymous coward.com> writes:
//Hijack

http://digitalmars.com/d/1.0/cppcomplex.html

 • Consider the formula (1 - infinity*i) * i which should produce 
 (infinity + i). However, if instead the second factor is (0 + i) rather 
 than just i, the result is (infinity + NaN*i), a spurious NaN was 
 generated.
 • A distinct imaginary type preserves the sign of 0, necessary for 
 calculations involving branch cuts.
Is this stuff no longer an issue? -Shammah
Nov 22 2013
next sibling parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Saturday, 23 November 2013 at 04:37:19 UTC, Shammah Chancellor 
wrote:
 //Hijack

 http://digitalmars.com/d/1.0/cppcomplex.html

 • Consider the formula (1 - infinity*i) * i which should 
 produce (infinity + i). However, if instead the second factor 
 is (0 + i) rather than just i, the result is (infinity + 
 NaN*i), a spurious NaN was generated.
 • A distinct imaginary type preserves the sign of 0, necessary 
 for calculations involving branch cuts.
Is this stuff no longer an issue? -Shammah
I believe D used to have builtin complex types, back in the old days. They have been removed (deprecated?) and replaced by the library type std.complex. At least that is my understanding. Craig
Nov 22 2013
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 11/22/2013 09:22 PM, Craig Dillabaugh wrote:

 On Saturday, 23 November 2013 at 04:37:19 UTC, Shammah Chancellor wrote:
 //Hijack

 http://digitalmars.com/d/1.0/cppcomplex.html

 • Consider the formula (1 - infinity*i) * i which should produce
 (infinity + i). However, if instead the second factor is (0 + i)
 rather than just i, the result is (infinity + NaN*i), a spurious NaN
 was generated.
 • A distinct imaginary type preserves the sign of 0, necessary for
 calculations involving branch cuts.
Is this stuff no longer an issue? -Shammah
I believe D used to have builtin complex types, back in the old days. They have been removed (deprecated?)
It still compiles.
 and replaced by the library type
 std.complex.

 At least that is my understanding.
And it makes what Shammah Chancellor quoted even more interesting. cdouble and idouble still work correctly but std.complex produces "incorrect" result: import std.stdio; import std.complex; void main() { writeln(complex(1.0L, -real.infinity) * complex(0.0, 1.0L)); writeln((1L - ireal.infinity) * 1i); } The output: inf-nani <-- "incorrect" according to the quoted page inf+1i <-- correct
 Craig
Ali
Nov 22 2013
next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 23/11/13 08:43, Ali Çehreli wrote:
 import std.stdio;
 import std.complex;

 void main()
 {
      writeln(complex(1.0L, -real.infinity) * complex(0.0, 1.0L));
      writeln((1L - ireal.infinity) * 1i);
 }


 The output:

 inf-nani    <-- "incorrect" according to the quoted page
 inf+1i      <-- correct
It's because 0.0L * (-real.infinity) evaluates to nan.
Nov 24 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/24/13 9:54 AM, Joseph Rushton Wakeling wrote:
 On 23/11/13 08:43, Ali Çehreli wrote:
 import std.stdio;
 import std.complex;

 void main()
 {
      writeln(complex(1.0L, -real.infinity) * complex(0.0, 1.0L));
      writeln((1L - ireal.infinity) * 1i);
 }


 The output:

 inf-nani    <-- "incorrect" according to the quoted page
 inf+1i      <-- correct
It's because 0.0L * (-real.infinity) evaluates to nan.
Has this been submitted as a bug report? Andrei
Nov 24 2013
parent reply Shammah Chancellor <anonymous coward.com> writes:
On 2013-11-24 18:00:45 +0000, Andrei Alexandrescu said:

 On 11/24/13 9:54 AM, Joseph Rushton Wakeling wrote:
 On 23/11/13 08:43, Ali Çehreli wrote:
 import std.stdio;
 import std.complex;
 
 void main()
 {
 writeln(complex(1.0L, -real.infinity) * complex(0.0, 1.0L));
 writeln((1L - ireal.infinity) * 1i);
 }
 
 
 The output:
 
 inf-nani    <-- "incorrect" according to the quoted page
 inf+1i      <-- correct
It's because 0.0L * (-real.infinity) evaluates to nan.
Has this been submitted as a bug report? Andrei
It's more a fundamental problem with a complex type in general. C++ has this issue as well. You need a purely imaginary type with the appropiate operations between Complex and Imaginary defined.
Nov 24 2013
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
24-Nov-2013 22:03, Shammah Chancellor пишет:
 On 2013-11-24 18:00:45 +0000, Andrei Alexandrescu said:

 On 11/24/13 9:54 AM, Joseph Rushton Wakeling wrote:
 On 23/11/13 08:43, Ali Çehreli wrote:
 import std.stdio;
 import std.complex;

 void main()
 {
 writeln(complex(1.0L, -real.infinity) * complex(0.0, 1.0L));
 writeln((1L - ireal.infinity) * 1i);
 }


 The output:

 inf-nani    <-- "incorrect" according to the quoted page
 inf+1i      <-- correct
It's because 0.0L * (-real.infinity) evaluates to nan.
Has this been submitted as a bug report? Andrei
It's more a fundamental problem with a complex type in general. C++ has this issue as well. You need a purely imaginary type with the appropiate operations between Complex and Imaginary defined.
Can't it just check for the real part being exactly zero and special- case multiplication for that? -- Dmitry Olshansky
Nov 24 2013
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Dmitry Olshansky" <dmitry.olsh gmail.com> wrote in message 
news:l6tfm8$2hnj$1 digitalmars.com...

 Can't it just check for the real part being exactly zero and special- case 
 multiplication for that?
There is no such thing as exactly zero in floating point. Only -0 and +0.
Nov 25 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
26-Nov-2013 09:06, Daniel Murphy пишет:
 "Dmitry Olshansky" <dmitry.olsh gmail.com> wrote in message
 news:l6tfm8$2hnj$1 digitalmars.com...

 Can't it just check for the real part being exactly zero and special- case
 multiplication for that?
There is no such thing as exactly zero in floating point. Only -0 and +0.
Well, let it be magnitude, "exactly" implies as good zero test as we need. I'm still of the opinion that a few predictable branches like `if(rhs.re.isZero)` won't kill it. Regardless, the point is that built-ins hardly help here at all as you may just as well get an "exactly" 0+1i for some complex computation, and the result won't suddenly change type to i{real,double,float}. -- Dmitry Olshansky
Nov 26 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/26/13 7:13 AM, Dmitry Olshansky wrote:
 26-Nov-2013 09:06, Daniel Murphy пишет:
 "Dmitry Olshansky" <dmitry.olsh gmail.com> wrote in message
 news:l6tfm8$2hnj$1 digitalmars.com...

 Can't it just check for the real part being exactly zero and special-
 case
 multiplication for that?
There is no such thing as exactly zero in floating point. Only -0 and +0.
Well, let it be magnitude, "exactly" implies as good zero test as we need. I'm still of the opinion that a few predictable branches like `if(rhs.re.isZero)` won't kill it. Regardless, the point is that built-ins hardly help here at all as you may just as well get an "exactly" 0+1i for some complex computation, and the result won't suddenly change type to i{real,double,float}.
I think the problem is we currently don't have a means to distinguish between two cases: (a) "There is no real part here at all" (b) "There is a real part that happens to be zero, or really as close to zero as it can ever get in a discrete representation" It seems the two cases behave differently in a few corner cases, and that is reasonable. Andrei
Nov 26 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Shammah Chancellor:

 It's more a fundamental problem with a complex type in general.
   C++ has this issue as well.   You need a purely imaginary 
 type with the appropiate operations between Complex and 
 Imaginary defined.
Can't you add a new name to std.complex to implement the purely imaginary type? Bye, bearophile
Nov 24 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/24/13 10:03 AM, Shammah Chancellor wrote:
 On 2013-11-24 18:00:45 +0000, Andrei Alexandrescu said:

 On 11/24/13 9:54 AM, Joseph Rushton Wakeling wrote:
 On 23/11/13 08:43, Ali Çehreli wrote:
 import std.stdio;
 import std.complex;

 void main()
 {
 writeln(complex(1.0L, -real.infinity) * complex(0.0, 1.0L));
 writeln((1L - ireal.infinity) * 1i);
 }


 The output:

 inf-nani    <-- "incorrect" according to the quoted page
 inf+1i      <-- correct
It's because 0.0L * (-real.infinity) evaluates to nan.
Has this been submitted as a bug report? Andrei
It's more a fundamental problem with a complex type in general. C++ has this issue as well. You need a purely imaginary type with the appropiate operations between Complex and Imaginary defined.
But that originates as a call to multiplication between two Complex numbers. Can't the problem be addressed at that level? Andrei
Nov 24 2013
next sibling parent reply Shammah Chancellor <anonymous coward.com> writes:
On 2013-11-24 18:37:51 +0000, Andrei Alexandrescu said:

 But that originates as a call to multiplication between two Complex 
 numbers. Can't the problem be addressed at that level?
 
 Andrei
I don't believe so because IEEE floats define inf*0 to be NaN. You would have to check to see if rhs.re == 0 || lhs.re == 0 and then just return zero. Somewhat unfortunate. You really do need an imaginary type for reasons specified in the original page here: http://digitalmars.com/d/1.0/cppcomplex.html -Shammah
Nov 24 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/24/13 10:56 AM, Shammah Chancellor wrote:
 On 2013-11-24 18:37:51 +0000, Andrei Alexandrescu said:

 But that originates as a call to multiplication between two Complex
 numbers. Can't the problem be addressed at that level?

 Andrei
I don't believe so because IEEE floats define inf*0 to be NaN. You would have to check to see if rhs.re == 0 || lhs.re == 0 and then just return zero. Somewhat unfortunate. You really do need an imaginary type for reasons specified in the original page here: http://digitalmars.com/d/1.0/cppcomplex.html -Shammah
Sure. We ain't above defining an imaginary type! Andrei
Nov 24 2013
prev sibling parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Sunday, 24 November 2013 at 18:37:48 UTC, Andrei Alexandrescu 
wrote:
 But that originates as a call to multiplication between two 
 Complex numbers. Can't the problem be addressed at that level?
Don't see why not, but it's going to be an unpleasant mess of if/else unless anyone can think up any clever tricks to avoid it. BTW is it true that IEEE standards define 0 * inf to be nan? It's counter-intuitive mathematically and I can't find a reference to that effect.
Nov 24 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/24/13 3:24 PM, Joseph Rushton Wakeling wrote:
 On Sunday, 24 November 2013 at 18:37:48 UTC, Andrei Alexandrescu wrote:
 But that originates as a call to multiplication between two Complex
 numbers. Can't the problem be addressed at that level?
Don't see why not, but it's going to be an unpleasant mess of if/else unless anyone can think up any clever tricks to avoid it.
How many special cases are out there?
 BTW is it true that IEEE standards define 0 * inf to be nan? It's
 counter-intuitive mathematically and I can't find a reference to that
 effect.
It sort of does. If you multiply something that goes to 0 with something that goes to infinity it could go either way. Andrei
Nov 24 2013
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 25/11/13 00:35, Andrei Alexandrescu wrote:
 How many special cases are out there?
Well, if you have two complex numbers, z1 and z2, then (z1 * z2).re = (z1.re * z2.re) - (z1.im * z2.im) and (z1 * z2).im = (z1.im * z2.re) + (z2.re * z1.im) So you have to do if's for all four of z1.im, z2.re, z2.re and z1.im, and then you have to decide whether you override the apparent IEEE default just for the case of (re * im) or whether you do it for everything. I mean, it feels a bit weird if you allow 0 * inf = 0 when it's real part times imaginary part, but not when it's real part times real part. Do the IEEE standards cover implementation of complex numbers? I confess complete ignorance here (and the Wikipedia page wasn't any help).
 It sort of does. If you multiply something that goes to 0 with something that
 goes to infinity it could go either way.
I'm not sure I follow. I mean, if you have two sequences {x_i} --> 0 and {y_i} --> inf, then sure, the sequence of the product {x_i * y_i} can go either way. But if you just think of 0 as a number, then 0 * inf = 0 * lim{x --> inf} x = lim{x --> inf} (0 * x) = lim{x --> inf} 0 = 0 Or am I missing something about how FP numbers are implemented that either makes it convenient to define 0 * inf as not-a-number or that means that there are ambiguities that don't exist for "real" real numbers?
Nov 25 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/25/13 12:18 AM, Joseph Rushton Wakeling wrote:
 On 25/11/13 00:35, Andrei Alexandrescu wrote:
 How many special cases are out there?
Well, if you have two complex numbers, z1 and z2, then (z1 * z2).re = (z1.re * z2.re) - (z1.im * z2.im) and (z1 * z2).im = (z1.im * z2.re) + (z2.re * z1.im) So you have to do if's for all four of z1.im, z2.re, z2.re and z1.im, and then you have to decide whether you override the apparent IEEE default just for the case of (re * im) or whether you do it for everything. I mean, it feels a bit weird if you allow 0 * inf = 0 when it's real part times imaginary part, but not when it's real part times real part.
Doesn't sound all that bad to me. After all the built-in complex must be doing something similar. Of course if a separate imaginary type helps this and other cases, we should define it.
 It sort of does. If you multiply something that goes to 0 with
 something that
 goes to infinity it could go either way.
I'm not sure I follow. I mean, if you have two sequences {x_i} --> 0 and {y_i} --> inf, then sure, the sequence of the product {x_i * y_i} can go either way. But if you just think of 0 as a number, then 0 * inf = 0 * lim{x --> inf} x = lim{x --> inf} (0 * x) = lim{x --> inf} 0 = 0
Heh, no need for the expansion :o). Zero is zero.
 Or am I missing something about how FP numbers are implemented that
 either makes it convenient to define 0 * inf as not-a-number or that
 means that there are ambiguities that don't exist for "real" real numbers?
Well 0 in FP can always be considered a number so small, 0 was the closest representation. But I'm just speculating as to whether that's the reason for the choice. Andrei
Nov 25 2013
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 25/11/13 18:51, Andrei Alexandrescu wrote:
 Doesn't sound all that bad to me. After all the built-in complex must be doing
 something similar. Of course if a separate imaginary type helps this and other
 cases, we should define it.
Well, if you want it I'm happy to write the patch. It's just I'm not sure that what is happening with std.complex is actually wrong if it's to be considered correct that 0 * inf = nan.
Nov 25 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/25/13 10:37 AM, Joseph Rushton Wakeling wrote:
 On 25/11/13 18:51, Andrei Alexandrescu wrote:
 Doesn't sound all that bad to me. After all the built-in complex must
 be doing
 something similar. Of course if a separate imaginary type helps this
 and other
 cases, we should define it.
Well, if you want it I'm happy to write the patch. It's just I'm not sure that what is happening with std.complex is actually wrong if it's to be considered correct that 0 * inf = nan.
If you got the blessing of some complex number expert, that would be great. Andrei
Nov 25 2013
next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 26/11/13 02:02, Andrei Alexandrescu wrote:
 If you got the blessing of some complex number expert, that would be great.
I'm in Italy, I could ask the pope ... :-) As far as I can see the behaviour of std.complex.Complex is consistent both with C++'s std::complex and with D's own internal cfloat/cdouble/creal types. The only case we don't cover with std.complex is that of multiplying a complex number with a purely imaginary one (the equivalent of multiplying, say, a creal and an ireal; multiplying a creal and a creal, even if the real part of the latter is 0, will give the same results as std.complex). We _could_ tweak Complex internally so that in the event that its real part is 0, it behaves like a purely imaginary number, and if its imaginary part is 0, it behaves like a purely real number; but that's problematic for reasons already discussed, because it doesn't distinguish between a purely imaginary number versus one where the real part is so vanishingly small that FP considers it to be 0. (It also leaves std.complex' behaviour incompatible with std::complex and other library implementations, though I guess that's less of a concern so long as we think what std.complex does is right.) So, as other people have suggested, really the only thing we can reasonably do is to define a separate Imaginary type -- or get round the problems with the built-in complex and imaginary types. It is really a shame if they are as problematic as I've heard. :-(
Nov 26 2013
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 26 November 2013 at 11:22:38 UTC, Joseph Rushton 
Wakeling wrote:
 On 26/11/13 02:02, Andrei Alexandrescu wrote:
 If you got the blessing of some complex number expert, that 
 would be great.
I'm in Italy, I could ask the pope ... :-) As far as I can see the behaviour of std.complex.Complex is consistent both with C++'s std::complex and with D's own internal cfloat/cdouble/creal types. The only case we don't cover with std.complex is that of multiplying a complex number with a purely imaginary one (the equivalent of multiplying, say, a creal and an ireal; multiplying a creal and a creal, even if the real part of the latter is 0, will give the same results as std.complex). We _could_ tweak Complex internally so that in the event that its real part is 0, it behaves like a purely imaginary number, and if its imaginary part is 0, it behaves like a purely real number; but that's problematic for reasons already discussed, because it doesn't distinguish between a purely imaginary number versus one where the real part is so vanishingly small that FP considers it to be 0. (It also leaves std.complex' behaviour incompatible with std::complex and other library implementations, though I guess that's less of a concern so long as we think what std.complex does is right.) So, as other people have suggested, really the only thing we can reasonably do is to define a separate Imaginary type -- or get round the problems with the built-in complex and imaginary types. It is really a shame if they are as problematic as I've heard. :-(
It seems to me that one really shouldn't special case for absolute values when dealing with floating point. A floating Imaginary type and an integer Complex type - both in std.complex - are the correct solutions IMO.
Nov 26 2013
next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 26/11/13 13:52, John Colvin wrote:
 It seems to me that one really shouldn't special case for absolute values when
 dealing with floating point. A floating Imaginary type and an integer Complex
 type - both in std.complex - are the correct solutions IMO.
Yup, agree.
Nov 26 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 26 November 2013 at 13:20:39 UTC, Joseph Rushton 
Wakeling wrote:
 On 26/11/13 13:52, John Colvin wrote:
 It seems to me that one really shouldn't special case for 
 absolute values when
 dealing with floating point. A floating Imaginary type and an 
 integer Complex
 type - both in std.complex - are the correct solutions IMO.
Yup, agree.
Just had a chat with one of our local numerics experts: He agreed that hidden special casing that breaks standards compliance is bad and that whatever the solution was it should be explicit. However, the following situation arises: Complex!double(1, -double.inf) * Complex!int(0, i); What does IEEE say about that? 0 * inf == nan?
Nov 26 2013
next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 26/11/13 14:32, John Colvin wrote:
 What does IEEE say about that? 0 * inf == nan?
Can't speak for the standard, but in both D and C++, 0 * inf evaluates to nan.
Nov 26 2013
prev sibling parent reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Tuesday, 26 November 2013 at 13:32:22 UTC, John Colvin wrote:
 Just had a chat with one of our local numerics experts: He 
 agreed that hidden special casing that breaks standards 
 compliance is bad and that whatever the solution was it should 
 be explicit.
I don't think we should worry too much about standards compliance. A library Complex type is quite different from a hardware floating-point type.
Jan 02 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 2 January 2014 at 11:37:22 UTC, Lars T. Kyllingstad 
wrote:
 I don't think we should worry too much about standards 
 compliance. A library Complex type is quite different from a 
 hardware floating-point type.
Are you sure? Sometimes you need to translate an algorithm, you don't understand the inner workings of, from a codebase/cookbook. If std.complex differs from the most used c++/fortran implementations people will be confused, and you also end up having (machine translated) algorithm libraries each supplying their own complex type. Use 3 different libraries and you have to deal with 3 different complex types. Floating point is rather sensitive to reordering of instructions, so I'd say you'll be better off mirroring one of the major existing implementations, otherwise accumulated discrepancies will be blamed on the language... A new tool that produce the same results as the old proven dinosaur tool look trustworthy. It makes you think that the conversion of your algorithms to the new tool was a success.
Jan 02 2014
parent reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Thursday, 2 January 2014 at 18:37:36 UTC, Ola Fosheim Grøstad 
wrote:
 On Thursday, 2 January 2014 at 11:37:22 UTC, Lars T. 
 Kyllingstad wrote:
 I don't think we should worry too much about standards 
 compliance. A library Complex type is quite different from a 
 hardware floating-point type.
Are you sure?
Not at all. ;) I just think we should keep in mind why FP semantics are defined the way they are. Take 0.0*inf, for example. As has been mentioned, 0.0 may represent a positive real number arbitrarily close to zero, and inf may represent an arbitrarily large real number. The product of these is ill-defined, and hence represented by a NaN. 0.0+1.0i, on the other hand, represents a number which is arbitrarily close to i. Multiplying it with a very large real number gives you a number which has a very large imaginary part, but which is arbitrarily close to the imaginary axis, i.e. 0.0 + inf i. I think this is very consistent with FP semantics, and may be worth making a special case in std.complex.Complex.
 Sometimes you need to translate an algorithm, you don't 
 understand the inner workings of, from a codebase/cookbook. If 
 std.complex differs from the most used c++/fortran 
 implementations people will be confused, and you also end up 
 having (machine translated) algorithm libraries each supplying 
 their own complex type. Use 3 different libraries and you have 
 to deal with 3 different complex types.
I agree, but there is also a lot to be said for not repeating old mistakes, if we deem them to be such.
Jan 02 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 2 January 2014 at 23:43:47 UTC, Lars T. Kyllingstad 
wrote:
 Not at all. ;)
I am never certain about anything related to FP. It is a very pragmatic hack, which is kind of viral. (but fun to talk about ;).
 I just think we should keep in mind why FP semantics are 
 defined the way they are.
Yes, unfortunately they are just kind-of-defined. 0.0 could represent anything from the minimum-denormal number to zero (Intel) to maximum-denormal number to zero (some other vendors). Then we have all the rounding-modes. And it gets worse with single than with double. I think the semantics of IEEE favours double over single, since detecting overflow is less important for double (it occurs seldom for doubles in practice so conflating overflow with 1.0/0.0 matters less for them than for single precision).
 Take 0.0*inf, for example.  As has been mentioned, 0.0 may 
 represent a positive real number arbitrarily close to zero, and 
 inf may represent an arbitrarily large real number. The product 
 of these is ill-defined, and hence represented by a NaN.
Yes, and it is consistent with having 0.0/0.0 evaluate to NaN. ( 0.0*(1.0/0.0) ought to give NaN as well )
 0.0+1.0i, on the other hand, represents a number which is 
 arbitrarily close to i. Multiplying it with a very large real 
 number gives you a number which has a very large imaginary 
 part, but which is arbitrarily close to the imaginary axis, 
 i.e. 0.0 + inf i. I think this is very consistent with FP 
 semantics, and may be worth making a special case in 
 std.complex.Complex.
I am too tired to figure out if you are staying within the max-min interval of potential values that can be represented (if you had perfect precision). I think that is the acid test. In order to reduce the unaccounted-for errors it is better to have a "wider" interval for each step to cover inaccuracies, and a bit dangerous if it gets more "narrow" than it should. I find it useful to try to think of floating point numbers as conceptual intervals of potential values (that get conceptually wider and wider the more you compute) and the actual FP value to be a "random" sample of that interval. For all I know, maybe some other implementations do what you suggest already, but my concern was more general than this specific issue. I think it would be a good idea to mirror a reference implementation that is widely used for scientific computation. Just to make sure that it is accepted. Imagine a team where the old boys cling to Fortran and the young guy wants D, if he can show the old boys that D produce the same results for what they do they are more likely to be impressed. Still, it is in the nature of FP that you should be able to configure and control expressions in order to overcome FP-related shortcomings. Like setting rounding-mode etc. So stuff like this ought to be handled the same way if it isn't standard practice. Not only for this stuff, but also for dealing with overflow/underflow and other "optional" aspects of FP computations.
 I agree, but there is also a lot to be said for not repeating 
 old mistakes, if we deem them to be such.
With templates you probably can find a clean way to throw in a compile-time switch for exception generation and other things that can be configured.
Jan 02 2014
prev sibling parent "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Tuesday, 26 November 2013 at 12:52:30 UTC, John Colvin wrote:
 It seems to me that one really shouldn't special case for 
 absolute values when dealing with floating point.
Why not? std.math and std.mathspecial do it all the time.
Jan 02 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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. Thanks, Andrei
Nov 26 2013
next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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.
Nov 27 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Nov 27, 2013 at 11:29:55PM +0100, Joseph Rushton Wakeling 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.
For the benefit of others: If you already have a Phobos fork on github, forking this repo won't do anything. What you need to do in that case is to add this repo as a remote, then fetch the 'imaginary' branch and check it out, like this: git remote add webdrake https://github.com/WebDrake/phobos.git git fetch webdrake imaginary git checkout -b imaginary webdrake/imaginary Now you can review / edit the code, push to origin (github), and then submit pull requests (make sure to target the WebDrake repo when submitting the pull, since otherwise it will go to Phobos master by default, which is probably not what you want). T -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan
Nov 28 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
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).
Nov 28 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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?
Nov 29 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
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)
Nov 29 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
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
Nov 29 2013
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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
Dec 20 2013
next sibling parent Shammah Chancellor <anonymous coward.com> writes:
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
Dec 26 2013
prev sibling parent reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Friday, 20 December 2013 at 16:26:00 UTC, Joseph Rushton 
Wakeling 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.
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
I'm not 100% convinced that a pure imaginary type is the way to go. You may be interested in reading a previous discussion, where the subject of pure imaginary number support is brought up: http://forum.dlang.org/thread/flsf9u$jf$1 digitalmars.com Let me quote some of the replies in that thread: On Monday, 7 January 2008 at 08:05:48 UTC, Don Clugston wrote:
 I think the argument for pure imaginary types is extremely 
 weak. They are very annoying to work with, because they aren't 
 closed under multiplication. This is a nasty property to have 
 in a built-in type.

 Suppose you're writing a generic function product(T)(T[]) which 
 returns T[0]*T[1]*T[2]*... What's the return type?
 Suppose T is idouble. Then if the number of elements in T is 
 odd, the return type should be idouble, but if it's even, the 
 return type should be double!
 You could promote it to complex with a construction like 
 typeof(1?T*T:T), but that's inefficient, and negates most of 
 the benefits of having a imaginary type.
On Tuesday, 8 January 2008 at 03:13:34 UTC, Bill Baxter wrote:
 The bottom line is that there really is no useful mathematics 
 that can be performed using only imaginary numbers.  If to do 
 anything more than add, subtract, or multiply by a (real!) 
 scalar they become complex.  If you have any imaginary numbers 
 in a numerical code it means you're working in the complex 
 plane.
Jan 01 2014
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Wednesday, 1 January 2014 at 23:32:58 UTC, Lars T. Kyllingstad 
wrote:
 I'm not 100% convinced that a pure imaginary type is the way to 
 go.  You may be interested in reading a previous discussion, 
 where the subject of pure imaginary number support is brought 
 up:

   http://forum.dlang.org/thread/flsf9u$jf$1 digitalmars.com
I have read through that thread already, but thank you for bringing it up -- it raises some issues that deserve an answer. My own thoughts on the matter go something like this: * There are calculations involving "pair of reals" implementations of complex numbers that generate spuriously incorrect results. They're corner cases, but they exist. * A purely imaginary type allows those calculations to be performed correctly. It also allows more precise calculations in general for cases where the real part of a complex number is known to be 0. * The idea of allowing imaginary literals but promoting them to complex when written to a variable sounds attractive but we can't discount the possibility that people will want to pass imaginary literals to functions or otherwise store them in variables, and later use them; if they are promoted to complex, calculations done with them may have lesser precision or even generate the aforementioned spurious results. I don't think simply writing to a variable should cause loss of precision like this. * You can do calculations involving purely real-valued numbers and complex numbers and not run into the same issues, because purely real values are supported. So you should be able to do the same with purely imaginary numbers. * The lack of closure under various operations is annoying but not insurmountable. I should add that as far as I'm concerned what I want is simply to find the best possible way to represent and use purely imaginary numbers in D. I don't mind if, having done that, the code winds up being rejected, as long as the exercise proves useful. Of course, an alternative would be to tweak the internals of Complex so that it can represent "purely real" and "purely imaginary" types precisely. I'm writing from a phone now so it's not really convenient to explain at length, but I'll try to expand on the above in the next days.
Jan 01 2014
parent reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Thursday, 2 January 2014 at 01:17:54 UTC, Joseph Rushton 
Wakeling wrote:
    * There are calculations involving "pair of reals" 
 implementations of complex
      numbers that generate spuriously incorrect results. 
 They're corner cases,
      but they exist.

    * A purely imaginary type allows those calculations to be 
 performed
      correctly. It also allows more precise calculations in 
 general for cases
      where the real part of a complex number is known to be 0.
So we have three choices: 1. We add a dedicated Imaginary type, and leave Complex more or less the way it is. The pros are that it provides a way to represent imaginary numbers "correctly", while keeping Complex simple and performant. The cons are that Complex still gives wrong (or at least somewhat unexpected) results in the aforementioned corner cases, and that we add a new type with extremely limited usability. 2. Special-case Complex for imaginary numbers. The pros are that it solves the problems Imaginary was intended to solve, and we don't need a new type. The cons are that the Complex implementation becomes more complex (haha) and less performant, and that we actually change the semantics of IEEE floating-point "zero" somewhat. 3. Leave std.complex as-is, and make sure people know what the problematic cases are. They all suck. I don't know what is the lesser of three evils here, but I too am starting to lean towards 1. I'm probably going to continue playing devil's advocate, though. ;)
    * You can do calculations involving purely real-valued 
 numbers and complex
      numbers and not run into the same issues, because purely 
 real values are
      supported. So you should be able to do the same with 
 purely imaginary
      numbers.
That argument is fallacious. Imaginary numbers are quite different from real numbers.
 I should add that as far as I'm concerned what I want is simply 
 to find the best possible way to represent and use purely 
 imaginary numbers in D. I don't mind if, having done that, the 
 code winds up being rejected, as long as the exercise proves 
 useful.
I think it's great that you're doing this. :)
Jan 02 2014
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 02/01/14 23:26, Lars T. Kyllingstad wrote:
 2. Special-case Complex for imaginary numbers. The pros are that it solves the
 problems Imaginary was intended to solve, and we don't need a new type. The
cons
 are that the Complex implementation becomes more complex (haha) and less
 performant, and that we actually change the semantics of IEEE floating-point
 "zero" somewhat.
Well, what I was mulling over was a Complex type that consists of two FP values (re and im) and two bools (let's call them hasRe, hasIm). The point of this is that if you assign to Complex from a regular real-valued number, then the value of re gets set, im gets set to zero, hasRe to true, and hasIm to false. So, you have a flag inside that says, "Hey, only worry about your real part." Then you could define an imaginary() helper function that creates a Complex number with re = 0.0, im set to whatever it needs to be, hasRe to false, and hasIm to true. So again, you can benefit from a Complex that _knows_ it's purely imaginary. Moreover, it should be possible to preserve that kind of knowledge under certain operations. e.g. if you multiply two Complex numbers which both have hasRe == false, you can _know_ that you're going to wind up with a number where hasRe == true and hasIm == false. OTOH when you perform certain other operations, you might end up with a zero re or im, but also with hasRe or hasIm to true, which basically reflects your _certainty_ that the real or imaginary part is zero. It might be interesting to try out, and it seems nicer to me than if ()'s based on whether re == 0 or im == 0, but on the other hand it enlarges the size of a Complex type and will result in a performance hit, and will break compatibility with C/C++ Complex types.
 They all suck. I don't know what is the lesser of three evils here, but I too
am
 starting to lean towards 1.  I'm probably going to continue playing devil's
 advocate, though. ;)
Please do. It's fun, and it also helps to improve things. :-)
    * You can do calculations involving purely real-valued numbers and complex
      numbers and not run into the same issues, because purely real values are
      supported. So you should be able to do the same with purely imaginary
      numbers.
That argument is fallacious. Imaginary numbers are quite different from real numbers.
Can you expand on that?
 I think it's great that you're doing this. :)
Thank you! :-)
Jan 02 2014
parent reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Thursday, 2 January 2014 at 23:26:48 UTC, Joseph Rushton 
Wakeling wrote:
 On 02/01/14 23:26, Lars T. Kyllingstad wrote:
   * You can do calculations involving purely real-valued 
 numbers and complex
     numbers and not run into the same issues, because purely 
 real values are
     supported. So you should be able to do the same with 
 purely imaginary
     numbers.
That argument is fallacious. Imaginary numbers are quite different from real numbers.
Can you expand on that?
Mathematically, the real numbers are a ring, whereas the purely imaginary numbers are not. (I've been out of the abstract algebra game for a couple of years now, so please arrest me if I've remembered the terminology wrongly.) What it boils down to is that they are not closed under multiplication, which gives them radically different properties - or lack thereof.
Jan 02 2014
parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 03/01/14 01:04, Lars T. Kyllingstad wrote:
 Mathematically, the real numbers are a ring, whereas the purely imaginary
 numbers are not. (I've been out of the abstract algebra game for a couple of
 years now, so please arrest me if I've remembered the terminology wrongly.)
 What it boils down to is that they are not closed under multiplication, which
 gives them radically different properties - or lack thereof.
I've been out of the abstract algebra game for rather longer :-) but regardless of terminology, I understand what you mean. My point was meant to be somewhat simpler: if you have x * (a + bi) (i.e. real * complex in terms of the computer representation) then, this will come out with higher precision than (x + 0i) * (a + bi) ... because you can avoid unnecessary multiplications by zero and other such things. You can also avoid some nasty nan's that may arise in the latter case. You get to enjoy this extra-precision-and-avoid-nasty-errors because we already have built-in numerical types and std.complex.Complex defines binary operations relative to them as well as to other Complex types. I'm simply suggesting that the same opportunities to avoid those calculation errors should be available when you're dealing with purely-imaginary types. It's an implementation issue AFAICS, not a question of mathematical theory, although like you and Don I find the lack of closure for imaginary op imaginary to be very annoying. (I got round it simply by not defining opOpAssign for operations that could not be assigned back to an Imaginary type.)
Jan 02 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/26/2013 3:22 AM, Joseph Rushton Wakeling wrote:
 (It also leaves std.complex' behaviour incompatible with std::complex and other
 library implementations, though I guess that's less of a concern so long as we
 think what std.complex does is right.)
Making it behave differently than others would be a disaster.
Jan 01 2014
parent "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Wednesday, 1 January 2014 at 23:54:05 UTC, Walter Bright wrote:
 On 11/26/2013 3:22 AM, Joseph Rushton Wakeling wrote:
 (It also leaves std.complex' behaviour incompatible with 
 std::complex and other
 library implementations, though I guess that's less of a 
 concern so long as we
 think what std.complex does is right.)
Making it behave differently than others would be a disaster.
Just as well that I was speaking hypothetically about things that _could_ be done, rather than _should_ be ... :-)
Jan 01 2014
prev sibling parent reply Shammah Chancellor <anonymous coward.com> writes:
On 2013-11-26 01:02:12 +0000, Andrei Alexandrescu said:

 On 11/25/13 10:37 AM, Joseph Rushton Wakeling wrote:
 On 25/11/13 18:51, Andrei Alexandrescu wrote:
 Doesn't sound all that bad to me. After all the built-in complex must
 be doing
 something similar. Of course if a separate imaginary type helps this
 and other
 cases, we should define it.
Well, if you want it I'm happy to write the patch. It's just I'm not sure that what is happening with std.complex is actually wrong if it's to be considered correct that 0 * inf = nan.
If you got the blessing of some complex number expert, that would be great. Andrei
With any luck, I'll be working on my PhD in computational physics using D toward the end of next year. I'll definitely be giving feedback :) As of right now, I have been out of the computational physics field for too long to give good feedback. I can't wait to make a version of the concurrency library that works across machines :D
Nov 26 2013
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 26/11/13 12:52, Shammah Chancellor wrote:
 With any luck, I'll be working on my PhD in computational physics using D
toward
 the end of next year.    I'll definitely be giving feedback :) As of right now,
 I have been out of the computational physics field for too long to give good
 feedback.  I can't wait to make a version of the concurrency library that works
 across machines :D
Sounds very cool. What kind of stuff will you be working on?
Nov 26 2013
parent Shammah Chancellor <anonymous coward.com> writes:
On 2013-11-26 12:55:26 +0000, Joseph Rushton Wakeling said:

 Sounds very cool.  What kind of stuff will you be working on?
Who knows. Haven't even finished my apps yet. The deadline is in a couple weeks :)
Nov 26 2013
prev sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Monday, 25 November 2013 at 08:18:43 UTC, Joseph Rushton 
Wakeling wrote:
 But if you just think of 0 as a number, then

 0 * lim{x --> inf} x
              = lim{x --> inf} (0 * x)
This is where your argument falls apart, as mathematically, you can't do that unless lim{x --> inf} x is well-defined. See also: http://en.wikipedia.org/wiki/Riemann_sphere David
Nov 26 2013
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 26/11/13 17:11, David Nadlinger wrote:
 On Monday, 25 November 2013 at 08:18:43 UTC, Joseph Rushton Wakeling wrote:
 But if you just think of 0 as a number, then

 0 * lim{x --> inf} x
              = lim{x --> inf} (0 * x)
This is where your argument falls apart, as mathematically, you can't do that unless lim{x --> inf} x is well-defined.
I was using a very lazy shorthand there, I'm glad someone thought to call me on it. Can we take it as read that I was basically thinking of a sequence {x_n} such that for every K there is an N such that for n > N, x_n > K ... ? :-) And then you have 0 * lim{n --> inf} x_n = ... etc. The fun stuff must surely arrive when you want to show this kind of stuff in the context of real numbers being defined as equivalence classes of infinite sequences of rationals, à la Cauchy ...
 See also: http://en.wikipedia.org/wiki/Riemann_sphere
I don't recall ever actually studying the Riemann sphere, which really seems to me like a gap in my education :-\
Nov 26 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 26 November 2013 at 16:30:30 UTC, Joseph Rushton 
Wakeling wrote:
 On 26/11/13 17:11, David Nadlinger wrote:
 On Monday, 25 November 2013 at 08:18:43 UTC, Joseph Rushton 
 Wakeling wrote:
 But if you just think of 0 as a number, then

 0 * lim{x --> inf} x
             = lim{x --> inf} (0 * x)
This is where your argument falls apart, as mathematically, you can't do that unless lim{x --> inf} x is well-defined.
I was using a very lazy shorthand there, I'm glad someone thought to call me on it. Can we take it as read that I was basically thinking of a sequence {x_n} such that for every K there is an N such that for n > N, x_n > K ... ? :-) And then you have 0 * lim{n --> inf} x_n = ... etc.
x_n = n actually fulfils that property, and I think most people would understand the limit notation for real numbers exactly the way you intended. But that was not my point. To be able to write "lim{n --> inf} x_n" in a meaningful way (and consequently »pull in« the multiplication), a (or as it turns out, the) limit must exist in the metric space you are working in. If your metric space contains ∞, and it has the property that 0 . ∞ = 0, then your argument is correct. But such a symbol ∞ does not exist in the real numbers. I guess it might help to think back to your first university-level analysis courses, where I'm sure these distinctions were discussed many times in proofs concerning the existence of limits, e.g. integrability of certain functions, …
 See also: http://en.wikipedia.org/wiki/Riemann_sphere
I don't recall ever actually studying the Riemann sphere, which really seems to me like a gap in my education :-\
Well, the reason I bring this up is that what the »right« behavior is all comes down to the definition of your numerical system. IEEE 754 includes infinity as an actual value, contrary to the usual definition of real numbers in mathematics. However, it also distinguishes between +∞ and -∞, so it can't model the Riemann sphere, which is one of the most straightforward ways to perform the extension of the complex plane with a concept infinity in mathematics. David
Nov 26 2013
next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 26/11/13 22:11, David Nadlinger wrote:
 x_n = n actually fulfils that property, and I think most people would
understand
 the limit notation for real numbers exactly the way you intended.

 But that was not my point. To be able to write "lim{n --> inf} x_n" in a
 meaningful way (and consequently »pull in« the multiplication), a (or as it
 turns out, the) limit must exist in the metric space you are working in.

 If your metric space contains ∞, and it has the property that 0 . ∞ = 0,
then
 your argument is correct. But such a symbol ∞ does not exist in the real
numbers.

 I guess it might help to think back to your first university-level analysis
 courses, where I'm sure these distinctions were discussed many times in proofs
 concerning the existence of limits, e.g. integrability of certain functions,
…
Well, it has been 12+ years ... :-P Still, it's very, very annoying when one misplaces fundamental stuff like that. Thank you for reminding me :-) Now I need to dust off my copy of "What is Mathematics?" ...
 Well, the reason I bring this up is that what the »right« behavior is all
comes
 down to the definition of your numerical system.

 IEEE 754 includes infinity as an actual value, contrary to the usual definition
 of real numbers in mathematics. However, it also distinguishes between +∞ and
 -∞, so it can't model the Riemann sphere, which is one of the most
 straightforward ways to perform the extension of the complex plane with a
 concept infinity in mathematics.
I'm sure you've heard that old anecdote of the professor back in the 1950s, or was it the 1920s, who, on hearing a student say "infinity", said: "I won't have bad language in class!" :-)
Nov 27 2013
parent Shammah Chancellor <anonymous coward.com> writes:
On 2013-11-27 09:14:04 +0000, Joseph Rushton Wakeling said:

 I'm sure you've heard that old anecdote of the professor back in the 
 1950s, or was it the 1920s, who, on hearing a student say "infinity", 
 said: "I won't have bad language in class!" :-)
Yes. I think that's part of the reason 0 • inf = NaN in IEEE. The values are taken to be limits of unknown functions. Thus 0 * inf is uncalculable without knowing those functions. There is no such thing as the value infinity.
Nov 27 2013
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jan 01 2014
prev sibling parent Shammah Chancellor <anonymous coward.com> writes:
On 2013-11-24 23:24:18 +0000, Joseph Rushton Wakeling said:

 BTW is it true that IEEE standards define 0 * inf to be nan? It's 
 counter-intuitive mathematically and I can't find a reference to that 
 effect.
I couldn't find a reference either, but that's certainly how it is handled. I doubt there is a bug in so many compilers regarding that. Although, my friend Fred Tydeman makes his living finding these sorts of bugs with compilers: http://www.tybor.com/
Nov 24 2013
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 23/11/13 08:43, Ali Çehreli wrote:
 import std.stdio;
 import std.complex;

 void main()
 {
      writeln(complex(1.0L, -real.infinity) * complex(0.0, 1.0L));
      writeln((1L - ireal.infinity) * 1i);
 }


 The output:

 inf-nani    <-- "incorrect" according to the quoted page
 inf+1i      <-- correct
But, still operating with builtins, writeln((1L - ireal.infinity) * (0 + 1i)); and you get again inf-nani Basically, your nice result with (1L - ireal.infinity) * 1i comes about because in this case, you're not multiplying two complex numbers, but one complex and one imaginary. In the latter case, there's no 0 to multiply by infinity.
Nov 26 2013
prev sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Craig Dillabaugh" <craig.dillabaugh gmail.com> wrote in message 
news:izowcplookyzxrpzmoci forum.dlang.org...
 On Saturday, 23 November 2013 at 04:37:19 UTC, Shammah Chancellor wrote:
 //Hijack

 http://digitalmars.com/d/1.0/cppcomplex.html

 . Consider the formula (1 - infinity*i) * i which should produce 
 (infinity + i). However, if instead the second factor is (0 + i) rather 
 than just i, the result is (infinity + NaN*i), a spurious NaN was 
 generated.
 . A distinct imaginary type preserves the sign of 0, necessary for 
 calculations involving branch cuts.
Is this stuff no longer an issue? -Shammah
I believe D used to have builtin complex types, back in the old days. They have been removed (deprecated?) and replaced by the library type std.complex. At least that is my understanding. Craig
They are not deprecated yet, but it has been 'planned' for a long time. It's one of those things where not deprecating them doesn't hurt anyone, so it isn't high priority.
Nov 23 2013
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Saturday, 23 November 2013 at 08:18:35 UTC, Daniel Murphy 
wrote:
 They are not deprecated yet, but it has been 'planned' for a 
 long time.
 It's one of those things where not deprecating them doesn't 
 hurt anyone, so
 it isn't high priority.
Must say that, whatever the behind-the-scenes of the implementation, it seems a shame to lose the nice z = x + y*i notation. OTOH I guess that could lead to ambiguous code, e.g. int i = 4; complex z = x + y*i; // what does i mean here?
Nov 23 2013
next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> wrote in message 
news:pyjudfnteduztpporndj forum.dlang.org...
 On Saturday, 23 November 2013 at 08:18:35 UTC, Daniel Murphy wrote:
 They are not deprecated yet, but it has been 'planned' for a long time.
 It's one of those things where not deprecating them doesn't hurt anyone, 
 so
 it isn't high priority.
Must say that, whatever the behind-the-scenes of the implementation, it seems a shame to lose the nice z = x + y*i notation. OTOH I guess that could lead to ambiguous code, e.g. int i = 4; complex z = x + y*i; // what does i mean here?
I feel mostly the same way - except - I've never actually used them in my own code, and when I've built test cases for them while fixing other bugs I've found some horrific bugs in dmd. This makes me think that _nobody_ is using them. And if that's true, we might as well get rid of them. eg https://d.puremagic.com/issues/show_bug.cgi?id=7594
Nov 23 2013
parent reply Shammah Chancellor <anonymous coward.com> writes:
On 2013-11-23 14:02:38 +0000, Daniel Murphy said:

 "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> wrote in 
 message news:pyjudfnteduztpporndj forum.dlang.org...
 On Saturday, 23 November 2013 at 08:18:35 UTC, Daniel Murphy wrote:
 They are not deprecated yet, but it has been 'planned' for a long time.
 It's one of those things where not deprecating them doesn't hurt anyone, so
 it isn't high priority.
Must say that, whatever the behind-the-scenes of the implementation, it seems a shame to lose the nice z = x + y*i notation. OTOH I guess that could lead to ambiguous code, e.g. int i = 4; complex z = x + y*i; // what does i mean here?
I feel mostly the same way - except - I've never actually used them in my own code, and when I've built test cases for them while fixing other bugs I've found some horrific bugs in dmd. This makes me think that _nobody_ is using them. And if that's true, we might as well get rid of them. eg https://d.puremagic.com/issues/show_bug.cgi?id=7594
I disagree. I was using them for physics simulations. They are very useful for the computational physics community. Just because most people are still using FORTRAN does not mean they won't switch eventually. -Shammah
Nov 23 2013
parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Saturday, 23 November 2013 at 15:13:22 UTC, Shammah Chancellor 
wrote:
 I disagree.  I was using them for physics simulations.   They 
 are very useful for the computational physics community.   Just 
 because most people are still using FORTRAN does not mean they 
 won't switch eventually.
Would it cause you any particular disadvantage to use the library std.complex rather than the built-in complex type?
Nov 24 2013
parent reply Shammah Chancellor <anonymous coward.com> writes:
On 2013-11-24 15:50:46 +0000, Joseph Rushton Wakeling said:

 On Saturday, 23 November 2013 at 15:13:22 UTC, Shammah Chancellor wrote:
 I disagree.  I was using them for physics simulations.   They are very 
 useful for the computational physics community.   Just because most 
 people are still using FORTRAN does not mean they won't switch 
 eventually.
Would it cause you any particular disadvantage to use the library std.complex rather than the built-in complex type?
It would if the they don't work correctly. There needs to be an Imaginary type and some proper operations between complex and imaginary types. That doesn't seem to be the case currently. I personally think having the built-in type is very helpful. However, I can understand from a language perspective that having "i" around is hard for the parser. Also, the argument "If complex/imaginary is built-in, why not have quaterions also" seems to imply that it should be a library type. -Shammah
Nov 24 2013
parent reply "QAston" <qaston gmail.com> writes:
On Sunday, 24 November 2013 at 17:35:34 UTC, Shammah Chancellor 
wrote:
 On 2013-11-24 15:50:46 +0000, Joseph Rushton Wakeling said:

 On Saturday, 23 November 2013 at 15:13:22 UTC, Shammah 
 Chancellor wrote:
 I disagree.  I was using them for physics simulations.   They 
 are very useful for the computational physics community.   
 Just because most people are still using FORTRAN does not 
 mean they won't switch eventually.
Would it cause you any particular disadvantage to use the library std.complex rather than the built-in complex type?
It would if the they don't work correctly. There needs to be an Imaginary type and some proper operations between complex and imaginary types. That doesn't seem to be the case currently. I personally think having the built-in type is very helpful. However, I can understand from a language perspective that having "i" around is hard for the parser. Also, the argument "If complex/imaginary is built-in, why not have quaterions also" seems to imply that it should be a library type. -Shammah
You can have im!5.0 in a library type, to me it sounds good enough.
Jan 02 2014
parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 02/01/14 22:08, QAston wrote:
 You can have im!5.0 in a library type, to me it sounds good enough.
As currently written, it'll be imaginary(5.0) or Imaginary!double(5.0) -- sorry for the verbosity, but "im" seems to me too likely to wind up being used as a variable name ... ;-)
Jan 02 2014
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 23/11/13 10:42, Joseph Rushton Wakeling wrote:
 Must say that, whatever the behind-the-scenes of the implementation, it seems a
 shame to lose the nice z = x + y*i notation.

 OTOH I guess that could lead to ambiguous code, e.g.

      int i = 4;
      complex z = x + y*i;     // what does i mean here?
I was wrong about this -- you have to write complex z = x + y * 1i ... which is unambiguous though I guess potentially still prone to typos :-)
Nov 26 2013
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Shammah Chancellor:
 //Hijack
More hijack, see also: http://forum.dlang.org/thread/lxuhrynxujrujoksrvdi forum.dlang.org Bye, bearophile
Nov 23 2013
prev sibling parent "Lars T. Kyllingstad" <public kyllingen.net> writes:
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
Jan 01 2014