n 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
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 th
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
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 langu
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 th
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
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 y
erations (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
inary 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 fro
On 02/01/2014 21:10, Joseph Rushton Wakeling wrote:
On Thursday, 2 January 2014 at 20:23:40 UTC, Stewart Gordon wrote:
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
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 th
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 ... ;-)
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 pr
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 re
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 correct
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'
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 tr
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 rel
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 impor
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 tha
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 numbe
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 librari
On 01/01/2014 23:12, Lars T. Kyllingstad wrote:
/* 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 sen
On 01/01/2014 19:55, Joseph Rushton Wakeling wrote:
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 imple
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/biotro
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:
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
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 m
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.
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
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 Compl
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/thre
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
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 t
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
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 m
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
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
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 w
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. Computa
On 19/11/2013 02:03, Andrei Alexandrescu wrote:> On 11/18/13 5:44 PM,
Craig Dillabaugh wrote:
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
On 2013-12-20 16:25:53 +, 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 m
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/
On 29 November 2013 08:57, Joseph Rushton Wakeling
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
On 29 November 2013 11:50, Iain Buclaw wrote:
> On 29 November 2013 08:57, Joseph Rushton Wakeling
> 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
On 29/11/13 08:50, Iain Buclaw wrote:
That repo doesn't seem to exist (must by my imagination).
It's just the branch "imaginary" in my regular Phobos repo (I always use feature
branches for new stuff).
The link works for me, what goes wrong for you?
On 27 November 2013 22:29, 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
>>
>
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 ty
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:
http
On 2013-11-27 09:14:04 +, 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 • in
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 »
On 2013-11-26 12:55:26 +, 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 :)
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 *
On 11/26/13 7:13 AM, Dmitry Olshansky wrote:
26-Nov-2013 09:06, Daniel Murphy пишет:
"Dmitry Olshansky" 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
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 d
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
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-def
26-Nov-2013 09:06, Daniel Murphy пишет:
"Dmitry Olshansky" 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 +
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.
th 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:
Co
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.
ur 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
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 c
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 co
;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
On 19 November 2013 02:03, 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
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 h
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
"Dmitry Olshansky" 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.
l, 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
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.
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.r
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
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 unpl
On 2013-11-24 23:24:18 +, 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 th
On 11/24/13 10:56 AM, Shammah Chancellor wrote:
On 2013-11-24 18:37:51 +, 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
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 an
On 2013-11-24 18:37:51 +, 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
On 11/24/13 10:03 AM, Shammah Chancellor wrote:
On 2013-11-24 18:00:45 +, 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
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
24-Nov-2013 22:03, Shammah Chancellor пишет:
On 2013-11-24 18:00:45 +, 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
On 2013-11-24 18:00:45 +, 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
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<-- "i
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
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 betwe
Would it cause you any particular disadvantage to use the library
std.complex rather than the built-in complex type?
On 2013-11-23 14:02:38 +, Daniel Murphy said:
"Joseph Rushton Wakeling" wrote in
message news:pyjudfnteduztppor...@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 tho
Shammah Chancellor:
//Hijack
More hijack, see also:
http://forum.dlang.org/thread/lxuhrynxujrujoksr...@forum.dlang.org
Bye,
bearophile
"Joseph Rushton Wakeling" wrote in message
news:pyjudfnteduztppor...@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 h
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
cessary 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
&
volving 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.
>
&g
(deprecated?) and replaced by the
library type std.complex.
At least that is my understanding.
Craig
//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 ty
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
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
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
96 matches
Mail list logo
