On Saturday, 9 February 2019 at 02:12:29 UTC, Murilo wrote:
Why is it that in C when I attribute the number
991234307654329925.7865 to a double it prints
991234299470108672. and in D it prints
9912342990. ? Apparently both languages
cause a certain loss
On Sat, Feb 09, 2019 at 04:36:26AM +, DanielG via Digitalmars-d-learn wrote:
> On Saturday, 9 February 2019 at 04:32:44 UTC, Murilo wrote:
> > Thank you very much for clearing this up. But how do I make D
> > behave just like C? Is there a way to do that?
>
> Off the top of my head, you'd have
On Sat, Feb 09, 2019 at 03:52:38AM +, Murilo via Digitalmars-d-learn wrote:
> On Saturday, 9 February 2019 at 03:28:24 UTC, Adam D. Ruppe wrote:
[...]
> > But you can change this with the format specifiers (use `writefln`
> > instead of `writeln` and give a precision argument) or, of course,
>
On Saturday, 9 February 2019 at 04:36:26 UTC, DanielG wrote:
On Saturday, 9 February 2019 at 04:32:44 UTC, Murilo wrote:
Thank you very much for clearing this up. But how do I make D
behave just like C? Is there a way to do that?
Off the top of my head, you'd have to link against libc so you
On Saturday, 9 February 2019 at 04:32:44 UTC, Murilo wrote:
Thank you very much for clearing this up. But how do I make D
behave just like C? Is there a way to do that?
Off the top of my head, you'd have to link against libc so you
could use printf() directly.
But may I ask why that is so im
On Saturday, 9 February 2019 at 04:30:22 UTC, DanielG wrote:
On Saturday, 9 February 2019 at 03:33:13 UTC, Murilo wrote:
Thanks but here is the situation, I use printf("%.20f", 0.1);
in both C and D, C returns 0.1555 whereas D
returns 0.10001000. So I understand your
On Saturday, 9 February 2019 at 03:33:13 UTC, Murilo wrote:
Thanks but here is the situation, I use printf("%.20f", 0.1);
in both C and D, C returns 0.1555 whereas D
returns 0.10001000. So I understand your point, D
rounds off more, but that causes loss of precision,
On Saturday, 9 February 2019 at 03:28:24 UTC, Adam D. Ruppe wrote:
On Saturday, 9 February 2019 at 03:21:51 UTC, Murilo wrote:
Now, changing a little bit the subject. All FPs in D turn out
to be printed differently than they are in C and in C it comes
out a little more precise than in D. Is thi
On Saturday, 9 February 2019 at 03:28:24 UTC, Adam D. Ruppe wrote:
On Saturday, 9 February 2019 at 03:21:51 UTC, Murilo wrote:
Now, changing a little bit the subject. All FPs in D turn out
to be printed differently than they are in C and in C it comes
out a little more precise than in D. Is thi
On Saturday, 9 February 2019 at 03:21:51 UTC, Murilo wrote:
Now, changing a little bit the subject. All FPs in D turn out
to be printed differently than they are in C and in C it comes
out a little more precise than in D. Is this really supposed to
happen?
Like I said in my first message, the
On Saturday, 9 February 2019 at 03:03:41 UTC, H. S. Teoh wrote:
On Sat, Feb 09, 2019 at 02:12:29AM +, Murilo via
Digitalmars-d-learn wrote:
Why is it that in C when I attribute the number
991234307654329925.7865 to a double it prints
991234299470108672. and in D it print
On Saturday, 9 February 2019 at 03:03:41 UTC, H. S. Teoh wrote:
It's not only because of converting decimal to binary, it's
also because double only has 64 bits to store information, and
your number has far more digits than can possibly fit into 64
bits.
Adding to that, here's a nice little o
On Sat, Feb 09, 2019 at 02:54:18AM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
[...]
> (The `real` thing in D was a massive mistake. It is slow and adds
> nothing but confusion.)
Yeah, it is also the only variable-width built-in type in D, which makes
it a wart in an otherwise elegant sys
On Saturday, 9 February 2019 at 02:54:18 UTC, Adam D. Ruppe wrote:
On Saturday, 9 February 2019 at 02:46:52 UTC, Murilo wrote:
But I used the type double in D which is supposed to be only
64 bits long and not 80 bits long, the type real is the one
which is supposed to be 80 bits long. Right?
On Sat, Feb 09, 2019 at 02:12:29AM +, Murilo via Digitalmars-d-learn wrote:
> Why is it that in C when I attribute the number
> 991234307654329925.7865 to a double it prints
> 991234299470108672. and in D it prints
> 9912342990. ? Apparently both language
On Saturday, 9 February 2019 at 02:46:52 UTC, Murilo wrote:
But I used the type double in D which is supposed to be only 64
bits long and not 80 bits long, the type real is the one which
is supposed to be 80 bits long. Right?
Right, BUT the compile time stuff is done before that.
double a = 1
On Saturday, 9 February 2019 at 02:42:09 UTC, Adam D. Ruppe wrote:
On Saturday, 9 February 2019 at 02:12:29 UTC, Murilo wrote:
prints
Two likely reasons: the D compiler does compile time stuff at
80 bit, whereas the C++ one probably uses 64 bit, and the D
default print rounds more aggressive
On Saturday, 9 February 2019 at 02:12:29 UTC, Murilo wrote:
prints
Two likely reasons: the D compiler does compile time stuff at 80
bit, whereas the C++ one probably uses 64 bit, and the D default
print rounds more aggressively than default C++ printing.
It is useful to put stuff in runtime
On Friday, February 8, 2019 4:27:44 AM MST Eduard Staniloiu via Digitalmars-
d-learn wrote:
> On Friday, 8 February 2019 at 06:55:15 UTC, Jerry wrote:
> > On Friday, 8 February 2019 at 04:51:08 UTC, Sudhi wrote:
> >> On Friday, 8 February 2019 at 04:30:23 UTC, Arun
> >>
> >> Chandrasekaran wrote:
>
Why is it that in C when I attribute the number
991234307654329925.7865 to a double it prints
991234299470108672. and in D it prints
9912342990. ? Apparently both languages cause
a certain loss of precision(which is part of converting the
decimal system
On Fri, Feb 08, 2019 at 11:36:03PM +, JN via Digitalmars-d-learn wrote:
> On Friday, 8 February 2019 at 23:30:44 UTC, H. S. Teoh wrote:
[...]
> > Pity we couldn't get rid of std.stdio.
[...]
> I can replace it with core.stdc.stdio if it's any better. Looks like
> any attempt to do a check for "
On Friday, 8 February 2019 at 23:30:44 UTC, H. S. Teoh wrote:
On Fri, Feb 08, 2019 at 10:45:39PM +, JN via
Digitalmars-d-learn wrote: [...]
Anyway, I reduced the code further manually. It's very hard to
reduce it any further. For example, removing the assignments
in fromEulerAngles static m
On Fri, Feb 08, 2019 at 10:45:39PM +, JN via Digitalmars-d-learn wrote:
[...]
> Anyway, I reduced the code further manually. It's very hard to reduce
> it any further. For example, removing the assignments in
> fromEulerAngles static method hides the bug. Likewise, replacing
> writeln with ass
On Friday, 8 February 2019 at 22:11:31 UTC, H. S. Teoh wrote:
Pity I still can't reproduce the problem locally. Otherwise I
would reduce it even more -- e.g., eliminate std.stdio
dependency and have the program fail on assert(obj != null),
and a bunch of other things to make it easier for compi
On Fri, Feb 08, 2019 at 09:42:11PM +, JN via Digitalmars-d-learn wrote:
> On Friday, 8 February 2019 at 21:35:34 UTC, H. S. Teoh wrote:
> > On Fri, Feb 08, 2019 at 09:23:40PM +, JN via Digitalmars-d-learn
> > wrote: [...]
> > > I managed to greatly reduce the source code. I have filed a bug
On Friday, 8 February 2019 at 21:35:34 UTC, H. S. Teoh wrote:
On Fri, Feb 08, 2019 at 09:23:40PM +, JN via
Digitalmars-d-learn wrote: [...]
I managed to greatly reduce the source code. I have filed a
bug with the reduced testcase
https://issues.dlang.org/show_bug.cgi?id=19662 .
Haha, you
On Fri, Feb 08, 2019 at 09:23:40PM +, JN via Digitalmars-d-learn wrote:
[...]
> I managed to greatly reduce the source code. I have filed a bug with
> the reduced testcase https://issues.dlang.org/show_bug.cgi?id=19662 .
Haha, you were right! It's a compiler bug, another one of those nasty
-O
On Friday, 8 February 2019 at 09:30:12 UTC, Vladimir Panteleev
wrote:
On Friday, 8 February 2019 at 09:28:48 UTC, JN wrote:
I will try. However, one last thing - in the example test
scripts, it runs first with one compiler setting (or D
version) and the second time with the other compiler setti
On Friday, 8 February 2019 at 15:42:13 UTC, Jonathan Levi wrote:
I should be able to use `core.memory.GC.removeRange` right?
That would leave dangling references in the array. You may be
interested in this, but I have not used it myself:
https://repo.or.cz/w/iv.d.git/blob/HEAD:/weakref.d
I have observers and listeners.
class Observer {
Listener[] listeners;
}
class Listener {}
The observers keep references to listeners, but I would like the
GC to garbage collect listeners even if observers have references
to it and remove the references in observers.
I should be able to u
On Friday, 8 February 2019 at 10:03:03 UTC, Ron Tarrant wrote:
On Thursday, 7 February 2019 at 08:41:29 UTC, Antonio Corbi
wrote:
Hi Ron,
xrandr (and gui interfaces for it like arandr) are your
friends here.
xrandr -q -> shows your card outputs and then you can use
xrandr + options to con
On Friday, 8 February 2019 at 06:55:15 UTC, Jerry wrote:
On Friday, 8 February 2019 at 04:51:08 UTC, Sudhi wrote:
On Friday, 8 February 2019 at 04:30:23 UTC, Arun
Chandrasekaran wrote:
On Friday, 8 February 2019 at 04:13:39 UTC, Sudhi wrote:
[...]
Works fine for me with DMD64 D Compiler v2.0
On Friday, 8 February 2019 at 09:19:12 UTC, rikki cattermole
wrote:
File, inconsistent behavior is inconsistent. Not good.
done: https://issues.dlang.org/show_bug.cgi?id=19660
On Thursday, 7 February 2019 at 08:41:29 UTC, Antonio Corbi wrote:
Hi Ron,
xrandr (and gui interfaces for it like arandr) are your friends
here.
xrandr -q -> shows your card outputs and then you can use
xrandr + options to configure monitors.
Or you can use arandr that will do that for yo
On Friday, 8 February 2019 at 09:28:48 UTC, JN wrote:
I will try. However, one last thing - in the example test
scripts, it runs first with one compiler setting (or D version)
and the second time with the other compiler setting (or D
version). But it looks like the exit code of the first run is
On Friday, 8 February 2019 at 07:30:41 UTC, Vladimir Panteleev
wrote:
On Thursday, 7 February 2019 at 22:16:19 UTC, JN wrote:
Does it also work for dub projects?
It will work if you can put all the relevant D code in one
directory, which is harder for Dub, as it likes to pull
dependencies fr
On 08/02/2019 9:14 PM, DanielG wrote:
On Friday, 8 February 2019 at 07:52:26 UTC, Kagamin wrote:
AFAIK, export attribute doesn't do much on posix platforms.
I created a minimal example and it definitely segfaults at runtime in
the presence of "export" (on Mac, haven't tested linux). So it's
On Friday, 8 February 2019 at 07:52:26 UTC, Kagamin wrote:
AFAIK, export attribute doesn't do much on posix platforms.
I created a minimal example and it definitely segfaults at
runtime in the presence of "export" (on Mac, haven't tested
linux). So it's required for Windows and silently evil
38 matches
Mail list logo
