On Thursday, 19 September 2019 at 11:16:12 UTC, Simen Kjærås
wrote:
Might I ask what specifically you're working on?
Of course. It's about issue 15881 (and 15763), namely approxEqual
not always doing, what people think it should do. (As a side
note: I stumbled over this, when I wanted to file
r to put this in std/complex.d
anyway, but then code duplication would be necessary).
You could perfectly well place MergeOverloads inside whatever
function you make, thus not polluting std.math:
float abs(float f) {
return f < 0 ? -f : f;
}
unittest {
import std.complex : complex, c
On Thursday, 19 September 2019 at 07:26:17 UTC, Simen Kjærås
wrote:
That does indeed fail to compile, and there's no easy way to
introduce the module-level abs() function to the scope. Again
though, MergeOverloads to the rescue:
I'm not sure, if MergeOverloads will be accepted into std/math.d.
On Wednesday, 18 September 2019 at 13:24:05 UTC, berni wrote:
On Wednesday, 18 September 2019 at 12:37:28 UTC, Simen Kjærås
wrote:
How to resolve this, though? The simplest solution is to not
use selective imports:
import std.math;
import std.complex;
writeln(abs(complex(1.0,1.0
On Wed, Sep 18, 2019 at 12:37:28PM +, Simen Kjærås via Digitalmars-d-learn
wrote:
[...]
> template MergeOverloads(T...) {
> alias MergeOverloads = T[0];
> static if (T.length > 1) {
> alias MergeOverloads = MergeOverloads!(T[1..$]);
> }
> }
>
> I would however label that a
On Wednesday, 18 September 2019 at 12:37:28 UTC, Simen Kjærås
wrote:
How to resolve this, though? The simplest solution is to not
use selective imports:
import std.math;
import std.complex;
writeln(abs(complex(1.0,1.0)));
writeln(abs(1.0));
That works. But: I'm tryi
On Wednesday, 18 September 2019 at 12:03:28 UTC, berni wrote:
The following code doesn't compile:
import std.stdio;
void main()
{
import std.complex: abs, complex;
import std.math: abs;
auto a = complex(1.0,1.0);
auto b = 1.0;
writeln(abs(a));
writeln(abs(b));
}
On Wed, Sep 18, 2019 at 2:05 PM berni via Digitalmars-d-learn
wrote:
>
> The following code doesn't compile:
>
> >import std.stdio;
> >
> >void main()
> >{
> >import std.complex: abs, complex;
> >import std.math: abs;
> &g
On Wednesday, 18 September 2019 at 12:03:28 UTC, berni wrote:
The following code doesn't compile:
import std.stdio;
void main()
{
import std.complex: abs, complex;
import std.math: abs;
auto a = complex(1.0,1.0);
auto b = 1.0;
writeln(abs(a));
writeln(abs(b));
}
The following code doesn't compile:
import std.stdio;
void main()
{
import std.complex: abs, complex;
import std.math: abs;
auto a = complex(1.0,1.0);
auto b = 1.0;
writeln(abs(a));
writeln(abs(b));
}
The error message depends on the order of the two import
state
This shows a difference between the deprecated built-in complex
numbers and std.complex:
void main() {
import std.complex: complex;
const cdouble cd;
pragma(msg, typeof(cd.re));
const acc = complex(1, 2);
pragma(msg, typeof(acc.re));
}
It prints:
double
const(double)
Is
On Sunday, August 19, 2012 20:28:35 teo wrote:
> I read at http://dlang.org/phobos/std_complex.html that "Complex will
> eventually replace the built-in types cfloat, cdouble, creal, ifloat,
> idouble, and ireal".
>
> Can someone elaborate why? What is wrong with the above types?
I think that it
I read at http://dlang.org/phobos/std_complex.html that "Complex will
eventually replace the built-in types cfloat, cdouble, creal, ifloat,
idouble, and ireal".
Can someone elaborate why? What is wrong with the above types?
er, I think it should be defined as Complex!real
(0,1);
I hope it will be automatically downsized to Complex!int if the left
value is a Complex!int and so on.
I vote for defining it in std.complex for the folowing reasons:
- it will enforce coding discipline and standardize code among
libraries and
IMO it looks a lot better:
auto z = fromPolar(2.23, 1.107);
> even in C99 one could write "complex double z=1+2*I" (but "I" is a
> defined symbol) - instead of "Complex!double(2,3)"
If you want that, just define
immutable I = Complex!float(0, 1);
Perha
Maybe I am wrong, but my feeling is that if the complex numbers were a native
type (like creal&co. are now), then it would have been possible to have a
dedicated formatting (just like %f, %d and %s are) for writefln.
Putting the type into the library seems to forbid some very nice things:
- init
On Tue, 11 May 2010 11:51:34 +, eles wrote:
> the following test case also works:
>
> Compiling
>
> import std.stdio;
> import std.complex;
>
> Complex!(double) x,y;
>
> int main(){
> writefln("salut!\n");
> x.re=1;
> x.im
the following test case also works:
Compiling
import std.stdio;
import std.complex;
Complex!(double) x,y;
int main(){
writefln("salut!\n");
x.re=1;
x.im=1;
y=x.conj();
writefln("x=%f+%f*i\n",x.re,x.im);
writefln(&qu
Confirmation: in the new beta, the test case for the std.complex
compiles on windows xp with dmd 2.046beta. I cannot post on the
D.phobos newsgroup, but I post the confirmation here.
I did not test it further.
Compiling
import std.complex;
int main(){
return 0;
}
results in:
C:\dmd2
Thank you, Don. I saw your post on the http://news.gmane.org/
gmane.comp.lang.d.dmd.beta group. I'll wait for the next release.
Does anybody knows about when the http://d.puremagic.com/issues/
show_bug.cgi?id=2460 (DMD bug 2460) will be addressed?
eles wrote:
Hello,
I just installed dmd 2.045 (unarchived in c:\dmd2) and put c:
\dmd2\windows2\bin on path.
Compiling the following:
import std.complex;
int main(){
return 0;
}
fails with:
C:\dmd2>dmd test.d
OPTLINK (R) for Win32 Release 8.00.2
Copyright (C) Digital Mars 1
On Sun, 09 May 2010 18:57:08 +, eles wrote:
> actually, i think 2.045 was the second (after 2.044) release to include
> std.complex.
You are right, what's in Phobos now is the new std.complex.
> as i understand, std.complex should replace the native types cfloat,
> creal,
actually, i think 2.045 was the second (after 2.044) release to
include std.complex.
as i understand, std.complex should replace the native types cfloat,
creal, ifloat, ireal etc.
i was eager to test the new std.complex. it seems that some work is
still needed. maybe someone could submit a bug
On 09/05/10 14:41, div0 wrote:
Though I think there's been discussion about the whole complex number
support. Not sure what's going off but I think it's going to overhauled
or replaced, so you'd be better off not using std.complex
std.complex has just undergone its major r
;
> int main(){
> writefln("hello!\n");
> return 0;
> }
>
> results in:
>
> C:\dmd2>dmd test.d
>
> C:\dmd2>test
> hello!
>
> So, the problem is somewhere in std.complex.
Doesn't work even with 2.028.
For some reason complex
d2>test
hello!
So, the problem is somewhere in std.complex.
On 09/05/10 02:27, eles wrote:
Hello,
I just installed dmd 2.045 (unarchived in c:\dmd2) and put c:
\dmd2\windows2\bin on path.
Compiling the following:
import std.complex;
int main(){
return 0;
}
fails with:
C:\dmd2>dmd test.d
OPTLINK (R) for Win32 Release 8.00.2
Copyright
Hello,
I just installed dmd 2.045 (unarchived in c:\dmd2) and put c:
\dmd2\windows2\bin on path.
Compiling the following:
import std.complex;
int main(){
return 0;
}
fails with:
C:\dmd2>dmd test.d
OPTLINK (R) for Win32 Release 8.00.2
Copyright (C) Digital Mars 1989-2009
nly difference should be that you need to import std.complex (if that
even). If changing to a library introduces any reduction in
functionality beyond that I don't think it would go through.
--bb
MikeWh:
> Why in the world would complex types be dropped from D?
Andrei wants to cut them away from the language. And his power in the design of
the language is great. So saying such things here isn't going to help much. So
you can send him an email, for example. He will probably answer you tha
;>> Doesn't D already has the built-in types cfloat, cdouble, creal,
>>> ifloat, idouble, and ireal?What's the advantage having complex class
>>> instead?
>
> The intention is that cfloat, cdouble,... will be deprecated eventually.
>
> I don
Steven Schveighoffer wrote:
On Mon, 06 Apr 2009 09:50:35 -0400, Don wrote:
Steven Schveighoffer wrote:
On Mon, 06 Apr 2009 08:36:18 -0400, Don wrote:
Sam Hu wrote:
Thank you!
Anothe silly question then:What's the disadvantage to have the
built-in type of i-type?
Regards,
Sam
It's a v
bearophile wrote:
> A better question can be: "What's the advantage of having a built-in
> imaginary type?" :-)
> You can find an answer here, from page 11:
> http://www.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf
> But maybe those ideas aren't much true anymore today.
Why could you not make a struct
On Mon, 06 Apr 2009 09:50:35 -0400, Don wrote:
Steven Schveighoffer wrote:
On Mon, 06 Apr 2009 08:36:18 -0400, Don wrote:
Sam Hu wrote:
Thank you!
Anothe silly question then:What's the disadvantage to have the
built-in type of i-type?
Regards,
Sam
It's a very nasty type. It supports
Steven Schveighoffer wrote:
On Mon, 06 Apr 2009 08:36:18 -0400, Don wrote:
Sam Hu wrote:
Thank you!
Anothe silly question then:What's the disadvantage to have the
built-in type of i-type?
Regards,
Sam
It's a very nasty type. It supports *, but isn't closed under *.
Which is really annoyi
Steven Schveighoffer wrote:
> On Mon, 06 Apr 2009 08:36:18 -0400, Don wrote:
>
>> Sam Hu wrote:
>>> Thank you!
>>> Anothe silly question then:What's the disadvantage to have the
>>> built-in type of i-type?
>>> Regards,
>>> Sam
>>
>> It's a very nasty type. It supports *, but isn't closed unde
On Mon, 06 Apr 2009 08:36:18 -0400, Don wrote:
Sam Hu wrote:
Thank you!
Anothe silly question then:What's the disadvantage to have the built-in
type of i-type?
Regards,
Sam
It's a very nasty type. It supports *, but isn't closed under *.
Which is really annoying for generic programming.
Sam Hu wrote:
Thank you!
Anothe silly question then:What's the disadvantage to have the built-in type of
i-type?
Regards,
Sam
It's a very nasty type. It supports *, but isn't closed under *.
Which is really annoying for generic programming.
idouble x = 2i;
x *= x; // oops, this isn't imagina
bearophile wrote:
Sam Hu:
Doesn't D already has the built-in types cfloat, cdouble, creal, ifloat,
idouble, and ireal?What's the advantage having complex class instead?
The intention is that cfloat, cdouble,... will be deprecated eventually.
I don't think std.complex sh
Sam Hu Wrote:
>What's the disadvantage to have the built-in type of i-type?<
I think the answer is: It's another type added to the language, with its
specific semantics, so it adds a bit of complexity to the language. And most
people today don't seem to use complex types in D1 much, so they thin
Thank you!
Anothe silly question then:What's the disadvantage to have the built-in type of
i-type?
Regards,
Sam
Sam Hu:
> Doesn't D already has the built-in types cfloat, cdouble, creal, ifloat,
> idouble, and ireal?What's the advantage having complex class instead?
Some people have discussed/complained that complex types aren't worth being
built-ins, so the *struct* Complex of s
Hello everyone!
Doesn't D already has the built-in types cfloat, cdouble, creal, ifloat,
idouble, and ireal?What's the advantage having complex class instead?
Thanks and best regards,
Sam
43 matches
Mail list logo
