On Wednesday, 20 February 2013 at 01:32:10 UTC, cal wrote:
On Wednesday, 20 February 2013 at 01:19:54 UTC, Ali Çehreli
wrote:
The example is wrong. a[4] throws an Error (not Exception) but
collectException catches Exception by default.
Additionally, the example is doing something that is
reco
On Wednesday, 20 February 2013 at 01:19:54 UTC, Ali Çehreli wrote:
The example is wrong. a[4] throws an Error (not Exception) but
collectException catches Exception by default.
Additionally, the example is doing something that is
recommended against: Catching Error or a descendent of it.
Sti
On 02/19/2013 04:38 PM, cal wrote:
> Is this example from the docs still meant to work?
>
> int[] a = new int[3];
> int b;
> assert(collectException(a[4], b));
The example is wrong. a[4] throws an Error (not Exception) but
collectException catches Exception by default.
Additionally, the exampl
I have, towards the start of my file:
/** Macros:
* Note = $(BR)$(BIG$(B$(GREEN Note:)))
* Todo = ToDo: $0
* Em = $(B$(BLUE $0))
* DoNotUse = $(B Do Not Use $0)
*/
Why do I need that DoNotUse macro to terminate the Em macro? If I don't
include it, the Em macro picks up the first line of
Is this example from the docs still meant to work?
int[] a = new int[3];
int b;
assert(collectException(a[4], b));
On 02/17/2013 09:32 PM, Ali Çehreli wrote:
On 02/17/2013 12:12 PM, jerro wrote:
> You don't need to cast it each time, you can do something like:
>
> auto structPointer = cast(MyStruct*) byteArray.ptr;
And that pointer can be converted to a D slice:
MyStruct[] slice = structPointer[0..numbe
Jos van Uden:
The chirality of the given output on Langtons ant doesn't
match what the code produces.
OK. I have changed the first entry.
Bye,
bearophile
monarch_dodra wrote:
In theory, there should be no reproducibility breakage, as the
generators themselves will not be changed (they are _strictly_
modeled after boosts' (the ones we have anyways)).
Indeed, I just looked at Boost and C++11 implementations, and
they currently have these divisio
Ivan Kazmenko:
Still, the current implementation uses divisions (which is slow
on most CPUs), and for a good source of random bits such as
MT19937, the implementation which repeatedly gets exactly
core.bitop.bsr(LIMIT)+1 bits until the result is in [0, LIMIT)
may be faster.
Is this to repor
On Tuesday, 19 February 2013 at 19:06:47 UTC, jerro wrote:
D doesn't use null termination for it's strings, strings are
immutable(char)[]. You can form a D slice from a pointer by
going
slice = ptr[0..length]
where length is the length of the array the pointer represents.
You can't just take a
On a side note, as D also uses MT19937 as the main RNG, random2
designers may want to address the same accuracy issue which
Python did. More on that topic here:
http://bugs.python.org/issue9025
Sorry for replying to myself again, but the abovementioned
accuracy issue is not about MT19937. I
On Tuesday, 19 February 2013 at 21:54:54 UTC, Ivan Kazmenko wrote:
monarch_dodra wrote:
void main()
{
uint[5] arr1;
arr1[].fill(rndGen);
uint[5] arr2;
arr2[].fill(rndGen);
writeln("arr1: ", arr1[]);
writeln("arr1: ", arr2[]);
}
//
arr1: [3622200385, 2579361262, 3208046123,
The chirality of the given output on Langtons ant doesn't match what
the code produces. (That's because somebody changed it a while ago).
See also the talk page.
http://rosettacode.org/wiki/Langton%27s_ant#D
monarch_dodra wrote:
void main()
{
uint[5] arr1;
arr1[].fill(rndGen);
uint[5] arr2;
arr2[].fill(rndGen);
writeln("arr1: ", arr1[]);
writeln("arr1: ", arr2[]);
}
//
arr1: [3622200385, 2579361262, 3208046123, 1753759120,
133131992]
arr2: [3622200385, 2579361262, 3208046
Joseph Rushton Wakeling wrote:
It's probably worth investigating the algorithms out there for
this kind of functionality, because I doubt the algorithm
that's given is optimal.
Given that the lazy version will hardly be possible without
allocating O(n) additional memory anyway, the simple sol
D code DLLs called by D code are heavly broken. Don't expect it
to work.
Any solid workarounds?
Is there a way to make this sort of thing work?
import std.algorithm;
struct S
{
int[] arr;
alias arr this;
}
void main()
{
auto s = S([1,2,3]);
sort(s); // error: template std.algorithm.sort does not
match any function
// template declaration. Candidates are...
D doesn't use null termination for it's strings, strings are
immutable(char)[]. You can form a D slice from a pointer by
going
slice = ptr[0..length]
where length is the length of the array the pointer represents.
You can't just take a c style string and expect writeln to work
with it.
You ca
Am 19.02.2013 00:27, schrieb deed:
I'm running into several issues, so first, is this supposed to work
correctly? I'm looking into D code DLLs called by D code.
D code DLLs called by D code are heavly broken. Don't expect it to work.
On Thursday, 14 February 2013 at 18:31:35 UTC, bioinfornatics
wrote:
Mr.Bio, what usage cases you'll be interested in, other than
those counters?
some idea such as letter counting:
rename identifier
trimming sequence from quality value to cutoff
convert to a binary format
convert to fasta + s
On Tuesday, 19 February 2013 at 16:23:45 UTC, Chris wrote:
I have written a DLL that I load into a Python program.
Everything works fine (DLL is loaded via ctypes, functions can
be called and are executed). Only the string handling is giving
me a bit of a headache. The string in D is always com
I have written a DLL that I load into a Python program.
Everything works fine (DLL is loaded via ctypes, functions can be
called and are executed). Only the string handling is giving me a
bit of a headache. The string in D is always complete garbage. I
have written Python modules in D (with C w
Le 19/02/2013 07:09, monarch_dodra a écrit :
On Tuesday, 19 February 2013 at 10:37:31 UTC, n00b wrote:
Hello.
--
MyType increment(MyType previous)
{
//snip
}
auto myRec = std.range.recurrence!increment(initialMyType);
-
... doesn't work. What am I doing wrong? The documentation doesn'
On Tuesday, 19 February 2013 at 01:59:45 UTC, Nick Sabalausky
wrote:
Consider these nested switches:
---
enum Foo {a, b}
enum Bar {bar}
auto foo = Foo.a;
auto bar = Bar.bar;
final switch(foo)
{
case Foo.a:
final switch(bar)
{
case Bar.bar:
XX
Hi folks,
The example of setting up a Win32 program in D is a great
starting point, but I have a concern about manually setting up
and tearing down the D runtime.
If myWinMain throws an exception that isn't caught, then it is
caught in WinMain instead. This causes us to miss the call to
Ru
On Tuesday, 19 February 2013 at 12:18:43 UTC, Joseph Rushton
Wakeling wrote:
On 02/19/2013 12:46 PM, Ivan Kazmenko wrote:
I'd like to note that my post is about randomCover, not
randomSample. I do see
the difference between the purpose of randomSample and
randomShuffle. But
randomCover's effe
On 02/19/2013 12:27 PM, monarch_dodra wrote:
Last but not least, be warned there is an old-standing bug with anything in
phobos that takes a PRNG by value. Basically, the PRNG will be duplicated, and
generate the same sequence over and over. Ergo, do NOT pass a specific random
generator to things
On Tuesday, 19 February 2013 at 11:46:54 UTC, Ivan Kazmenko wrote:
Hi!
Thank you for the reply.
Hum... randomShuffle and randomSample actually have nothing to
do with each other.
I'd like to note that my post is about randomCover, not
randomSample. I do see the difference between the pur
On 02/19/2013 12:46 PM, Ivan Kazmenko wrote:
I'd like to note that my post is about randomCover, not randomSample. I do see
the difference between the purpose of randomSample and randomShuffle. But
randomCover's effect is, at the first glance, just a slower version of
randomSample wrapped as a
On Tuesday, 19 February 2013 at 10:37:31 UTC, n00b wrote:
Hello.
--
MyType increment(MyType previous)
{
//snip
}
auto myRec = std.range.recurrence!increment(initialMyType);
-
... doesn't work. What am I doing wrong? The documentation
doesn't seem to imply the function has to b
Hi!
Thank you for the reply.
Hum... randomShuffle and randomSample actually have nothing to
do with each other.
I'd like to note that my post is about randomCover, not
randomSample. I do see the difference between the purpose of
randomSample and randomShuffle. But randomCover's effect i
On Tuesday, 19 February 2013 at 09:04:12 UTC, Ivan Kazmenko wrote:
Surely, because randomShuffle is re-ordering the elements
in-place, whereas randomCover is not.
Sorry, but that does not answer my question. If "in-place
shuffle" versus "function return value" was the only intended
differenc
Hello.
--
MyType increment(MyType previous)
{
//snip
}
auto myRec = std.range.recurrence!increment(initialMyType);
-
... doesn't work. What am I doing wrong? The documentation doesn't seem
to imply the function has to be passed as a string, if that's the issue.
I'm feeling the wind from Edsger Dijkstra spinning in his grave...
-=mike=-
"Nick Sabalausky" wrote in message
news:20130218205937.0768@unknown...
Consider these nested switches:
---
enum Foo {a, b}
enum Bar {bar}
auto foo = Foo.a;
auto bar = Bar.bar;
final swit
Surely, because randomShuffle is re-ordering the elements
in-place, whereas randomCover is not.
Sorry, but that does not answer my question. If "in-place
shuffle" versus "function return value" was the only intended
difference, randomCover could as well look like this (simplified
to int[] ca
35 matches
Mail list logo
