On Saturday, 3 March 2018 at 16:33:00 UTC, Martin Nowak wrote:
Doesn't really work that way, we can disable assertions, in
contracts, out contracts, and invariants. But not assertions in
some contexts while leaving them enabled in other contexts. At
least not without modifying all related codeg
On Sunday, 26 November 2017 at 12:09:37 UTC, rikki cattermole
wrote:
On 26/11/2017 11:59 AM, Joseph Rushton Wakeling wrote:
One suggestion: replace -release=assert with -release=body, so
in the above, you would have:
-release=body,in,out,invariant
... which has the nice intuitive
On Tuesday, 21 November 2017 at 14:15:30 UTC, Martin Nowak wrote:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md
Has come up a couple of times and it's a good idea to allow
more control over which checks are enabled.
I find the suggested switch levels a bit counter-intuitive and
wo
On Tuesday, 13 June 2017 at 09:42:43 UTC, Joakim wrote:
Also, it's possible others are still adding Glibc stuff as just
linux, as that's happened a couple times since then, but I
don't follow it and tell them to change it, as it usually
doesn't affect me on Android. If these are affecting you,
On Sunday, 4 June 2017 at 19:12:42 UTC, Jacob Carlborg wrote:
Erlang has the philosophy of share nothing between processes
(green processes), or task as you call it here. All allocations
are process local, that makes it easier to know that a failing
process doesn't affect any other process.
I
On Friday, 2 June 2017 at 15:19:29 UTC, Andrei Alexandrescu wrote:
Array bound accesses should be easy to intercept and have them
just kill the current thread.
Ideally, fiber, as well. Probably the real ideal for this sort
of problem is to be able to be as close as possible to Erlang,
where
On Wednesday, 10 May 2017 at 11:51:03 UTC, Atila Neves wrote:
So I went "I know, I'll just use a container". I tried Ubuntu
Zesty in docker. That doesn't build dmd off the bat either, it
fails with PIC errors.
Have you tried adding `PIC=-fPIC` when you invoke `make`?
On Tuesday, 9 May 2017 at 04:35:40 UTC, Ali Çehreli wrote:
Please list what we've achieved during the hackathon, including
what is started but is likely to be finished in the coming days
or months.
Created a working snap package definition for GDC. I'm
coordinating with Iain on how to get th
On Monday, 8 May 2017 at 20:45:57 UTC, Johan Engelen wrote:
Can we get a cool acronym / name for this thing? Helps when
talking with people about it. ;-)
DBeers? That's a diamond name ;-)
On Thursday, 27 April 2017 at 16:33:02 UTC, singingbush wrote:
SDL should be dropped.
Deprecated, sure. But dropping it seems a bad idea given that
various projects do still use it for their DUB package config.
NOBODY USES IT!
Probably not true. Perhaps a hackathon project could be to
On Friday, 14 April 2017 at 21:09:23 UTC, Walter Bright wrote:
Fundamentally changing the language is a major undertaking. The
language is complicated, there's a lot of baggage, and the
reason things are the way they are is usually unclear. Having a
handwavy post proposing such things is just n
On Thursday, 6 April 2017 at 19:27:50 UTC, Andrei Alexandrescu
wrote:
We commit to be more formal about the process, but overall it
is correct that we have more say in what gets in the language.
Allow me to add a couple of things.
First, this is the way things are commonly done in language
de
On Monday, 10 April 2017 at 22:07:11 UTC, Walter Bright wrote:
There are many. A random sampling:
Daniel Murphy - moving front end to D
Jacob Carlborg - Objective C support
Stephan Koch - newCTFE
Brad Roberts - autotester, bugzilla
the gdc and ldc teams
Rainer Schutze - GC work, Visual Studio su
On Wednesday, 12 April 2017 at 15:37:14 UTC, Mathias Lang wrote:
It was a conscious decision to provide something simple to use,
over something which allowed more control (good old KISS). If a
use case for it develop in the future, the addition will be
trivial.
Well, it's not simple to use if
On Monday, 10 April 2017 at 13:20:00 UTC, Matthias Klumpp wrote:
This has worked nicely for every language. If you don't have
templates in your API or don't change the templates between
releases, you can survive with one library for a long time.
But the vast majority of D libraries _do_ have t
On Sunday, 29 January 2017 at 20:07:50 UTC, Joseph Rushton
Wakeling wrote:
I started by trying to snap LDC, mainly because the cmake build
system made for a very easy integration with the snapcraft
package-build system. The LDC developers have been kind enough
to accept this as an official
On Friday, 3 February 2017 at 08:51:38 UTC, qznc wrote:
I just tried FlatPak and Snap. Snap is actually useable.
One of the first things that struck me about snap packaging was
the ease of its syntax and how straightforward it was to get
things working. I actually started creating snap packa
On Tuesday, 31 January 2017 at 05:41:38 UTC, Joakim wrote:
He can't read every forum thread, you should email him. That's
what I did when I got his permission to put dmd in FreeBSD
ports.
Yes, I understand that, and I was going to do so anyway. But I
was interested in any case in some more
On Monday, 30 January 2017 at 19:07:03 UTC, Nick Sabalausky wrote:
I don't understand where people keep getting that idea. It very
clearly states that all you need is to ask permission. It's
always been that way, and no reasonable request (or any at all
to my knowledge) has ever been denied.
On Monday, 30 January 2017 at 14:40:13 UTC, qznc wrote:
No comments? Well, there seems to be no downside (apart from
the work).
Yea, I'm a little sad to see the apparent lack of
feedback/interest :-\ I had quite a lot of fun creating these
packages and was hoping for a bit more curiosity.
Hello all,
I thought it might be time to share more generally something I've
been working on for a little while: snap packages for some of the
core D projects.
For those who don't know, snap packages are a new format
developed by Ubuntu to facilitate upstreams being able to provide
the late
On Sunday, 8 January 2017 at 13:16:29 UTC, Joseph Rushton
Wakeling wrote:
I'm asking for eyes on the problem because reducing it to a
minimal example appears non-trivial, while the bug itself looks
serious beyond its effect on this PR.
I underestimated myself :-P Minimal example
On Sunday, 8 January 2017 at 02:51:51 UTC, Andrei Alexandrescu
wrote:
This indicates a compiler bug in dmd itself, so the best
outcome for this library work would be a reduced compiler bug +
a simple library workaround. -- Andrei
Yes, that much is clear -- sorry if I wasn't clear enough myself
On Saturday, 26 November 2016 at 20:13:36 UTC, Andrei
Alexandrescu wrote:
On 11/26/16 11:31 AM, Ilya Yaroshenko wrote:
Hey,
32-bit Mt19937 random number Generator is default in Phobos.
It is default in Mir too, except that 64-bit targets use
64-bit Mt19937 instead.
Congrats! Also thanks for
On Friday, 16 December 2016 at 15:09:02 UTC, Ilya Yaroshenko
wrote:
And it should be builded this way whatever compiler and dub
options user use for his project.
It sounds like what is really needed here is the ability to
specify default build choices in `dub.json` (which the user could
then
On Wednesday, 14 December 2016 at 12:01:40 UTC, Mathias Lang
wrote:
That was my impression when reading this DIP. I'm very glad to
see that decoupling made its way up in the growing list of
things to do, my only concern is that this syntax sounds like a
workaround for giant modules.
Phobos is
On Friday, 9 December 2016 at 17:53:30 UTC, Matthias Klumpp wrote:
This issue should be fixed since LDC 1:1.1.0-2, which Xenial
doesn't have.
Ideally, fetch a newer version from Debian or a PPA to solve
this issue.
Is there any chance of getting a fix in Xenial itself (whether by
an update to
On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M Davis
wrote:
I say that when dealing with the built-in attributes, just
treat @ like another letter in the keyword, learn it, and move
on.
**Applause**
This is such a small thing and it is no problem at all to get
used to. Much bett
On Wednesday, 14 December 2016 at 07:17:57 UTC, Jacob Carlborg
wrote:
On 2016-12-14 03:23, Andrei Alexandrescu wrote:
On 12/13/16 9:22 PM, Hatem Oraby wrote:
with(import std.range)
bool equal(R1, R2) if (isInputRange!R1 && isInputRange!R2)
{ ... }
I considered this, then figured with is sup
On Saturday, 26 November 2016 at 16:31:40 UTC, Ilya Yaroshenko
wrote:
1. Improve RNG generation performance by making code more
friendly for CPU pipelining. Tempering (finalization)
operations was mixed with internal payload update operations.
A note on this. The `opCall` (or, in the range ve
On Tuesday, 13 December 2016 at 23:18:26 UTC, Ilya Yaroshenko
wrote:
* @Ilya, is this implementation your own design, or do you
have a reference
for the rationale behind this revised implementation of MT?
My own.
Congratulations, then -- I think this is a very interesting
rewrite of t
On Tuesday, 13 December 2016 at 18:15:25 UTC, Joseph Rushton
Wakeling wrote:
I'm going to try to put together a range-based version to see
if this also makes any difference. I'll post some benchmarks
of my own once that's done, and if all looks good I'll try to
put
On Saturday, 26 November 2016 at 20:13:36 UTC, Andrei
Alexandrescu wrote:
Congrats! Also thanks for using the Boost license which would
allow backporting the improvements to Phobos. Who'd be up for
it?
I've finally found a moment to look into this (I'm at home
recovering from a seasonal virus
On Thursday, 1 December 2016 at 15:28:28 UTC, Jethro wrote:
There is a problem with `distribution` in that it also has
other meanings.
Yes, but in context, is `random distribution` actually ambiguous?
What might people confuse it with?
`Random variable` is pretty well established
But is
On Wednesday, 30 November 2016 at 21:12:16 UTC, Ilya Yaroshenko
wrote:
"random distribution" is like "accidental distribution".
Not really. I would use "randomly chosen distribution" for that.
"random variable" is much more frequently used definition is
stats world (stats world != stats pack
On Wednesday, 30 November 2016 at 12:28:28 UTC, Ilya Yaroshenko
wrote:
Of course they can work with random devices. It looks strange
to me to have explicit API difference between engines and
devices. A random devices can be marked as random engines or we
can add a simple generic adaptor (Devic
On Tuesday, 29 November 2016 at 08:50:52 UTC, Ilya Yaroshenko
wrote:
The solution is to add a `hot` flag that indicates that
precomputed random values can be used and reset this flag in
copy constructor. It works without performance issues for the
Vitter's algorithm and Normal sampling (of cour
On Saturday, 26 November 2016 at 20:13:36 UTC, Andrei
Alexandrescu wrote:
Also I'm thinking of removing std.random's dependency on
druntime, e.g. by removing the uses of enforce. Thoughts?
There's no strong reason for those checks to be done via
`enforce` except for a design decision that user
On Saturday, 26 November 2016 at 06:55:24 UTC, Martin Nowak wrote:
Should we split off this discussion to a dlang-study thread?
I would personally really welcome that, but subject to the
understanding that people agree to look seriously at random
algorithms (like RandomSample) and not focus t
On Saturday, 26 November 2016 at 06:46:19 UTC, Martin Nowak wrote:
Yes the problems are inadvertent copies and a disabled
this(this) would prevent that. RNGs should have unique
ownership of their internal state.
Using InputRanges with phobos is somewhat clumsy. Maybe people
have been burned by
On Friday, 25 November 2016 at 16:08:15 UTC, Ilya Yaroshenko
wrote:
On Friday, 25 November 2016 at 16:04:07 UTC, Andrei
Alexandrescu wrote:
I'd say we can bury the hatchet and move on with Ilya's API.
-- Andrei
Yes, this was clear. There are also others who may disagree.
This is the reason fo
On Friday, 25 November 2016 at 15:56:45 UTC, Ilya Yaroshenko
wrote:
What kind of state should not be copied by value? I thought it
is only an Engine.
Unfortunately that's not true. The sampling algorithm pulls some
tricks to try to reduce the number of calls to the random number
generator (a
On Friday, 25 November 2016 at 15:04:24 UTC, Andrei Alexandrescu
wrote:
I thought I agreed that a noncopyable struct with opCall is
fine in conjunction with a range API adapter that uses a
pointer. -- Andrei
FWIW, I suspect that Ilya means simply that it became long and
convoluted, not that a
On Friday, 25 November 2016 at 14:27:13 UTC, Ilya Yaroshenko
wrote:
The discussion [2] about Mir Random [1] and Range API become a
holy war [2]. I am putting the following example here. It also
can be found at GitHub[1].
It's not a holy war, but your code example doesn't really address
the ke
On Wednesday, 23 November 2016 at 21:19:51 UTC, Jonathan M Davis
wrote:
It's quite feasible if you don't calculate front until it's
called or popFront is called, and then you cache the result so
that subsequent calls to front prior to the call to popFront
return the same result, but it creates
On Thursday, 24 November 2016 at 08:36:41 UTC, Andrea Fontana
wrote:
On Wednesday, 23 November 2016 at 17:31:58 UTC, Kagamin wrote:
On Wednesday, 23 November 2016 at 01:28:11 UTC, Andrei
Alexandrescu wrote:
Interesting. Could you please add a couple of links about
that? -- Andrei
http://xoros
On Wednesday, 23 November 2016 at 15:25:29 UTC, Kagamin wrote:
struct A
{
bool empty;
int front;
void popFront(){}
@disable this(this);
}
import std.algorithm;
void f()
{
A r;
auto m=r.map!(a=>1);
}
Does this compile for you?
auto m = (&r).map!(
On Wednesday, 23 November 2016 at 13:56:27 UTC, Andrei
Alexandrescu wrote:
Well I do see another small problem with
https://github.com/libmir/mir-random/blob/master/source/random/algorithm.d#L19. It creates the first value eagerly upon construction. That's just a bit awkward. It's not the first t
On Wednesday, 23 November 2016 at 13:44:00 UTC, Andrei
Alexandrescu wrote:
Well we need to get to the bottom of this if we're to make
progress. Otherwise it's copypasta with little changes followed
by disappointment all the way down. -- Andrei
Would you be up for a direct discussion of this so
On Wednesday, 23 November 2016 at 13:35:33 UTC, Ilya Yaroshenko
wrote:
1. Current default RNG (Mt19937) has not state for the latest
value.
That's a detail of your implementation, though, and it's not true
for lots of other pseudo-RNGs.
2. The structure is allocated on stack and compilers ca
On Wednesday, 23 November 2016 at 13:01:22 UTC, Andrea Fontana
wrote:
I wonder why Mersenne Twister is *always* choosen over other
algorithms.
The weight of history, I suspect. Mersenne Twister was the major
new high-quality RNG back when people started getting really
concerned about having
On Wednesday, 23 November 2016 at 13:03:04 UTC, Ilya Yaroshenko
wrote:
Added RandomRangeAdaptor for URBGs:
https://github.com/libmir/mir-random/blob/master/source/random/algorithm.d
This has exactly the problem I identified above, though: you're
unnecessarily cacheing the latest variate rather
On Wednesday, 23 November 2016 at 11:14:38 UTC, Ilya Yaroshenko
wrote:
For example, Mir Random basic utilities (more low level then
distributions):
https://github.com/libmir/mir-random/blob/master/source/random/package.d
Also you can explore std.random code. opCall would almost
always more con
On Wednesday, 23 November 2016 at 11:03:33 UTC, Ilya Yaroshenko
wrote:
It is only question of `Random` alias, which can be changed in
the future anyway. Both Mt19937_32 and Mt19937_64 are defined.
I think we're at an impasse in terms of priorities, because
that's exactly the reason that I thin
On Wednesday, 23 November 2016 at 05:58:47 UTC, Ilya Yaroshenko
wrote:
It is safe low level architecture without performance and API
issues. It prevents users to do stupid things implicitly (like
copying RNGs). A hight level range interface can be added in
the future (it will hold a _pointer_ t
On Wednesday, 23 November 2016 at 01:34:23 UTC, Andrei
Alexandrescu wrote:
I'm unclear on what that statistically unsafe default behavior
is - my understanding is it has to do with RNGs being
inadvertently copied. It would be great to formalize that in a
well-explained issue.
I'll see if I ca
On Wednesday, 23 November 2016 at 05:26:12 UTC, Ilya Yaroshenko
wrote:
Mir Random is going to be a library with saturated uniform FP
RNGs and almost saturated exponential FP RNGs. Comparing with
all other libraries (any language) the basic uniform FP numbers
will be generated in interval (-1, +
On Wednesday, 23 November 2016 at 05:58:47 UTC, Ilya Yaroshenko
wrote:
### Example of API+implementation bug:
Bug: RNGs has min and max params (hello C++). But, they
are not used when an uniform integer number is generated :
`uniform!ulong` / `uniform!ulong(0, 100)`.
Solution: In M
On Tuesday, 22 November 2016 at 06:31:45 UTC, Ilya Yaroshenko
wrote:
- 64-bit Mt19937 is default for 64-bit targets
This means that seemingly identical code will produce different
results depending on whether it's compiled for 64-bit or 32-bit.
Is that really worth it, when anyone who cares
On Tuesday, 22 November 2016 at 06:31:45 UTC, Ilya Yaroshenko
wrote:
# Integer uniform generators
[WIP]
# Real uniform generators
[WIP]
# Nonuniform generators
[WIP]
As we discussed in relation to Seb's project, I think this is a
problematic conceptualization of the best way to s
On Tuesday, 22 November 2016 at 23:55:01 UTC, Andrei Alexandrescu
wrote:
On 11/22/16 1:31 AM, Ilya Yaroshenko wrote:
- `opCall` API instead of range interface is used (similar to
C++)
This seems like a gratuitous departure from common D practice.
Random number generators are most naturally m
On Monday, 26 September 2016 at 11:32:20 UTC, Ilya Yaroshenko
wrote:
Updated:
Mir is LLVM-Accelerated Generic Numerical Library for Science
and Machine Learning. It requires LDC (LLVM D Compiler) for
compilation. Mir GLAS (Generic Linear Algebra Subprograms) has
a single generic kernel for all
On Saturday, 24 September 2016 at 07:20:25 UTC, Ilya Yaroshenko
wrote:
Please help to improve the blog post during this weekend. It
will be announced in the Reddit.
One other place that a little more explanation could be helpful
is this sentence:
"It is written completely in D for LDC (LLVM
On Monday, 26 September 2016 at 10:01:44 UTC, Ilya Yaroshenko
wrote:
I mean that for single precision numbers I have 2 charts
(normal and normalized).
Ah, OK. Would still be nice to have a note, though, on how the
numbers in the charts are generated, i.e. are they the result of
a single run,
On Saturday, 24 September 2016 at 09:14:38 UTC, Ilya Yaroshenko
wrote:
Please use `dub build ...` and then run report at least 2
times, and choice a better one.
Is this what you mean by your description of the results as e.g.
"single precision numbers x2", "double precision numbers x2",
etc.?
On Sunday, 25 September 2016 at 10:45:35 UTC, Ilya Yaroshenko
wrote:
Thank for the review! I have added notes about Eigen and CBLAS
interface example.
One extra suggestion:
"Mir GLAS has native mir.ndslice interface" -> "Mir GLAS has a
native mir.ndslice interface"
I would also suggest addi
On Sunday, 25 September 2016 at 23:03:27 UTC, Ali Çehreli wrote:
Stay in touch with the lastest developments in scientific
computing for D. ->
(I will let others recommend something better there but neither
"stay in touch" nor "lastest" sounds right to my ears. :) )
"lastest" -> "latest" ... ?
On Thursday, 22 September 2016 at 05:38:53 UTC, HaraldZealot
wrote:
So it seems to be essential point. But because we already have
the same problem with UFCS, I don't see why we should prohibit
external overloading of operator, it is just inequality (in
political sense) for operators :)
I'm n
On Wednesday, 7 September 2016 at 22:31:17 UTC, Walter Bright
wrote:
On 9/7/2016 3:24 PM, John Colvin wrote:
What, precisely, does "valid" mean in the above?
S is initialized to a valid state, meaning the fields are not
filled with garbage, and are in a state expected by the member
functions
On Tuesday, 23 August 2016 at 17:58:31 UTC, Steven Schveighoffer
wrote:
On 8/23/16 1:46 PM, Andrei Alexandrescu wrote:
* In an extra twinge of irony, the link to the package format
specification goes to
http://code.dlang.org/package-format?lang=json,
i.e. the JSON format. Which is of course not
On Tuesday, 31 May 2016 at 18:31:05 UTC, Steven Schveighoffer
wrote:
On 5/31/16 11:45 AM, Jonathan M Davis via Digitalmars-d wrote:
On Monday, May 30, 2016 09:57:29 H. S. Teoh via Digitalmars-d
wrote:
I'd argue that range-based generic code that assumes
non-transience is
inherently buggy, beca
On Sunday, 29 May 2016 at 17:29:35 UTC, Steven Schveighoffer
wrote:
This doesn't help at all. I can still make a "transient" range
with all three range primitives.
There seems to be a misunderstanding about what a transient
range is.
byLine is a transient range that requires the front elemen
On Sunday, 29 May 2016 at 11:28:11 UTC, ZombineDev wrote:
On Sunday, 29 May 2016 at 11:15:19 UTC, Dicebot wrote:
I would prefer such ranges to not have `front` and return new
item from `popFront` instead but yes, I would much prefer it
to existing form, transient or not. It is impossible to
co
On Saturday, 28 May 2016 at 21:32:15 UTC, Brad Roberts wrote:
On 5/28/2016 10:27 AM, Joseph Rushton Wakeling via
Digitalmars-d wrote:
On Saturday, 28 May 2016 at 01:48:08 UTC, Jonathan M Davis
wrote:
On Friday, May 27, 2016 23:42:24 Seb via Digitalmars-d wrote:
So what about the convention to
On Saturday, 28 May 2016 at 18:30:03 UTC, Seb wrote:
On Saturday, 28 May 2016 at 18:11:16 UTC, Joseph Rushton
Wakeling wrote:
Copyright is extremely under-reported for Phobos, in my
experience -- authors of significant components of modules do
not necessarily add their name to the copyright
On Saturday, 28 May 2016 at 17:50:46 UTC, Seb wrote:
Now that D foundation finally got its own page [1], it's
probably time to start this dicussion.
Is it safe to assume that the entire Phobos source code (except
for the external C modules), belongs to the D foundation?
No, not at all, and you
On Saturday, 28 May 2016 at 01:48:08 UTC, Jonathan M Davis wrote:
On Friday, May 27, 2016 23:42:24 Seb via Digitalmars-d wrote:
So what about the convention to explicitely declare a
`.transient` enum member on a range, if the front element
value can change?
Honestly, I don't think that suppor
On Thursday, 19 May 2016 at 11:33:38 UTC, Joakim wrote:
The example he refers to is laughable because it also checks
for equality.
With good reason, because it's intended to illustrate the point
that two calculations that _look_ identical in code, that
intuitively should produce identical res
On Wednesday, 18 May 2016 at 23:09:28 UTC, Walter Bright wrote:
Now try the square root of 2. Or pi, e, etc. The irrational
numbers are, by definition, not representable as a ratio.
Continued fraction? :-)
On Wednesday, 18 May 2016 at 20:29:27 UTC, Walter Bright wrote:
I do not understand the tolerance for bad results in
scientific, engineering, medical, or finance applications.
I don't think anyone has suggested tolerance for bad results in
any of those applications.
What _has_ been argued fo
On Wednesday, 18 May 2016 at 09:21:30 UTC, Ola Fosheim Grøstad
wrote:
No. The "const float y" will not be coerced to 32 bit, but the
"float y" will be coerced to 32 bit. So you get two different y
values. (On a specific compiler, i.e. DMD.)
I'm not sure that the `const float` vs `float` is the
On Tuesday, 10 May 2016 at 07:28:21 UTC, Manu wrote:
Perhaps float comparison should *always* be done at the lower
precision? There's no meaningful way to perform a float/double
comparison where the float is promoted, whereas demoting the
double for the comparison will almost certainly yield th
On Monday, 16 May 2016 at 11:18:45 UTC, Joseph Rushton Wakeling
wrote:
As Adam mentioned, you keep saying "correctness" or "accuracy"
... meant to say '"correctness" or "precision"'.
On Monday, 16 May 2016 at 10:57:00 UTC, Walter Bright wrote:
On 5/16/2016 3:14 AM, Joseph Rushton Wakeling wrote:
1.299523162841796875
1.3000444089209850062616169452667236328125
Note the increase in correctness of the result by 10 digits.
As Adam mentioned, you keep saying
On Monday, 16 May 2016 at 09:56:07 UTC, Walter Bright wrote:
What you call "illegitimate" are really just legitimate
examples that you
dismiss because they do not match your own specific experience.
Of course, legitimate is a matter of opinion. Can code be
written to rely on lower precision?
On Monday, 16 May 2016 at 09:54:51 UTC, Iain Buclaw wrote:
On 16 May 2016 at 10:52, Ola Fosheim Grøstad via Digitalmars-d
wrote:
On Monday, 16 May 2016 at 08:47:03 UTC, Iain Buclaw wrote:
But you *didn't* request coercion to 32 bit floats.
Otherwise you would have used 1.30f.
con
On Monday, 16 May 2016 at 08:52:16 UTC, Ola Fosheim Grøstad wrote:
On Monday, 16 May 2016 at 08:47:03 UTC, Iain Buclaw wrote:
But you *didn't* request coercion to 32 bit floats. Otherwise
you would have used 1.30f.
const float f = 1.3f;
float c = f;
assert(c*1.0 == f*1
On Sunday, 15 May 2016 at 18:30:20 UTC, Walter Bright wrote:
If you wrote it "to not break if the floating-point precision
is enhanced, and to allow greater precision to be used when the
hardware supports it" then what's the problem?
Can you provide an example of a legitimate algorithm that
p
On Saturday, 14 May 2016 at 15:25:58 UTC, Brian wrote:
Project:
https://github.com/putao-dev/google-flatbuffers
Pull address:
https://github.com/google/flatbuffers/pull/3856
dub project:
http://code.dlang.org/packages/flatbuffers
Nice to see someone working on this! A few general bits of
fe
On Saturday, 14 May 2016 at 18:46:50 UTC, Walter Bright wrote:
On 5/14/2016 3:16 AM, John Colvin wrote:
This is all quite discouraging from a scientific programmers
point of view.
Precision is important, more precision is good, but
reproducibility and
predictability are critical.
I used to d
A few people asked about bike rental. I can't vouch for anyone
myself, but friends have told me these folks have a good
reputation:
https://www.facebook.com/RentABike44/
They're over on Mahlower Straße 9:
https://www.google.de/maps/place/Rent+a+Bike+44+in+Berlin+Neuk%C3%B6lln/@52.4797042,13.42
On Saturday, 7 May 2016 at 09:24:13 UTC, Adrian Matoga wrote:
On Saturday, 7 May 2016 at 08:55:50 UTC, Joseph Rushton
Wakeling wrote:
Hello all,
For anyone who's still in town and fancies grabbing a nice
late breakfast/early lunch in a nice Berlin food place, I'll
be doing my usua
Hello all,
For anyone who's still in town and fancies grabbing a nice late
breakfast/early lunch in a nice Berlin food place, I'll be doing
my usual Saturday morning thing of dropping by this
cafe/restaurant at about 11:30:
https://www.google.de/maps/place/Papilles/@52.4811843,13.4279886,17z/
On Thursday, 5 May 2016 at 12:48:04 UTC, Nafees wrote:
I recently upgraded to ubuntu 16.04 LTS from 14.04 LTS. I
formatted the whole HDD, when I reinstalled all my stuff, DUB
won't work. When I type "dub" into the terminal, this is what
shows up: "dub: error while loading shared libraries:
lib
On Wednesday, 27 April 2016 at 02:57:47 UTC, Walter Bright wrote:
To prepare for a week in Berlin, a few German phrases is all
you'll need to fit in, get around, and have a great time:
1. Ein Bier bitte!
2. Noch ein Bier bitte!
3. Wo ist der WC!
Kein Bier vor vier ;-)
On Saturday, 23 April 2016 at 19:53:38 UTC, Andrei Alexandrescu
wrote:
On 04/23/2016 03:50 PM, ag0aep6g wrote:
On 23.04.2016 21:43, Andrei Alexandrescu wrote:
http://dlang.org/phobos/std_experimental_allocator_building_blocks_affix_allocator.html#.AffixAllocator.goodAllocSize
Looks like almost
On Saturday, 23 April 2016 at 14:17:19 UTC, Seb wrote:
I am very proud to be selected as a GSoC stipend for the D
foundation.
Congratulations, Seb!
This project is about adding non-uniform random generators to
mir and hopefully eventually to Phobos.
This is a very welcome contribution. Tha
On Saturday, 23 April 2016 at 13:57:28 UTC, Andrei Alexandrescu
wrote:
I think it should have a separate page on dlang.org (no
subdomain necessary), e.g. https://dlang.org/foundation. --
Personally I'd see the use of a subdomain as a useful way to
separate between pages about the language vers
On Saturday, 23 April 2016 at 09:57:20 UTC, Ilya Yaroshenko wrote:
On Friday, 22 April 2016 at 22:11:27 UTC, Joseph Rushton
Wakeling wrote:
On Sunday, 17 April 2016 at 09:09:52 UTC, Ilya Yaroshenko
wrote:
On Sunday, 17 April 2016 at 08:49:53 UTC, Seb wrote:
On Sunday, 17 April 2016 at 07:35:19
On Sunday, 17 April 2016 at 09:09:52 UTC, Ilya Yaroshenko wrote:
On Sunday, 17 April 2016 at 08:49:53 UTC, Seb wrote:
On Sunday, 17 April 2016 at 07:35:19 UTC, Ilya Yaroshenko
wrote:
On Sunday, 17 April 2016 at 07:30:38 UTC, Vladimir Panteleev
I don't understand, what's wrong with std.sci or e
1 - 100 of 1231 matches
Mail list logo
