www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why is complex being deprecated again?

reply "Mehrdad" <wfunction hotmail.com> writes:
Why is complex being phased out?
What happened to all this? http://dlang.org/cppcomplex.html
Apr 14 2012
next sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
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.
Apr 14 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, April 15, 2012 05:50:33 Kapps wrote:

 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.


It was probably the same reasoning that lead to moving the AA implementation 
into druntime, but I don't remember any specifics.

- Jonathan M Davis
Apr 14 2012
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 15/04/2012 04:56, Jonathan M Davis wrote:
<snip>

 It was probably the same reasoning that lead to moving the AA implementation
 into druntime, but I don't remember any specifics.


No.  The AA implementation was moved into druntime because that's where it
belongs.  Under 
D1, stuff like that is in std.internal.  Under D2, code along those lines has
been moved 
into druntime.  The basic idea is that a D compiler will not generate calls to
code in 
Phobos, and druntime will call code only within itself.  This also lessens the
effect of 
the Phobos/Tango schism.

Stewart.
Apr 15 2012
prev sibling parent "Mehrdad" <wfunction hotmail.com> writes:
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.
Apr 15 2012
prev sibling next sibling parent Caligo <iteronvexor gmail.com> writes:
On Sat, Apr 14, 2012 at 10:10 PM, Mehrdad <wfunction hotmail.com> wrote:

 Why is complex being phased out?
 What happened to all this? http://dlang.org/cppcomplex.html


Where does it say it's being phased out?
Apr 14 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, April 14, 2012 22:27:19 Caligo wrote:

 On Sat, Apr 14, 2012 at 10:10 PM, Mehrdad <wfunction hotmail.com> wrote:

 Why is complex being phased out?
 What happened to all this? http://dlang.org/cppcomplex.html


 
 Where does it say it's being phased out?


It says so here: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel

It's also supposed to say at dlang.org, but the page for it isn't being 
generated properly at the moment:

http://d.puremagic.com/issues/show_bug.cgi?id=7875
Apr 14 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/14/12 10:54 PM, Jonathan M Davis wrote:

 On Saturday, April 14, 2012 22:27:19 Caligo wrote:

 On Sat, Apr 14, 2012 at 10:10 PM, Mehrdad<wfunction hotmail.com>  wrote:

 Why is complex being phased out?
 What happened to all this? http://dlang.org/cppcomplex.html


 Where does it say it's being phased out?


 It says so here: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel

 It's also supposed to say at dlang.org, but the page for it isn't being
 generated properly at the moment:

 http://d.puremagic.com/issues/show_bug.cgi?id=7875


I just submitted a fix.

Andrei
Apr 14 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/14/12 10:10 PM, Mehrdad wrote:

 Why is complex being phased out?
 What happened to all this? http://dlang.org/cppcomplex.html


I don't think that page makes a compelling argument, but I'm not an 
expert. If Walter and Don agree, I'd remove the page.

Andrei
Apr 14 2012
parent reply Don Clugston <dac nospam.com> writes:
On 15/04/12 06:20, Andrei Alexandrescu wrote:

 On 4/14/12 10:10 PM, Mehrdad wrote:

 Why is complex being phased out?
 What happened to all this? http://dlang.org/cppcomplex.html


 I don't think that page makes a compelling argument, but I'm not an
 expert. If Walter and Don agree, I'd remove the page.

 Andrei



I agree, I think that page should be killed.

The efficiency argument is valid but reduces to this: The complier 
*MUST* be able to generate equally good from a library type, as from a 
built-in language type.
Once we've reached that point, we can remove the built-in type.

The correctness issue is a good argument for implementing complex 
functions correctly (basically, you should do your branch cuts on the 
negative real axis, whenever possible). But to go from there to 
requiring that the language has a pure imaginary type is not convincing.

We don't have a 'negint' type for negative integers, why have a pure 
imaginary type?
Apr 16 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/16/12 4:21 AM, Don Clugston wrote:

 On 15/04/12 06:20, Andrei Alexandrescu wrote:

 On 4/14/12 10:10 PM, Mehrdad wrote:

 Why is complex being phased out?
 What happened to all this? http://dlang.org/cppcomplex.html


 I don't think that page makes a compelling argument, but I'm not an
 expert. If Walter and Don agree, I'd remove the page.

 Andrei



 I agree, I think that page should be killed.


Done.


Thanks,

