On Sun, Apr 15, 2012 at 4:09 PM, Lars T. Kyllingstad <public@kyllingen.net> wrote:
> If there is anything missing from the module, I will be
> happy to add it.
>
> -Lars

How about Quaternions?

On Sunday, 15 April 2012 at 21:09:13 UTC, Lars T. Kyllingstad wrote:
>
> I absolutely do not think it does.  There is nothing you can do with a pure imaginary type that you cannot do with a complex type. Furthermore, the imaginary numbers have the unfortunate property of not being closed under multiplication and division, which is troublesome for generic code:
>
>   ireal x;
>   x *= x; // boom
>
> It seems nobody noticed, but I did in fact rewrite all of std.complex two years ago (almost to the day) in preparation for the deprecation of the built-in types.  If there is anything missing from the module, I will be happy to add it.
>
> -Lars

The quote on the 'Semantics' section has a counter example...
http://dlang.org/cppcomplex.html

On 15/04/2012 22:09, Lars T. Kyllingstad wrote:
> On 15/04/12 14:29, Stewart Gordon wrote:
<snip>
>> My impression was that the plan is to deprecate it once the stuff in
>> std.complex is complete. std.complex has clearly grown since that
>> discussion, but it still needs a pure imaginary type (and I don't know
>> what else at the moment).
>
> I absolutely do not think it does. There is nothing you can do with a pure imaginary type
> that you cannot do with a complex type.
<snip>

What proof have you of this - and in particular, that the rationale for pure imaginary types on the comparison page is wrong?

And apparently C99 has pure imaginary types to interface....
http://digitalmars.com/d/1.0/interfaceToC.html
http://www.cprogrammingreference.com/Tutorials/Basic_Tutorials/Ckeywordsindiviusual/z_Imaginary.php

(At the moment, in the D2 docs the complex/imaginary types are totally absent from that page....)

Stewart.

Lars T. Kyllingstad:

> If there is anything missing from the module, I will be happy to add it.

You have seen std.math.expi, that returns a creal using the instructions sincos plus a registers swap (so it returns complex(cos,sin)). Maybe it's worth adding to Phobos a fully inlinable core.bitop.sincos intrinsic that performs just the sincos.

Bye,
bearophile

On 15/04/2012 23:31, bearophile wrote:
<snip>
> You have seen std.math.expi, that returns a creal using the instructions sincos plus a
> registers swap (so it returns complex(cos,sin)). Maybe it's worth adding to Phobos a fully
> inlinable core.bitop.sincos intrinsic that performs just the sincos.

I'd never imagined that x86 CPUs had such an instruction built in, but I can begin to imagine why.

But in what way are trig functions bit-level operations?

Stewart.

Stewart Gordon:

> But in what way are trig functions bit-level operations?

That module should be named core.intrinsics.

Bye,
bearophile

On 16-04-2012 00:31, bearophile wrote:
> Lars T. Kyllingstad:
>
>> If there is anything missing from the module, I will be happy to add it.
>
> You have seen std.math.expi, that returns a creal using the instructions
> sincos plus a registers swap (so it returns complex(cos,sin)). Maybe
> it's worth adding to Phobos a fully inlinable core.bitop.sincos
> intrinsic that performs just the sincos.
>
> Bye,
> bearophile

I assume you meant druntime? I think we really need to isolate these intrinsic 'hacks' in the runtime. There should be *no* magic surrounding Phobos in an ideal world - it should just be a plain library.

-- 
- Alex

So we're removing it to reduce the number of keywords? ...Why?
Is the keyword-ness of "cdouble" and "ifloat", etc. causing problems for people?


"Stewart Gordon"  wrote in message news:jmeevc$o3m$1@digitalmars.com...

On 15/04/2012 04:10, Mehrdad wrote:
> Why is complex being phased out?
> What happened to all this? http://dlang.org/cppcomplex.html

There was a brief discussion about it back in 2008

http://www.digitalmars.com/d/archives/digitalmars/D/Replacing_built-in_complex_What_s_this_about_81214.html

My impression was that the plan is to deprecate it once the stuff in std.complex is
complete.  std.complex has clearly grown since that discussion, but it still needs a pure
imaginary type (and I don't know what else at the moment).

From what I gathered, the reason is that it's an unnecessary complexity (pardon the pun)
in the language that relatively few programmers are going to use.  The only thing it
really gains by being built in is complex/imaginary literals.  Even a library complex
constructor doesn't need to be as cumbersome as the C++ example code on the comparison page.

Though it does seem that complex numbers, quite ironically, aren't really that complex a
feature....

Stewart. 

Thanks but that just repeated my question...

"Kapps"  wrote in message news:wedxqokomlaoagkssupc@forum.dlang.org... 

On Sunday, 15 April 2012 at 03:10:25 UTC, Mehrdad wrote:
> Why is complex being phased out?
> What happened to all this? http://dlang.org/cppcomplex.html

It's being replaced with a library implementation of it. I doubt it will be deprecated before the library implementation is ready.

"Mehrdad" <wfunction@hotmail.com> wrote in message news:jmg3ak$147c$1@digitalmars.com...
> So we're removing it to reduce the number of keywords? ...Why?
> Is the keyword-ness of "cdouble" and "ifloat", etc. causing problems for
> people?
>
>

No.  Complex types are special-cased in a lot of places in the dmd frontend, and considering the number of backend bugs I've found, nobody is using them with the dmd backend anyway. (especially not on x64)