On 22.07.19 14:49, drug wrote:
I have almost identical (I believe it at least) implementation (D and
C++) of the same algorithm that uses Kalman filtering. These
implementations though show different results (least significant
digits). Before I start investigating I would like to ask if this is
On Tuesday, 23 July 2019 at 00:54:08 UTC, aliak wrote:
On Tuesday, 23 July 2019 at 00:36:49 UTC, Exil wrote:
auto ref get(T)(W!T value) {
return value.front;
}
You're returning a reference to a temporary that gets deleted
at the end of the function's scope. The "auto ref" here will
be a "
On Tuesday, 23 July 2019 at 00:36:49 UTC, Exil wrote:
auto ref get(T)(W!T value) {
return value.front;
}
You're returning a reference to a temporary that gets deleted
at the end of the function's scope. The "auto ref" here will be
a "ref".
. oh ... shit you're right.
Ok so this
Shouldn't (stream == null) be (stream is null)?
-Eric
From: "adamgoldberg via Digitalmars-d-learn"
To: digitalmars-d-learn@puremagic.com
Sent: Monday, July 22, 2019 3:05:17 PM
Subject: Why does a switch break cause a segmentation fault
Hey, I just happened to be writing a program in D
auto ref get(T)(W!T value) {
return value.front;
}
You're returning a reference to a temporary that gets deleted at
the end of the function's scope. The "auto ref" here will be a
"ref".
Hi,
so I had this weird bug that was driving me crazy and only
segfaulted with ldc in release build - (I'm using ldc 1.16.0).
This is the code that segfaults. All parts seem to be necessary
for it to happen, or at least I think so. I've gone in circles
minimizing so I've probably missed some
On Monday, 22 July 2019 at 22:05:17 UTC, adamgoldberg wrote:
Hey, I just happened to be writing a program in D an stumbled
upon a bug, that causes it to terminate after receiving a SEGV
signal, nothing wierd so far but it looks everything I tried
shows it is the break statement inside of a swit
On 23/07/2019 9:34 AM, solidstate1991 wrote:
It seems that I've to write my own function that searches in the given
object's classinfo.interfaces since I couldn't find anything related in
Phobos.
if (Foo foo = cast(Bar)bar) {
}
Hey, I just happened to be writing a program in D an stumbled
upon a bug, that causes it to terminate after receiving a SEGV
signal, nothing wierd so far but it looks everything I tried
shows it is the break statement inside of a switch.
It seems to have a relatively random chance of occuring, a
It seems that I've to write my own function that searches in the
given object's classinfo.interfaces since I couldn't find
anything related in Phobos.
Am 22.07.19 um 20:38 schrieb Jonathan M Davis:
> On Monday, July 22, 2019 1:29:21 AM MDT Johannes Loher via Digitalmars-d-
> learn wrote:
>> Am 22.07.19 um 05:16 schrieb Paul Backus:
>>> On Sunday, 21 July 2019 at 18:03:33 UTC, Johannes Loher wrote:
I'd like to log stacktraces of caught except
On Monday, July 22, 2019 1:29:21 AM MDT Johannes Loher via Digitalmars-d-
learn wrote:
> Am 22.07.19 um 05:16 schrieb Paul Backus:
> > On Sunday, 21 July 2019 at 18:03:33 UTC, Johannes Loher wrote:
> >> I'd like to log stacktraces of caught exceptions in an @safe manner.
> >> However, Throwable.Tra
22.07.2019 17:19, drug пишет:
22.07.2019 16:26, Guillaume Piolat пишет:
Typical floating point operations in single-precision like a simple
(a * b) + c will provide a -140dB difference if order is changed.
It's likely the order of operations is not the same in your program,
so the least sign
22.07.2019 16:26, Guillaume Piolat пишет:
Typical floating point operations in single-precision like a simple (a
* b) + c will provide a -140dB difference if order is changed. It's
likely the order of operations is not the same in your program, so the
least significant digit should be differe
On Monday, 22 July 2019 at 12:49:24 UTC, drug wrote:
Before I start investigating I would like to ask if this issue
(different results of floating points calculation for D and
C++) is well known?
This likely has little to do with the language, and more with the
implementation. Basic floating
On Monday, 22 July 2019 at 13:23:26 UTC, Guillaume Piolat wrote:
On Monday, 22 July 2019 at 12:49:24 UTC, drug wrote:
I have almost identical (I believe it at least) implementation
(D and C++) of the same algorithm that uses Kalman filtering.
These implementations though show different results
On Monday, 22 July 2019 at 12:49:24 UTC, drug wrote:
I have almost identical (I believe it at least) implementation
(D and C++) of the same algorithm that uses Kalman filtering.
These implementations though show different results (least
significant digits). Before I start investigating I would
On 23/07/2019 12:58 AM, drug wrote:
22.07.2019 15:53, rikki cattermole пишет:
https://godbolt.org/z/EtZLG0
hmm, in short - this is my local problem?
That is not how I would describe it.
I would describe it as IEEE-754 doing what IEEE-754 is good at.
But my point is, you can get the results
On Monday, 22 July 2019 at 09:54:13 UTC, Jacob Carlborg wrote:
On 2019-07-19 22:16, Max Haughton wrote:
Isn't assert a template (file and line) rather than a plain
function call?
No. It's a keyword, it's built-in to the compiler. It get extra
benefits compared to a regular functions: the ass
22.07.2019 15:53, rikki cattermole пишет:
https://godbolt.org/z/EtZLG0
hmm, in short - this is my local problem?
On 23/07/2019 12:49 AM, drug wrote:
I have almost identical (I believe it at least) implementation (D and
C++) of the same algorithm that uses Kalman filtering. These
implementations though show different results (least significant
digits). Before I start investigating I would like to ask if th
I have almost identical (I believe it at least) implementation (D and
C++) of the same algorithm that uses Kalman filtering. These
implementations though show different results (least significant
digits). Before I start investigating I would like to ask if this issue
(different results of float
On 2019-07-19 22:16, Max Haughton wrote:
Isn't assert a template (file and line) rather than a plain function call?
No. It's a keyword, it's built-in to the compiler. It get extra benefits
compared to a regular functions: the asserts will be removed in release
builds.
--
/Jacob Carlborg
Am 22.07.19 um 05:16 schrieb Paul Backus:
> On Sunday, 21 July 2019 at 18:03:33 UTC, Johannes Loher wrote:
>> I'd like to log stacktraces of caught exceptions in an @safe manner.
>> However, Throwable.TraceInfo.toString is not @safe (or @trusted), so
>> this is not possible. Why is it not @safe? Ca
24 matches
Mail list logo