Andrei
Apr 16 2012
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Apr 15 2012
next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
On 15/04/12 14:29, Stewart Gordon wrote:

 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).


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
Apr 15 2012
next sibling parent reply Caligo <iteronvexor gmail.com> writes:
On Sun, Apr 15, 2012 at 4:09 PM, Lars T. Kyllingstad
<public kyllingen.net> wrote:

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

 -Lars


How about Quaternions?
Apr 15 2012
parent reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
On 15/04/12 23:37, Caligo wrote:

 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?


If such were to be added, I think it would be better to put them in a 
separate std.quaternion module.

-Lars
Apr 15 2012
parent Somedude <lovelydear mailmetrash.com> writes:
Le 16/04/2012 08:09, Lars T. Kyllingstad a écrit :

 On 15/04/12 23:37, Caligo wrote:

 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?


 
 If such were to be added, I think it would be better to put them in a
 separate std.quaternion module.
 
 -Lars


Or rather std.math.quaternion
Apr 16 2012
prev sibling next sibling parent reply "Tove" <tove fransson.se> writes:
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
Apr 15 2012
parent "Lars T. Kyllingstad" <public kyllingen.net> writes:
On 15/04/12 23:37, Tove wrote:

 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


See my reply to Stewart.

-Lars
Apr 15 2012
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Apr 15 2012
parent reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
On 15/04/12 23:56, Stewart Gordon wrote:

 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?


For any standard type (built-in or library) to be useful, it has to 
actually be used for something.  And in all my years of using D, I have 
never seen a *single* real-world use of the pure imaginary types.

The reason the imaginaries are so seldomly used is precisely because 
there are so few things you can do with them.  Basically, if you do 
anything beyond addition and subtraction, and multiplication with a real 
number, you are back in the complex plane.  And if those operations are 
all you need, the real line is just as good as the imaginary line, and 
you might as well fake it with a real floating-point type.

Yes, complex and imaginary numbers have some quirks and subtleties that 
need to be taken into consideration, but I see this as an implementation 
issue with the complex type, and not a justification for the existence a 
pure imaginary type.

All that said, however, if anyone can demonstrate that the pure 
imaginary types are in fact used in a substantial body of real-world 
code, I will be happy to change my stance on the above.

Now, to address the rationale for pure imaginary types on 
http://dlang.org/cppcomplex.html.

Firstly, in light of what I've said above (and given that I am not wrong 
<g>), the efficiency issue would appear moot.  That leaves the semantic 
issues.  The quote by prof. Kahan mentions that the identities 
sqrt(conj(z))==conj(sqrt(z)) and log(conj(z))==conj(log(z)) should hold 
even when z is a negative real number.  IIRC, f(conj(z))==conj(f(z)) 
holds when f is analytic, but both sqrt and log (conventionally) have 
branch cuts along the negative real axis.

Case in point:  Neither of these identities hold in Mathematica, which 
is considered the state of the art in mathematical software:

     Conjugate[Log[-1]]   evaluates to   -I Pi
     Log[Conjugate[-1]]   evaluates to    I Pi
     Conjugate[Sqrt[-1]]  evaluates to   -I
     Sqrt[Conjugate[-1]]  evaluates to    I

The page also mentions some identity involving infinities which is 
supposed to hold.  This is not obviously true.  An IEEE infinity has 
very little to do with mathematical infinity, it is just a special value 
which means either "this number is too large to be represented by the 
given number of bits", or "this is a result of a divide by positive 
zero".  (The signedness of zero is another quirk of IEEE floats. 
Basically, -0.0 means "a negative number which is arbitrarily close to 
zero", and dividing by it yields an arbitrarily large negative number, 
i.e. -double.infinity.  Mathematically, something/0 makes no sense at 
all.  Personally, I think IEEE made a mistake in defining FP numbers in 
this way.)

