Re: Can't "is null" an interface?!?! Incompatible types???
On Thursday, 8 March 2018 at 04:48:08 UTC, Nick Sabalausky
(Abscissa) wrote:
-
import vibe.core.net;
TCPConnection mySocket;
void main() {
auto b = mySocket is null;
}
-
That's giving me:
-
Error: incompatible types for (mySocket) is (null):
TCPConnection and typeof(null)
-
WTF?!?!
The type in question (vibe.core.net.TCPConnection) is an
interface:
http://vibed.org/api/vibe.core.net/TCPConnection
https://github.com/vibe-d/vibe.d/blob/master/core/vibe/core/net.d#L344
The following works just fine:
-
interface IFoo {}
void main() {
IFoo i;
auto b = i is null;
}
-
That does seem odd.
---
/+dub.sdl:
dependency "vibe-d" version="~>0.8.3-alpha.1"
+/
import vibe.core.net;
import std.stdio;
TCPConnection mySocket;
void main() {
auto b = mySocket is null;
writeln(b);
}
---
works fine on run.dlang.io
Re: docs/definition: !object
Nick Sabalausky (Abscissa) wrote: (Or does return the address of the *reference* to the object rather than the address of the object?...You can see just how often I do OO in D ;) ) exactly. if you want to convert object to a pointer safely, do this: MyObject o; void* p = *cast(void**) this magic construct guarantees that you won't hit `opCast()` in `MyObject` (yes, somebody *can* write weird `opCast` for `void*`! ;-). doing just `` gives you the address of a variable (on a stack, or in a tls), which is, obviously, never `null`. ;-)
Re: docs/definition: !object
On 03/08/2018 12:05 AM, ketmar wrote: Nick Sabalausky (Abscissa) wrote: I'm having trouble finding the documentation for what exactly the unary "not" operator does when applied to a class/interface object. Does this documentation exist somewhere? I know at least part of it involves "is null", but I seem to remember hearing there was more to it than just that. https://dlang.org/spec/operatoroverloading.html#boolean_operators "Class references are converted to bool by checking to see if the class reference is null or not." Ah, thanks. But are we CERTAIN that's all there is to it? I have a non-reduced situation right now where outputting the address of a class reveals a non-null address, and yet assert(!!theObjectInQuestion) is failing. (this is occurring during stack unwinding, if that makes a difference) (Or does return the address of the *reference* to the object rather than the address of the object?...You can see just how often I do OO in D ;) )
Re: docs/definition: !object
Nick Sabalausky (Abscissa) wrote: I'm having trouble finding the documentation for what exactly the unary "not" operator does when applied to a class/interface object. Does this documentation exist somewhere? I know at least part of it involves "is null", but I seem to remember hearing there was more to it than just that. https://dlang.org/spec/operatoroverloading.html#boolean_operators "Class references are converted to bool by checking to see if the class reference is null or not."
Re: VsCode tutorial
On Wednesday, 7 March 2018 at 21:39:09 UTC, Apocalypto wrote: Are there any tutorials about D in vscode? No that I know of. Which are the minimal plugins to install to have code completion, syntax highlighting and code formatting? I've been getting by with https://marketplace.visualstudio.com/items?itemName=webfreak.code-d-beta Are there any app templates that i can invoke to not start every project from scratch? See the usage of `dub init` here: https://code.dlang.org/getting_started How can I debug my app? See https://marketplace.visualstudio.com/items?itemName=webfreak.debug Mike
docs/definition: !object
I'm having trouble finding the documentation for what exactly the unary "not" operator does when applied to a class/interface object. Does this documentation exist somewhere? I know at least part of it involves "is null", but I seem to remember hearing there was more to it than just that.
Can't "is null" an interface?!?! Incompatible types???
-
import vibe.core.net;
TCPConnection mySocket;
void main() {
auto b = mySocket is null;
}
-
That's giving me:
-
Error: incompatible types for (mySocket) is (null): TCPConnection and
typeof(null)
-
WTF?!?!
The type in question (vibe.core.net.TCPConnection) is an interface:
http://vibed.org/api/vibe.core.net/TCPConnection
https://github.com/vibe-d/vibe.d/blob/master/core/vibe/core/net.d#L344
The following works just fine:
-
interface IFoo {}
void main() {
IFoo i;
auto b = i is null;
}
-
Re: issue with each specifically for x86
Matt Gamble wrote: Ok, this has been submitted as a bug. https://issues.dlang.org/show_bug.cgi?id=18573 thank you.
Re: issue with each specifically for x86
On Wednesday, 7 March 2018 at 21:39:58 UTC, ketmar wrote: Matt Gamble wrote: On Wednesday, 7 March 2018 at 21:02:30 UTC, ag0aep6g wrote: On 03/07/2018 09:09 PM, ag0aep6g wrote: [...] With `real` instead of `double` x86_64 is also affected. Wow. Good to know I'm not crazy. I was afk for a bit, sorry. I guess I'm glad I found it and posted. The conversation has gone beyond my realm of understanding. Has anyone tested on 2.079 like Ali wanted. I have not had a chance to install. I was going to wait to post the bug till that was tried. sure, it is still there in git HEAD. it is not the bug that can be fixed "accidentally". %-) Ok, this has been submitted as a bug. https://issues.dlang.org/show_bug.cgi?id=18573 Thanks for the quick responses. Don't know what I'd do with out the community.
Re: issue with each specifically for x86
Matt Gamble wrote:
On Wednesday, 7 March 2018 at 21:02:30 UTC, ag0aep6g wrote:
On 03/07/2018 09:09 PM, ag0aep6g wrote:
double f() { return 1; }
void main()
{
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
double b = 2;
assert(b == 2); /* fails; should pass */
}
With `real` instead of `double` x86_64 is also affected.
Wow. Good to know I'm not crazy. I was afk for a bit, sorry. I guess I'm
glad I found it and posted. The conversation has gone beyond my realm of
understanding. Has anyone tested on 2.079 like Ali wanted. I have not had
a chance to install. I was going to wait to post the bug till that was
tried.
sure, it is still there in git HEAD. it is not the bug that can be fixed
"accidentally". %-)
VsCode tutorial
Are there any tutorials about D in vscode? Which are the minimal plugins to install to have code completion, syntax highlighting and code formatting? Are there any app templates that i can invoke to not start every project from scratch? How can I debug my app?
Re: issue with each specifically for x86
On Wednesday, 7 March 2018 at 21:02:30 UTC, ag0aep6g wrote:
On 03/07/2018 09:09 PM, ag0aep6g wrote:
double f() { return 1; }
void main()
{
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
double b = 2;
assert(b == 2); /* fails; should pass */
}
With `real` instead of `double` x86_64 is also affected.
Wow. Good to know I'm not crazy. I was afk for a bit, sorry. I
guess I'm glad I found it and posted. The conversation has gone
beyond my realm of understanding. Has anyone tested on 2.079 like
Ali wanted. I have not had a chance to install. I was going to
wait to post the bug till that was tried.
Re: issue with each specifically for x86
ag0aep6g wrote:
On 03/07/2018 09:09 PM, ag0aep6g wrote:
double f() { return 1; }
void main()
{
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
double b = 2;
assert(b == 2); /* fails; should pass */
}
With `real` instead of `double` x86_64 is also affected.
yeah. that is 'cause SSE cannot do math with 80-bit floats, and compiler
falls back to FPU in this case.
Re: issue with each specifically for x86
On 03/07/2018 09:09 PM, ag0aep6g wrote:
double f() { return 1; }
void main()
{
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
double b = 2;
assert(b == 2); /* fails; should pass */
}
With `real` instead of `double` x86_64 is also affected.
Re: issue with each specifically for x86
H. S. Teoh wrote:
On Wed, Mar 07, 2018 at 10:21:42PM +0200, ketmar via Digitalmars-d-learn
wrote:
[...]
it looks like ignoring `double` result causes FPU stack imbalance
('cause compiler doesn't insert "FPU pop" instruction), and that
affects the computations.
on 64 bit it doesn't matter, 'cause no FPU is used there.
the fix prolly should be easy: just emit "FPU pop" if function result
is ignored. codegen should have this info at hand, i believe.
Nice catch! Is there a bug filed for this yet? If not, it should be.
btw, this is specific to `cast(void)`. if you'll remove the cast, or do
something like `cast(void)(pred(i)+42);`, the bug won't be there. so it
looks like it is not a codegen bug after all, but glue layer. the codegen
is correctly dropping the result without `cast(void)` (`fstp %st(0)` is
inserted in `main`), but cannot do that if return type information is stripped.
so it looks that glue layer should not strip return type info.
Re: issue with each specifically for x86
H. S. Teoh wrote:
On Wed, Mar 07, 2018 at 10:21:42PM +0200, ketmar via Digitalmars-d-learn
wrote:
[...]
it looks like ignoring `double` result causes FPU stack imbalance
('cause compiler doesn't insert "FPU pop" instruction), and that
affects the computations.
on 64 bit it doesn't matter, 'cause no FPU is used there.
the fix prolly should be easy: just emit "FPU pop" if function result
is ignored. codegen should have this info at hand, i believe.
Nice catch! Is there a bug filed for this yet? If not, it should be.
it seems that no bug is filled yet. feel free to do so. ;-) or maybe OP
should better do it, dunno. definitely not me. ;-)
Re: issue with each specifically for x86
On Wed, Mar 07, 2018 at 10:21:42PM +0200, ketmar via Digitalmars-d-learn wrote:
[...]
> it looks like ignoring `double` result causes FPU stack imbalance
> ('cause compiler doesn't insert "FPU pop" instruction), and that
> affects the computations.
>
> on 64 bit it doesn't matter, 'cause no FPU is used there.
>
> the fix prolly should be easy: just emit "FPU pop" if function result
> is ignored. codegen should have this info at hand, i believe.
Nice catch! Is there a bug filed for this yet? If not, it should be.
T
--
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs
Re: issue with each specifically for x86
Steven Schveighoffer wrote:
it seems that the only difference between `void` and `double` lambda is one
asm instruction: `fldl (%edi)`. it is presend in `double` labmda, and
absent in `void` lambda.
it looks like ignoring `double` result causes FPU stack imbalance ('cause
compiler doesn't insert "FPU pop" instruction), and that affects the computations.
on 64 bit it doesn't matter, 'cause no FPU is used there.
the fix prolly should be easy: just emit "FPU pop" if function result is
ignored. codegen should have this info at hand, i believe.
Re: issue with each specifically for x86
On 3/7/18 3:09 PM, ag0aep6g wrote:
On 03/07/2018 08:54 PM, Steven Schveighoffer wrote:
Clearly there is some codegen issue here.
It's beautiful:
double f() { return 1; }
void main()
{
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
double b = 2;
assert(b == 2); /* fails; should pass */
}
Are all those calls required? That's one crazy bug.
-Steve
Re: How can I get notified when an process created by spawnShell() has exit?
On Wednesday, 7 March 2018 at 15:03:28 UTC, Marc wrote:
I do need to start (up to 4 a time) processes in parallel but
I'd like to get notified (similar to C#'s Process.Exited Event)
when the process exits. How can I do that in D?
You can use pipeShell and a control loop to check when the
ProcessPipes it returns is done.
example:
```d
void main()
{
import std.stdio, std.process, std.conv, std.random,
core.thread,
std.algorithm, std.range;
ProcessPipes[4] pp;
iota(0,4).each!(a => pp[a] = pipeShell("sleep " ~
uniform(1,20).to!string));
while (pp[].any!(a => !tryWait(a.pid).terminated))
Thread.sleep(dur!"msecs"(50));
writeln("done");
}
```
You can wrap in a struct to hide the ugly bits.
Re: issue with each specifically for x86
On 03/07/2018 08:54 PM, Steven Schveighoffer wrote:
Looking at each, it looks like it does this:
cast(void) unaryFun!pred(r.front);
So I tried this:
auto pred = i => a[i] = a[i-1] + 2;
foreach(i; 1 .. a.length)
cast(void)pred(i);
And I see the -nan value. Remove the cast(void) and I don't see it.
Clearly there is some codegen issue here.
It's beautiful:
double f() { return 1; }
void main()
{
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
cast(void) f();
double b = 2;
assert(b == 2); /* fails; should pass */
}
Re: issue with each specifically for x86
On 3/7/18 1:57 PM, Matt Gamble wrote:
This is a record for me with two 32bit vs 64bit issues in one day. Seems
to be a problem with using "each" under 32bit which can be fixed by
using foreach or switching to x64. Am I doing something wrong or is this
the second bug I've found today?
Below is a silly case, that replicates an error. (i.e. I know I could
use iota(0,9,2).array), but that does not demonstrate the potential bug
and would not fix my actual program.)
import std.range;
import std.algorithm;
import std.stdio;
unittest
{
auto a = new double[9];
a[0] = 0;
iota(1,a.length).each!(i => a[i] = a[i-1] + 2);
writeln(a);
}
//x86, wrong, error
//[-nan, 2, 4, 6, 8, 10, 12, 14, 16]
//First-chance exception: std.format.FormatException Unterminated format
specifier: "%" at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(1175)
//x64, correct
//[0, 2, 4, 6, 8, 10, 12, 14, 16]
unittest
{
auto a = new double[9];
a[0] = 0;
foreach(i; 1..a.length) a[i] = a[i - 1] + 2;
writeln(a);
}
//x86, correct
//[0, 2, 4, 6, 8, 10, 12, 14, 16]
//x64, correct
//[0, 2, 4, 6, 8, 10, 12, 14, 16]
This is windows 10, DMD v2.076.1
It has something to do with the fact that you are returning the value:
iota(1, a.length).each!((i) {a[i] = a[i - 1] + 2;}); // ok
iota(1, a.length).each!((i) {return a[i] = a[i - 1] + 2;}); // shows error
Which is odd to say the least, I don't think each is supposed to do
anything with the return value.
I don't get the exception BTW (2.078.1 Windows 10).
Looking at each, it looks like it does this:
cast(void) unaryFun!pred(r.front);
So I tried this:
auto pred = i => a[i] = a[i-1] + 2;
foreach(i; 1 .. a.length)
cast(void)pred(i);
And I see the -nan value. Remove the cast(void) and I don't see it.
Clearly there is some codegen issue here.
-Steve
Re: issue with each specifically for x86
On 03/07/2018 10:57 AM, Matt Gamble wrote:
This is a record for me with two 32bit vs 64bit issues in one day. Seems
to be a problem with using "each" under 32bit which can be fixed by
using foreach or switching to x64. Am I doing something wrong or is this
the second bug I've found today?
Below is a silly case, that replicates an error. (i.e. I know I could
use iota(0,9,2).array), but that does not demonstrate the potential bug
and would not fix my actual program.)
import std.range;
import std.algorithm;
import std.stdio;
unittest
{
auto a = new double[9];
a[0] = 0;
iota(1,a.length).each!(i => a[i] = a[i-1] + 2);
writeln(a);
}
//x86, wrong, error
//[-nan, 2, 4, 6, 8, 10, 12, 14, 16]
//First-chance exception: std.format.FormatException Unterminated format
specifier: "%" at C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(1175)
//x64, correct
//[0, 2, 4, 6, 8, 10, 12, 14, 16]
unittest
{
auto a = new double[9];
a[0] = 0;
foreach(i; 1..a.length) a[i] = a[i - 1] + 2;
writeln(a);
}
//x86, correct
//[0, 2, 4, 6, 8, 10, 12, 14, 16]
//x64, correct
//[0, 2, 4, 6, 8, 10, 12, 14, 16]
This is windows 10, DMD v2.076.1
Confirmed on Linux with dmd 2.078.1
It's somehow related to the unused return value of the lambda. The
following code has the same error:
iota(1,a.length).each!((i) {
a[i] = a[i-1] + 2;
return a[i];
});
The error disappears when that return statement is commented-out.
Please file a dmd bug after making sure that 2.079 still has it. (Too
lazy to install right now.)
An ldc that I have handy does not have this bug:
based on DMD v2.073.2 and LLVM 4.0.0
Ali
issue with each specifically for x86
This is a record for me with two 32bit vs 64bit issues in one
day. Seems to be a problem with using "each" under 32bit which
can be fixed by using foreach or switching to x64. Am I doing
something wrong or is this the second bug I've found today?
Below is a silly case, that replicates an error. (i.e. I know I
could use iota(0,9,2).array), but that does not demonstrate the
potential bug and would not fix my actual program.)
import std.range;
import std.algorithm;
import std.stdio;
unittest
{
auto a = new double[9];
a[0] = 0;
iota(1,a.length).each!(i => a[i] = a[i-1] + 2);
writeln(a);
}
//x86, wrong, error
//[-nan, 2, 4, 6, 8, 10, 12, 14, 16]
//First-chance exception: std.format.FormatException Unterminated
format specifier: "%" at
C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(1175)
//x64, correct
//[0, 2, 4, 6, 8, 10, 12, 14, 16]
unittest
{
auto a = new double[9];
a[0] = 0;
foreach(i; 1..a.length) a[i] = a[i - 1] + 2;
writeln(a);
}
//x86, correct
//[0, 2, 4, 6, 8, 10, 12, 14, 16]
//x64, correct
//[0, 2, 4, 6, 8, 10, 12, 14, 16]
This is windows 10, DMD v2.076.1
Re: log for complex
On Wed, Mar 07, 2018 at 10:47:40AM +, J-S Caux via Digitalmars-d-learn
wrote:
> On Wednesday, 7 March 2018 at 10:28:23 UTC, Simen Kjærås wrote:
> > On Wednesday, 7 March 2018 at 10:10:49 UTC, J-S Caux wrote:
> > > On Wednesday, 7 March 2018 at 08:04:36 UTC, Simen Kjærås wrote:
> > > > auto log(T)(Complex!T x) {
> > > > import std.math : log;
> > > > return Complex!T(log(abs(x)), arg(x));
> > > > }
> > >
> > > Yes indeed I can do this, but isn't this inefficient as compared
> > > to what it should be? The internals of arg are presumable already
> > > doing part of/all the necessary work.
> >
> > arg is just atan2 in disguise, and doesn't do any logarithms. I
> > mean, in a way it does, but it's really just a fpatan instruction. I
> > don't expect there to be many optimization opportunities here.
[...]
> OK thanks Simen. Should your suggestion for repairing this omission be
> filed as a bugreport? I can of course implement it locally for myself,
> but the language should really provide this function directly.
Yes, please file a bug.
T
--
The trouble with TCP jokes is that it's like hearing the same joke over and
over.
Re: issue with inf from exp function
On Wednesday, 7 March 2018 at 16:40:04 UTC, Steven Schveighoffer wrote: On 3/7/18 11:19 AM, Matt Gamble wrote: On Wednesday, 7 March 2018 at 16:12:28 UTC, Matt Gamble wrote: On Wednesday, 7 March 2018 at 16:10:15 UTC, Marc wrote: On Wednesday, 7 March 2018 at 16:00:39 UTC, Alex wrote: [...] it works for me too. https://imgur.com/bLGTv1l Wow, Now I'm really confused, I'm using DMD v2.076.1. Any thoughts I why I'm getting this result? Yes if I switch to 32bit, it works for me now. Is this a bug? Looks like it. The core.stdc.math module looks very cryptic, but appears to do some weird things via exp on real. -Steve Thanks. I submitted as a bug. https://issues.dlang.org/show_bug.cgi?id=18570
Re: issue with inf from exp function
On 3/7/18 11:19 AM, Matt Gamble wrote: On Wednesday, 7 March 2018 at 16:12:28 UTC, Matt Gamble wrote: On Wednesday, 7 March 2018 at 16:10:15 UTC, Marc wrote: On Wednesday, 7 March 2018 at 16:00:39 UTC, Alex wrote: On Wednesday, 7 March 2018 at 15:44:28 UTC, Matt Gamble wrote: [...] works for me as expected. ln(largest double) = 709.783 e^710 = inf ln(largest real) = 11356.5 e^710 = 2.23399e+308 it works for me too. https://imgur.com/bLGTv1l Wow, Now I'm really confused, I'm using DMD v2.076.1. Any thoughts I why I'm getting this result? Yes if I switch to 32bit, it works for me now. Is this a bug? Looks like it. The core.stdc.math module looks very cryptic, but appears to do some weird things via exp on real. -Steve
Re: issue with inf from exp function
On Wednesday, 7 March 2018 at 16:12:28 UTC, Matt Gamble wrote: On Wednesday, 7 March 2018 at 16:10:15 UTC, Marc wrote: On Wednesday, 7 March 2018 at 16:00:39 UTC, Alex wrote: On Wednesday, 7 March 2018 at 15:44:28 UTC, Matt Gamble wrote: [...] works for me as expected. ln(largest double) = 709.783 e^710 = inf ln(largest real) = 11356.5 e^710 = 2.23399e+308 it works for me too. https://imgur.com/bLGTv1l Wow, Now I'm really confused, I'm using DMD v2.076.1. Any thoughts I why I'm getting this result? Yes if I switch to 32bit, it works for me now. Is this a bug?
Re: issue with inf from exp function
On Wednesday, 7 March 2018 at 16:12:28 UTC, Matt Gamble wrote: On Wednesday, 7 March 2018 at 16:10:15 UTC, Marc wrote: On Wednesday, 7 March 2018 at 16:00:39 UTC, Alex wrote: On Wednesday, 7 March 2018 at 15:44:28 UTC, Matt Gamble wrote: [...] works for me as expected. ln(largest double) = 709.783 e^710 = inf ln(largest real) = 11356.5 e^710 = 2.23399e+308 it works for me too. https://imgur.com/bLGTv1l Wow, Now I'm really confused, I'm using DMD v2.076.1. Any thoughts I why I'm getting this result? See my previous post. It's something related to generating 64bit code.
Re: issue with inf from exp function
On Wednesday, 7 March 2018 at 16:00:39 UTC, Alex wrote:
On Wednesday, 7 March 2018 at 15:44:28 UTC, Matt Gamble wrote:
I don't understand why I'm getting an 'inf' by raising E to a
real number, e^^710.0L. See below.
import std.stdio;
import std.math;
unittest
{
writefln("ln(largest double) = %s", log(double.max)); //
709.783
writefln("e^710 = %s", exp(710.0));// inf, makes sense
writefln("ln(largest real) = %s", log(real.max)); // 11356.6
real t = 710.0;
writefln("e^710 = %s", exp(t)); //why is this inf???
}
Any help would be greatly appreciated. I have functions in an
actual program that are giving me a headache due to this issue.
works for me as expected.
ln(largest double) = 709.783
e^710 = inf
ln(largest real) = 11356.5
e^710 = 2.23399e+308
it works for me too.
https://imgur.com/bLGTv1l
Re: issue with inf from exp function
On Wednesday, 7 March 2018 at 16:06:26 UTC, Matt Gamble wrote: On Wednesday, 7 March 2018 at 16:00:39 UTC, Alex wrote: On Wednesday, 7 March 2018 at 15:44:28 UTC, Matt Gamble wrote: [...] works for me as expected. ln(largest double) = 709.783 e^710 = inf ln(largest real) = 11356.5 e^710 = 2.23399e+308 Really? Is it my system? I'm running windows 10, with an intel Core i7-4650, 64bit operating system I compiled with -m64 -g -unittest -main Did notice you were using -m64 flag before. Well, now I used -m64 the same code doesn't work as expected. I also got inf.
Re: issue with inf from exp function
On Wednesday, 7 March 2018 at 16:10:15 UTC, Marc wrote: On Wednesday, 7 March 2018 at 16:00:39 UTC, Alex wrote: On Wednesday, 7 March 2018 at 15:44:28 UTC, Matt Gamble wrote: [...] works for me as expected. ln(largest double) = 709.783 e^710 = inf ln(largest real) = 11356.5 e^710 = 2.23399e+308 it works for me too. https://imgur.com/bLGTv1l Wow, Now I'm really confused, I'm using DMD v2.076.1. Any thoughts I why I'm getting this result?
Re: issue with inf from exp function
On Wednesday, 7 March 2018 at 16:00:39 UTC, Alex wrote:
On Wednesday, 7 March 2018 at 15:44:28 UTC, Matt Gamble wrote:
I don't understand why I'm getting an 'inf' by raising E to a
real number, e^^710.0L. See below.
import std.stdio;
import std.math;
unittest
{
writefln("ln(largest double) = %s", log(double.max)); //
709.783
writefln("e^710 = %s", exp(710.0));// inf, makes sense
writefln("ln(largest real) = %s", log(real.max)); // 11356.6
real t = 710.0;
writefln("e^710 = %s", exp(t)); //why is this inf???
}
Any help would be greatly appreciated. I have functions in an
actual program that are giving me a headache due to this issue.
works for me as expected.
ln(largest double) = 709.783
e^710 = inf
ln(largest real) = 11356.5
e^710 = 2.23399e+308
Really? Is it my system?
I'm running windows 10, with an intel Core i7-4650, 64bit
operating system
I compiled with -m64 -g -unittest -main
Re: issue with inf from exp function
On Wednesday, 7 March 2018 at 15:44:28 UTC, Matt Gamble wrote:
I don't understand why I'm getting an 'inf' by raising E to a
real number, e^^710.0L. See below.
import std.stdio;
import std.math;
unittest
{
writefln("ln(largest double) = %s", log(double.max)); //
709.783
writefln("e^710 = %s", exp(710.0));// inf, makes sense
writefln("ln(largest real) = %s", log(real.max)); // 11356.6
real t = 710.0;
writefln("e^710 = %s", exp(t)); //why is this inf???
}
Any help would be greatly appreciated. I have functions in an
actual program that are giving me a headache due to this issue.
works for me as expected.
ln(largest double) = 709.783
e^710 = inf
ln(largest real) = 11356.5
e^710 = 2.23399e+308
issue with inf from exp function
I don't understand why I'm getting an 'inf' by raising E to a
real number, e^^710.0L. See below.
import std.stdio;
import std.math;
unittest
{
writefln("ln(largest double) = %s", log(double.max)); // 709.783
writefln("e^710 = %s", exp(710.0));// inf, makes sense
writefln("ln(largest real) = %s", log(real.max)); // 11356.6
real t = 710.0;
writefln("e^710 = %s", exp(t)); //why is this inf???
}
Any help would be greatly appreciated. I have functions in an
actual program that are giving me a headache due to this issue.
How can I get notified when an process created by spawnShell() has exit?
I do need to start (up to 4 a time) processes in parallel but I'd like to get notified (similar to C#'s Process.Exited Event) when the process exits. How can I do that in D?
Re: Generic test bit function (core.bitop)
On Tuesday, 6 March 2018 at 10:37:30 UTC, Pierre wrote:
Hi all,
I would like to use bt function (core.bitop) on generic array
but it seems that's not possible. I would like to know if there
is some reasons to have a fixed type (size_t) instead of
something like :
pure @system int bt(T)(in T* p,size_t bitnum)
if(__traits(isIntegral,T))
{
return p[bitnum/ (T.sizeof*8)] & (1 << (bitnum&
((T.sizeof*8) - 1)));
}
Thank you for your help.
From this point of view, size_t is not fixed, but capable to
point to any place in memory.
Therefore, pointer of any type have by definition exactly the
defined size of size_t.
If you want to use an array (or an object of custom type) as a
bit array, there is for example
https://dlang.org/library/std/bitmanip/bit_array.html
which fits more, I think...
DUB and Gtk-d reduce size of huge executable, build dynamic dependencies
Hi, I'm trying to decide whether it is better to use DLang for Gtk development or Vala/Genie. When I make a simple Vala/Genie Gtk executable the file is tiny whereas the DLang file is huge. First I used the default Dub build and the file was in excess of 60mb (assuming this includes debug build). Using dub build=release the file is still more than 7 mb. Using a native Vala/Genie build the file is less than 500k. Trying to understand what is going on, but I assume from this that Dub is linking static dependencies, whereas the Vala/Genie builds will link to dynamic libraries. So my (two pronged) question is this: Is there any way to specify in dub.json to build and link dependencies as dynamic libraries, and are there any other tips that can be used to reduce these (relatively) huge executables?
Re: log for complex
On Wednesday, 7 March 2018 at 10:28:23 UTC, Simen Kjærås wrote:
On Wednesday, 7 March 2018 at 10:10:49 UTC, J-S Caux wrote:
On Wednesday, 7 March 2018 at 08:04:36 UTC, Simen Kjærås wrote:
auto log(T)(Complex!T x) {
import std.math : log;
return Complex!T(log(abs(x)), arg(x));
}
Yes indeed I can do this, but isn't this inefficient as
compared to what it should be? The internals of arg are
presumable already doing part of/all the necessary work.
arg is just atan2 in disguise, and doesn't do any logarithms. I
mean, in a way it does, but it's really just a fpatan
instruction. I don't expect there to be many optimization
opportunities here.
--
Simen
OK thanks Simen. Should your suggestion for repairing this
omission be filed as a bugreport? I can of course implement it
locally for myself, but the language should really provide this
function directly.
Re: log for complex
On Wednesday, 7 March 2018 at 10:10:49 UTC, J-S Caux wrote:
On Wednesday, 7 March 2018 at 08:04:36 UTC, Simen Kjærås wrote:
auto log(T)(Complex!T x) {
import std.math : log;
return Complex!T(log(abs(x)), arg(x));
}
Yes indeed I can do this, but isn't this inefficient as
compared to what it should be? The internals of arg are
presumable already doing part of/all the necessary work.
arg is just atan2 in disguise, and doesn't do any logarithms. I
mean, in a way it does, but it's really just a fpatan
instruction. I don't expect there to be many optimization
opportunities here.
--
Simen
Re: log for complex
On Wednesday, 7 March 2018 at 08:04:36 UTC, Simen Kjærås wrote:
On Wednesday, 7 March 2018 at 07:42:37 UTC, J-S Caux wrote:
Simple question: how do I get the log of a complex number?
If I try the simple
logtest = log(complex(1.0, 2.0))
I get the compiler error
Error: function core.stdc.math.log(double x) is not callable
using argument types (Complex!double)
Some basic functions are described in
https://dlang.org/phobos/std_complex.html, but not the log...
That seems like an oversight. For now, this should work:
auto log(T)(Complex!T x) {
import std.math : log;
return Complex!T(log (abs(x)), arg(x));
}
--
Simen
Yes indeed I can do this, but isn't this inefficient as compared
to what it should be? The internals of arg are presumable already
doing part of/all the necessary work.
Re: log for complex
On Wednesday, 7 March 2018 at 07:42:37 UTC, J-S Caux wrote:
Simple question: how do I get the log of a complex number?
If I try the simple
logtest = log(complex(1.0, 2.0))
I get the compiler error
Error: function core.stdc.math.log(double x) is not callable
using argument types (Complex!double)
Some basic functions are described in
https://dlang.org/phobos/std_complex.html, but not the log...
That seems like an oversight. For now, this should work:
auto log(T)(Complex!T x) {
import std.math : log;
return Complex!T(log (abs(x)), arg(x));
}
--
Simen
