On 11/12/13 13:44, Simen Kjærås wrote:
> I've tried to figure out good ways to add some sorely-needed implicit
> conversions to the language, but I'm sure there are details that need to be
> ironed out. In other words - destroy!

Since you brought up std.complex: some of the issues here are subtle.  For example, it's appropriate to allow implicit conversion from numerical => Complex (although this can be done fairly readily by just calling complex(x) where x is a numerical type); it's also appropriate to allow implicit conversion from Imaginary => Complex; but it'd be wrong to allow implicit conversion from numerical => Imaginary.

Conversely, I'm not certain whether it'd be appropriate to allow implicit conversion Complex => numerical or Complex => Imaginary, even if the imaginary or real parts respectively were zero.

On 2013-12-11 22:00, Joseph Rushton Wakeling wrote:
> On 11/12/13 13:44, Simen Kjærås wrote:
>> I've tried to figure out good ways to add some sorely-needed implicit
>> conversions to the language, but I'm sure there are details that need
>> to be
>> ironed out. In other words - destroy!
>
> Since you brought up std.complex: some of the issues here are subtle.
> For example, it's appropriate to allow implicit conversion from
> numerical => Complex (although this can be done fairly readily by just
> calling complex(x) where x is a numerical type); it's also appropriate
> to allow implicit conversion from Imaginary => Complex; but it'd be
> wrong to allow implicit conversion from numerical => Imaginary.

To be honest, I don't find that subtle - it's basic dimensional analysis. :p


> Conversely, I'm not certain whether it'd be appropriate to allow
> implicit conversion Complex => numerical or Complex => Imaginary, even
> if the imaginary or real parts respectively were zero.

I'm certain it would not. At least in my mind, that's almost as bad as allowing implicit conversion from string to integer, based on the confused notion that it *might* be valid.

--
  Simen

On Wednesday, 11 December 2013 at 21:00:19 UTC, Joseph Rushton Wakeling wrote:
> On 11/12/13 13:44, Simen Kjærås wrote:
>> I've tried to figure out good ways to add some sorely-needed implicit
>> conversions to the language, but I'm sure there are details that need to be
>> ironed out. In other words - destroy!
>
> Since you brought up std.complex: some of the issues here are subtle.  For example, it's appropriate to allow implicit conversion from numerical => Complex (although this can be done fairly readily by just calling complex(x) where x is a numerical type); it's also appropriate to allow implicit conversion from Imaginary => Complex; but it'd be wrong to allow implicit conversion from numerical => Imaginary.
>
> Conversely, I'm not certain whether it'd be appropriate to allow implicit conversion Complex => numerical or Complex => Imaginary, even if the imaginary or real parts respectively were zero.

I don't think Imaginary should exist at all. Mathematically, it's nonsense.
It's exactly like defining a NegativeInteger. It has horrible properties, such as, it's not closed under multiplication!

I don't think there are many applications for pure imaginary numbers, I tried to come up with one but failed. Kahan only provides one example in his paper, and it's contrived. It eliminates one subtlety but introduces far more. In practice it is always far better to just operate directly on the real and imaginary parts.

On 12/12/13 15:31, Don wrote:
> I don't think Imaginary should exist at all. Mathematically, it's nonsense.
> It's exactly like defining a NegativeInteger. It has horrible properties, such
> as, it's not closed under multiplication!
>
> I don't think there are many applications for pure imaginary numbers, I tried to
> come up with one but failed. Kahan only provides one example in his paper, and
> it's contrived. It eliminates one subtlety but introduces far more. In practice
> it is always far better to just operate directly on the real and imaginary parts.

Well, there have been discussions and requests for it recently because of the errors that can arise when you take 2 numbers, one with a purely imaginary part, and multiply -- which arise out of the fact that then you have to contend with a 0 * something calculation.  AFAICS there are also some benefits of precision that one can gain for some calculations.

On 12/12/13 00:08, Simen Kjærås wrote:
> To be honest, I don't find that subtle - it's basic dimensional analysis. :p

The maths is simple, the subtleties come with the social side of managing a codebase and the potential for someone to want some feature because it serves their use-case, and a reviewer accidentally missing that it might open a horrible can of worms somewhere else ... :-)

> I'm certain it would not. At least in my mind, that's almost as bad as allowing
> implicit conversion from string to integer, based on the confused notion that it
> *might* be valid.

TBH I agree.  I just didn't want to assume that there wasn't some valid case someone else might make, that I hadn't considered.

On 12/12/13 6:31 AM, Don wrote:
> On Wednesday, 11 December 2013 at 21:00:19 UTC, Joseph Rushton Wakeling
> wrote:
>> On 11/12/13 13:44, Simen Kjærås wrote:
>>> I've tried to figure out good ways to add some sorely-needed implicit
>>> conversions to the language, but I'm sure there are details that need
>>> to be
>>> ironed out. In other words - destroy!
>>
>> Since you brought up std.complex: some of the issues here are subtle.
>> For example, it's appropriate to allow implicit conversion from
>> numerical => Complex (although this can be done fairly readily by just
>> calling complex(x) where x is a numerical type); it's also appropriate
>> to allow implicit conversion from Imaginary => Complex; but it'd be
>> wrong to allow implicit conversion from numerical => Imaginary.
>>
>> Conversely, I'm not certain whether it'd be appropriate to allow
>> implicit conversion Complex => numerical or Complex => Imaginary, even
>> if the imaginary or real parts respectively were zero.
>
> I don't think Imaginary should exist at all. Mathematically, it's nonsense.
> It's exactly like defining a NegativeInteger. It has horrible
> properties, such as, it's not closed under multiplication!
>
> I don't think there are many applications for pure imaginary numbers, I
> tried to come up with one but failed. Kahan only provides one example in
> his paper, and it's contrived. It eliminates one subtlety but introduces
> far more. In practice it is always far better to just operate directly
> on the real and imaginary parts.

Great. I'm all for keeping it simple :o). Can you fix Kahan's example (or class of examples) with a glorious hack and call it a day?

Andrei

On 12/12/13 17:04, Andrei Alexandrescu wrote:
> Great. I'm all for keeping it simple :o). Can you fix Kahan's example (or class
> of examples) with a glorious hack and call it a day?

FWIW: I intend to land the Imaginary type code I've been working on, but I'll have no problem if it gets rejected out of hand; it's been a worthwhile learning exercise.  OTOH, if I can be pointed to Kahan's example, I can also take a look at workarounds for that instead.

On 12/12/13 8:09 AM, Joseph Rushton Wakeling wrote:
> On 12/12/13 17:04, Andrei Alexandrescu wrote:
>> Great. I'm all for keeping it simple :o). Can you fix Kahan's example
>> (or class
>> of examples) with a glorious hack and call it a day?
>
> FWIW: I intend to land the Imaginary type code I've been working on, but
> I'll have no problem if it gets rejected out of hand; it's been a
> worthwhile learning exercise.  OTOH, if I can be pointed to Kahan's
> example, I can also take a look at workarounds for that instead.

A few searches returned this:

http://www.eecs.berkeley.edu/Pubs/TechRpts/1992/6127.html

The PDF is a scan...


Andrei

On 12/12/13 18:59, Andrei Alexandrescu wrote:
> A few searches returned this:
>
> http://www.eecs.berkeley.edu/Pubs/TechRpts/1992/6127.html

Thanks! :-)