It is true that the real line can be extended with elements called plus 
and minus infinity (affinely extended real line, see 
https://en.wikipedia.org/wiki/Extended_real_number), and the IEEE floats 
can be said to approximate this system, but this does not generalise 
directly to complex numbers.  The extended complex plane (see 
https://en.wikipedia.org/wiki/Riemann_sphere) only has one "infinity".

How should the IEEE system be extended to the complex plane, anyway?  If 
we look at the problem in terms of the cartesian representation, we may 
want four infinities, namely:

     infinity + i * infinity
    -infinity + i * infinity
     infinity - i * infinity
    -infinity - i * infinity

If, on the other hand, we take a polar view of things, there are MANY 
possibilies:

     infinity * exp(i * r)  // where r is any real number

Now, we may invent our own rules for operations with complex numbers 
involving infinities, if nothing else for predictability in 
calculations.  (And maybe such rules are well established already?)  But 
it does not justify the existence of a pure imaginary type.

-Lars
Apr 15 2012
next sibling parent "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Monday, 16 April 2012 at 06:06:12 UTC, Lars T. Kyllingstad 
wrote:

 How should the IEEE system be extended to the complex plane, 
 anyway?  If we look at the problem in terms of the cartesian 
 representation, we may want four infinities, namely:

     infinity + i * infinity
    -infinity + i * infinity
     infinity - i * infinity
    -infinity - i * infinity


Sorry, that would be eight.  I forgot

      infinity
     -infinity
      i * infinity
     -i * infinity

which seems to be what the comparison page calls for.

-Lars
Apr 16 2012
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 16/04/2012 07:06, Lars T. Kyllingstad wrote:
<snip>

 For any standard type (built-in or library) to be useful, it has to actually
be used for
 something.


You mean someone has to use it in order to prove that it's usable and therefore
useful? 
Well, if a feature isn't usable, it's probably due to something wrong with its
design. 
And in many cases it's a reason to rethink the design, rather than throw the
feature out 
of the window.


 And in all my years of using D, I have never seen a *single* real-world use of
 the pure imaginary types.


How many of those years you spent "using" D did you spend looking at other
people's 
real-world applications written in it?

Of these, how many have a focus on number crunching?

And of these, how many use complex numbers?

It's bound to be a rarely used feature.  But "nobody's using it" is a prime
example of a 
self-fulfilling prophecy if it leads to the feature's removal.

Do you feel the SETI Institute should have given up years ago?


 The reason the imaginaries are so seldomly used is precisely because there are
so few
 things you can do with them. Basically, if you do anything beyond addition and
 subtraction, and multiplication with a real number, you are back in the
complex plane. And
 if those operations are all you need, the real line is just as good as the
imaginary line,
 and you might as well fake it with a real floating-point type.


This doesn't cover the case of multiplying a complex number by an imaginary
number.  In 
the absence of imaginary types, one would have to use complex(-z.im * k, z.re *
k), just 
because z * complex(0, k) isn't guaranteed to produce the correct result. 
Seems a bit 
silly.  Or have you another suggestion for dealing with this?

<snip>

 It is true that the real line can be extended with elements called plus and
minus infinity
 (affinely extended real line, see
https://en.wikipedia.org/wiki/Extended_real_number), and
 the IEEE floats can be said to approximate this system, but this does not
generalise
 directly to complex numbers. The extended complex plane (see
 https://en.wikipedia.org/wiki/Riemann_sphere) only has one "infinity".


<snip>

But the Riemann sphere is only one of the various possible extended complex
planes.  You 
could just as well use the polar circle of infinities, the cartesian square of
infinities, 
or the real projective plane model (by which -∞ = ∞, but ∞i, ∞(2+i),
etc. are distinct).

Stewart.
Apr 16 2012
parent reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Monday, 16 April 2012 at 11:27:29 UTC, Stewart Gordon wrote:

 On 16/04/2012 07:06, Lars T. Kyllingstad wrote:
 <snip>

 For any standard type (built-in or library) to be useful, it 
 has to actually be used for
 something.


 You mean someone has to use it in order to prove that it's 
 usable and therefore useful? Well, if a feature isn't usable, 
 it's probably due to something wrong with its design. And in 
 many cases it's a reason to rethink the design, rather than 
 throw the feature out of the window.


 And in all my years of using D, I have never seen a *single* 
 real-world use of
 the pure imaginary types.


 How many of those years you spent "using" D did you spend 
 looking at other people's real-world applications written in it?

 Of these, how many have a focus on number crunching?

 And of these, how many use complex numbers?


This is why I said: "[...] if anyone can demonstrate that the 
pure imaginary types are in fact used in a substantial body of 
real-world code, I will be happy to change my stance [...]"



 It's bound to be a rarely used feature.  But "nobody's using 
 it" is a prime example of a self-fulfilling prophecy if it 
 leads to the feature's removal.


I'm not saying it is *never* useful.  I'm saying I don't think 
it's useful *enough* to warrant inclusion in the standard library.



 Do you feel the SETI Institute should have given up years ago?


I don't really see the similarity between SETI and Phobos.



 The reason the imaginaries are so seldomly used is precisely 
 because there are so few
 things you can do with them. Basically, if you do anything 
 beyond addition and
 subtraction, and multiplication with a real number, you are 
 back in the complex plane. And
 if those operations are all you need, the real line is just as 
 good as the imaginary line,
 and you might as well fake it with a real floating-point type.


 This doesn't cover the case of multiplying a complex number by 
 an imaginary number.  In the absence of imaginary types, one 
 would have to use complex(-z.im * k, z.re * k), just because z 
 * complex(0, k) isn't guaranteed to produce the correct result.
  Seems a bit silly.  Or have you another suggestion for dealing 
 with this?


Yes:  Define Complex!T so it produces the desired result in each 
case.



 <snip>

 It is true that the real line can be extended with elements 
 called plus and minus infinity
 (affinely extended real line, see 
 https://en.wikipedia.org/wiki/Extended_real_number), and
 the IEEE floats can be said to approximate this system, but 
 this does not generalise
 directly to complex numbers. The extended complex plane (see
 https://en.wikipedia.org/wiki/Riemann_sphere) only has one 
 "infinity".


 <snip>

 But the Riemann sphere is only one of the various possible 
 extended complex planes.  You could just as well use the polar 
 circle of infinities, the cartesian square of infinities, or 
 the real projective plane model (by which -∞ = ∞, but ∞i, 
 ∞(2+i), etc. are distinct).


My point exactly.

-Lars
Apr 16 2012
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 16/04/2012 12:42, Lars T. Kyllingstad wrote:
<snip>

 Do you feel the SETI Institute should have given up years ago?


 I don't really see the similarity between SETI and Phobos.


They've been working for decades in the hope of finding aliens.  In the same
way, 
imaginary types have been put into D in the hope that they would be useful.  To
leap to 
the conclusion that they aren't useful, just because they haven't been put to
any real use 
_yet_, would be like SETI leaping to the conclusion that aliens don't exist and
therefore 
abandoning the project.

<snip>

 This doesn't cover the case of multiplying a complex number by an imaginary
number. In
 the absence of imaginary types, one would have to use complex(-z.im * k, z.re
* k), just
 because z * complex(0, k) isn't guaranteed to produce the correct result.
 Seems a bit silly. Or have you another suggestion for dealing with this?


 Yes: Define Complex!T so it produces the desired result in each case.


<snip>

You mean define complex multiplication and division with a special case so
that, when ±0 
occurs as the real part of a number, it just pretends there's no real part at
all?  I can 
see this slowing down almost any program that does complex arithmetic....

Stewart.
Apr 16 2012
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Apr 15 2012
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Apr 15 2012
parent "bearophile" <bearophileHUGS lycos.com> writes:
Stewart Gordon:


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


That module should be named core.intrinsics.

Bye,
bearophile
Apr 15 2012
prev sibling next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
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
Apr 15 2012
prev sibling parent "Lars T. Kyllingstad" <public kyllingen.net> writes:
On 16/04/12 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.


You're right, expi() should be added.  I remember that being on my to-do 
list, but I don't know why I skipped it.

-Lars
Apr 15 2012
prev sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
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.
Apr 15 2012
next sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"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)
Apr 15 2012
prev sibling parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
On 16.04.2012 05:22, Mehrdad wrote:

 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?


Not problems, but serious eye sores: Personally, I am really happy that 
"ireal" and "creal" are going to drop out of the language specs. Now D 
finally has the chance of being taken seriously by mathematicians...

(Anyone, who does not get it: imagine a language that calls floating 
point values "fint" because they are "fractional integers". The same 
language would probably also have the keywords "cvar" for "constant 
variable" and "ntrue" for "not true"... :-)  )
Apr 17 2012
parent "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Tuesday, 17 April 2012 at 18:46:13 UTC, Norbert Nemec wrote:

 On 16.04.2012 05:22, Mehrdad wrote:

 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?


 Not problems, but serious eye sores: Personally, I am really 
 happy that "ireal" and "creal" are going to drop out of the 
 language specs. Now D finally has the chance of being taken 
 seriously by mathematicians...

 (Anyone, who does not get it: imagine a language that calls 
 floating point values "fint" because they are "fractional 
 integers". The same language would probably also have the 
 keywords "cvar" for "constant variable" and "ntrue" for "not 
 true"... :-)  )


Hear, hear! These names have always made me me cringe. (Similar, 
though not nearly as annoying, is the use of "enum" to declare 
manifest constants.)

However, I suspect that when the builtins get removed, aliases 
will be introduced in their place in std.complex.

-Lars
Apr 17 2012