Re: Multiple %s format specifiers with a single argument
Am Thu, 12 Apr 2012 13:11:16 +1200 schrieb James Miller ja...@aatch.net: Its less using the email interface, and more people using braindead email clients. Gmail and Mutt (the two I use most) seem to handle replying well, setting the correct headers to indicate things. But I've seen some odd postings from people posting using things like Windows Live Mail. And it seems that Outlook Express is better at mailing lists than Outlook, which is strange... -- James Miller Well, I found Claws-Mail to actually fix up behind broken mail clients, by merging discussions with the same title. I switched from Opera to CM a while ago. It also offers a search by a list of criteria that downloads missing message bodies lazily on a full-text search. It starts up almost instantly, but takes a few seconds to load the 160.000 messages of this group, fixing up split discussions on the way. ;) Also I found that Opera Mail had a good set of default settings, while in Claws it took me a while to understand its configuration options. Haven't tried other clients (except for Evolution, which was no improvement over Opera). -- Marco
Re: stdout redirect
On Wednesday, 11 April 2012 at 15:25:56 UTC, Stefan wrote: On Wednesday, 11 April 2012 at 13:00:45 UTC, Andrea Fontana wrote: On Wednesday, 11 April 2012 at 12:46:30 UTC, Andrea Fontana wrote: How can I redirect stdout / stderr to file (from D not shell)? Self-reply: It works using std.c way: import std.cstream; std.c.stdio.freopen(args[4].ptr, w+, dout.file); std.c.stdio.freopen(args[4].ptr, w+, derr.file); Careful: D strings are not zero-terminated. args[4].toStringz() is the safer choice. Cheers, Stefan Good point Stefan!
Re: D Dll injection problem
I tried again with a few other random C dll's stolen around my system and they all work perfectly. it's only the D dll that gives me trouble.
Re: Name of files causes error. Why?
On Wednesday, 11 April 2012 at 19:50:18 UTC, Steven Schveighoffer wrote: On Wed, 11 Apr 2012 15:33:56 -0400, Xan xancor...@gmail.com wrote: Hi, With helloworld program named with score or underscore, I receive the following __annoying__ error: $ gdmd-4.6 hola-temp.d hola-temp.d: Error: module hola-temp has non-identifier characters in filename, use module declaration instead Why? Can someone fix it. It's really annoying Thanks in advance, Xan. All d module files (i.e. d source files) must be a valid identifier. See this document for what an identifier can contain: http://dlang.org/lex.html#Identifier Now, you *can* possibly name the module differently using a module statement, but this is highly discouraged. If you do this, the only way another module can import your differently-named module is if you pass the file on the command line. -Steve But it's a messy limitation. Why we should have it? For C++ compatibilities? Thanks,
Re: Static Associative Arrays
Jonathan M Davis , dans le message (digitalmars.D.learn:34332), a écrit : On Sunday, April 08, 2012 01:24:02 Caligo wrote: On Sat, Apr 7, 2012 at 11:01 PM, Jonathan M Davis jmdavisp...@gmx.com wrote: What do you mean my static associative arrays? Are you asking why you can't initialize a static variable which is an AA at compile time? e.g. - Jonathan M Davis The same way I can create a static array: int[4] = [1, 3, 4, 8]; // has value semantics and dynamic arrays: int[] = [1, 4, 2, 4]; // has reference semantics I want an associative array that has value semantics and it's size doesn't change, just like static arrays. Associative arrays are always on the heap. They always have reference semantics. It would be very expensive to have an AA with value semantics. They contains pointers all over the place. It would be equivalent to calling dup on them every time that you pass them to anything. And trying to put one on the stack would get very messy because all of the pointers involved. AAs are _completely_ different from dynamic and static arrays. Aside from the fact that they both have array in their name and both allow indexing of a sort, there's really no relation between them at all. Yet, one could imagine an associative array with a fixed size and fixed indexes, with no pointers. We could define a simple structure with a static array to store the data and methods to find the element associated with a key. But we could not use this structure in place of a classic associative array (for that we would need pointers obviously).
Re: Name of files causes error. Why?
Xan wrote: But it's a messy limitation. On the contrary: it requires work to implement limitations. Therefore limitations are implemented only to shield users from mess. Not having descovered any benefit of a limitation might point to insufficient empirical knowledge. -manfred
Re: Name of files causes error. Why?
On Thu, 12 Apr 2012 08:30:50 -0400, Xan xancor...@gmail.com wrote: On Wednesday, 11 April 2012 at 19:50:18 UTC, Steven Schveighoffer wrote: Now, you *can* possibly name the module differently using a module statement, but this is highly discouraged. If you do this, the only way another module can import your differently-named module is if you pass the file on the command line. But it's a messy limitation. Why we should have it? For C++ compatibilities? No. C++ has no requirements for file names. But C++ also doesn't have a module system. There are many benefits we get from having an actual module system. For instance, D doesn't need namespaces. The requirement is pretty straightforward -- name your module files after the modules they contain. It works pretty well in many module-oriented languages, such as Java and C#, and I would argue D. -Steve
Question Object.factory and namespaces.
Hello.
I am reading through TDPL by Andresscu. The book has the
following example, which I am abbreviating:
void main( string[] args) {
Stat [] stats;
foreach( arg; args[1..$]) {
auto newStat = cast(Stat) Object.factory( statsinc04. ~
arg);
enforce( newStat, Invalid statistical function: ~ arg);
stats ~= newStat;
}
My module is called statsinc04.d and you can see it listed above
in the foreach loop. My question is, how do I change the code
above so that it works even if I change the name of the
file/module? I'm looking for clean solution something like a
macro if one actually exists.
Thanks.
Re: D Dll injection problem
#include windows.h
void main()
{
LPTHREAD_START_ROUTINE LoadLibAddy =
(LPTHREAD_START_ROUTINE)GetProcAddress(GetModuleHandle(kernel32.dll),
LoadLibraryA);
CreateThread(NULL,0,LoadLibAddy,mydll.dll,0,NULL);
}
?
Re: D Dll injection problem
works and GetLastError() returns 0 in both cases.
Op 12 april 2012 16:13 schreef Kagamin s...@here.lot het volgende:
#include windows.h
void main()
{
LPTHREAD_START_ROUTINE LoadLibAddy = (LPTHREAD_START_ROUTINE)**
GetProcAddress(**GetModuleHandle(kernel32.dll**), LoadLibraryA);
CreateThread(NULL,0,**LoadLibAddy,mydll.dll,0,**NULL);
}
?
Sampling algorithms for D
Hello all, My programming experience is mostly in C with some C++, so much of the programming style of D is not familiar to me. With that in mind, I thought I'd set up a little pet project to try and learn good D programming style. What I thought I'd do is implement some clever algorithms for random sampling which I've already done in a C based on the GNU Scientific Library. The D implementation is (in very primitive form) at: https://github.com/WebDrake/SampleD ... and I'm using GDC 4.6.3 on Ubuntu 12.04 as my compiler. The basic challenge here is that, given a collection of N records, we want to take a sample of size n N such that the chance of any given record being picked is equal. The algorithms implemented are based on the notion of generating a series of random skips across the sequence of records, picking the records you land on. The idea is that one initializes the algorithm by giving the total number of records and the sample size required. The sampler provides a method, select(), which when called picks the next entry in the sample, up to the total number required; if you keep calling it when the sample is complete, it throws an error. Consequently, these algorithms don't store the entire sample, or the collection of records (which are just assumed to be labelled 0, 1, 2, ..., N-1). Rather, it just outputs, one by one as called upon, the indices of the selected records. So, introduction away, here are the main questions I came up with in creating the code. (1) Effective handling of random numbers. The design concept was for the sampler classes to use a specified uniform random number generator if provided, otherwise to use rndGen. This turned out to be trickier than anticipated, and I'm not very happy with the current solution. My first attempt just templatized class methods select() and skip(). However, one of the algorithms (class VitterD) requires random initialization as well, and trying to template this() ran into this bug: http://d.puremagic.com/issues/show_bug.cgi?id=435 I'm really not too happy with turning the whole class into a template just for the sake of the random number generator, so can anyone suggest an effective way to resolve the problem? (I may be biased here by C/GSL experience, where I've got used to passing the RNG as a pointer, meaning runtime polymorphism.) (2) init() function? I was unsure whether it would be good design practice for the sampler classes to be throwaway (1 instance = 1 use) or to put in place an init() function that would reset it with new record and sample sizes. Any thoughts? (3) Uniform random number on (0,1) The algorithms' specification explicitly refers to uniform random numbers on the open interval, which I take to mean (0,1) i.e. excluding zero. Phobos currently provides only a half-open uniform distribution on [a,b). I've implemented a simple uniform_open() function which should return a uniform distribution on (a,b). The question is, are there any plans for an open-interval uniform distribution in Phobos? Can I rely on this functionality being provided in the long term in D's standard library? (4) Truncation The code uses C's trunc() function to return the integer part of a floating point number. D doesn't seem to like it very much when I then set a size_t as equal to the result of trunc(), and I have to use a type cast. Is there a more elegant D-ish way of achieving the same result? roundTo() isn't adequate, as it rounds to the _nearest_ integer rather than the integer part. (5) ... any general stylistic comments? :-) Thanks and best wishes, -- Joe
Re: Passing function as values and returning functions
* Xan xancor...@gmail.com [2012-04-11 20:28:38 +0200]: On Wednesday, 11 April 2012 at 13:04:01 UTC, Steven Schveighoffer wrote: On Wed, 11 Apr 2012 08:53:00 -0400, Xan xancor...@gmail.com wrote: [snip] writeln(g(f)(1)); Unlike C, you *must* take the address of a function symbol to get a function pointer. -Steve Yes, it works, finally. Thanks, Steve. Xan. Glad you got help Xan, but for future reference can you please keep questions to D.learn? It is somewhat frustrating to see the question How do I do that? on this list, since it is for discussion, and high-level questions, not for people that are learning D. (High level questions being along the lines of What changes need to be made in dmd to support the new AA implementation?) -- James Miller
Re: Passing function as values and returning functions
* James Miller ja...@aatch.net [2012-04-13 02:49:03 +1200]: Glad you got help Xan, but for future reference can you please keep questions to D.learn? It is somewhat frustrating to see the question How do I do that? on this list, since it is for discussion, and high-level questions, not for people that are learning D. (High level questions being along the lines of What changes need to be made in dmd to support the new AA implementation?) And now I look like an asshole because I wasn't paying attention to the mailbox I was in. Ignore me, I'm an idiot... -- James Miller
Re: Passing function as values and returning functions
On Thu, 12 Apr 2012 10:49:03 -0400, James Miller ja...@aatch.net wrote: Glad you got help Xan, but for future reference can you please keep questions to D.learn? It is somewhat frustrating to see the question How do I do that? on this list, since it is for discussion, and high-level questions, not for people that are learning D. Um... this is d.learn... -Steve
Re: Question Object.factory and namespaces.
On Thu, 12 Apr 2012 16:11:11 +0200, dcoder wrote: My question is, how do I change the code above so that it works even if I change the name of the file/module? I'm looking for clean solution something like a macro if one actually exists. Check out packageName, moduleName, and fullyQualifiedName in std.traits. Additionally, the __FILE__ token will be expanded to the name of the current file. Justin
Re: Sampling algorithms for D
On 12.04.2012 18:45, Joseph Rushton Wakeling wrote:
Hello all,
Hello there,
[snip]
So, introduction away, here are the main questions I came up with in
creating the code.
(1) Effective handling of random numbers.
The design concept was for the sampler classes to use a specified
uniform random number generator if provided, otherwise to use rndGen.
This turned out to be trickier than anticipated, and I'm not very happy
with the current solution.
My first attempt just templatized class methods select() and skip().
However, one of the algorithms (class VitterD) requires random
initialization as well, and trying to template this() ran into this bug:
http://d.puremagic.com/issues/show_bug.cgi?id=435
I'm really not too happy with turning the whole class into a template
just for the sake of the random number generator, so can anyone suggest
an effective way to resolve the problem?
(I may be biased here by C/GSL experience, where I've got used to
passing the RNG as a pointer, meaning runtime polymorphism.)
I think that if you like function pointer thing, you'd love D's
delegates and lambdas. If templates are too pervasive it might be better
just use little bit of dynamic stuff.
e.g.
Mt19937 gen;
double delegate() rng = (){
auto x = gen.front;
gen.popFron();
return x;
}
use it somewhere later on:
writeln(rng(), rng()); // print 2 random numbers
(2) init() function?
I was unsure whether it would be good design practice for the sampler
classes to be throwaway (1 instance = 1 use) or to put in place an
init() function that would reset it with new record and sample sizes.
Any thoughts?
Use structs? They are cheap throwway value types allocated on stack (by
default).
(3) Uniform random number on (0,1)
The algorithms' specification explicitly refers to uniform random
numbers on the open interval, which I take to mean (0,1) i.e. excluding
zero. Phobos currently provides only a half-open uniform distribution on
[a,b).
I've implemented a simple uniform_open() function which should return a
uniform distribution on (a,b). The question is, are there any plans for
an open-interval uniform distribution in Phobos? Can I rely on this
functionality being provided in the long term in D's standard library?
(4) Truncation
The code uses C's trunc() function to return the integer part of a
floating point number. D doesn't seem to like it very much when I then
set a size_t as equal to the result of trunc(), and I have to use a type
cast. Is there a more elegant D-ish way of achieving the same result?
roundTo() isn't adequate, as it rounds to the _nearest_ integer rather
than the integer part.
It's OK. there are no implicit conversions of FP-- integer in the
language I think.
(5) ... any general stylistic comments? :-)
Looks fine ;)
Thanks and best wishes,
-- Joe
--
Dmitry Olshansky
Re: Question Object.factory and namespaces.
On Thursday, 12 April 2012 at 15:36:25 UTC, Justin Whear wrote:
On Thu, 12 Apr 2012 16:11:11 +0200, dcoder wrote:
My question is, how do I change the code above so that it
works even if I change the name of the file/module? I'm
looking for
clean solution something like a macro if one actually exists.
Check out packageName, moduleName, and fullyQualifiedName in
std.traits.
Additionally, the __FILE__ token will be expanded to the name
of the
current file.
Justin
Thanks for this info. I tried it but I'm still getting some
problems.
Here's what I have for code:
/* traits.d
*/
import std.stdio, std.traits;
void main() {
writefln( moduleName = %s , moduleName!(main));
return;
}
When I try to compile this, I get the following error:
traits.d(7): Error: undefined identifier moduleName
Could it be my compiler version? Here's what I have:
$ dmd
DMD32 D Compiler v2.055
By the way, I am doing this in cygwin, I don't know if that
matters.
thanks
Re: Question Object.factory and namespaces.
Could it be my compiler version? Here's what I have: $ dmd DMD32 D Compiler v2.055 Yeah, I think those templates were added in the last release or two. The current version is 2.058 (and 2.059 is in beta).
Re: Sampling algorithms for D
* Joseph Rushton Wakeling joseph.wakel...@webdrake.net [2012-04-12 16:45:34 +0200]: (3) Uniform random number on (0,1) The algorithms' specification explicitly refers to uniform random numbers on the open interval, which I take to mean (0,1) i.e. excluding zero. Phobos currently provides only a half-open uniform distribution on [a,b). I've implemented a simple uniform_open() function which should return a uniform distribution on (a,b). The question is, are there any plans for an open-interval uniform distribution in Phobos? Can I rely on this functionality being provided in the long term in D's standard library? There is support for fully all 4 types of intervals using std.random.uniform. You just specify the type of interval using a template parameter. The default is this: uniform!([))(a,b); And you want this: uniform!([])(a,b); You can also do () and (] to obtain the other two intervals -- James Miller
Re: Sampling algorithms for D
On 12/04/12 18:26, James Miller wrote: There is support for fully all 4 types of intervals using std.random.uniform. You just specify the type of interval using a template parameter. The default is this: uniform!([))(a,b); And you want this: uniform!([])(a,b); You can also do () and (] to obtain the other two intervals Deary me -- I did know that, once upon a time, and I'd completely forgotten. Thanks so much for reminding me. It was () I wanted ... :-)
Re: Sampling algorithms for D
On 12/04/12 16:45, Joseph Rushton Wakeling wrote: What I thought I'd do is implement some clever algorithms for random sampling which I've already done in a C based on the GNU Scientific Library. I noticed that there is already a randomSample class in std.random, which by the look of it is using Knuth's Algorithm S. Would there be any interest in my adapting Vitter's Algorithms A and D (as in my library) for Phobos in order to make this function more efficient?
Chaining std.algorithm functions
Hi. I was wondering why the following works: filter!(a = a % 2 == 0)(map!(a = a + 1)([1,2,3,4,5])) but the following does not: [1,2,3,4,5] .map!(a = a + 1)() .filter!(a = a % 2 == 0)() ...giving me the error `Error: no property 'filter' for type 'Result'` The dot syntax works fine if I'm just doing one map/filter/etc., though. Is there a better way to do chaining like this? Am I misunderstanding how the dot syntax sugar works or how map/filter/etc work in D? I'd prefer not to use the first style as it can get a bit unwieldy... Thanks for your time! ~DH
Re: Chaining std.algorithm functions
On Thursday, 12 April 2012 at 17:00:37 UTC, DH wrote: Hi. I was wondering why the following works: filter!(a = a % 2 == 0)(map!(a = a + 1)([1,2,3,4,5])) but the following does not: [1,2,3,4,5] .map!(a = a + 1)() .filter!(a = a % 2 == 0)() ...giving me the error `Error: no property 'filter' for type 'Result'` The dot syntax works fine if I'm just doing one map/filter/etc., though. Is there a better way to do chaining like this? Am I misunderstanding how the dot syntax sugar works or how map/filter/etc work in D? I'd prefer not to use the first style as it can get a bit unwieldy... Thanks for your time! ~DH It works for the first argument because UFCS (that is, calling free functions as members) works for arrays but not for other types (ranges in this case) in DMD =2.058. Thanks to the intrepid Kenji it works for all types in the upcoming 2.059. You can try out the 2.059 beta here: http://ftp.digitalmars.com/dmd2beta.zip Your second example should work fine in it. Regards, Brad Anderson
Re: Chaining std.algorithm functions
On Thu, Apr 12, 2012 at 07:00:35PM +0200, DH wrote: Hi. I was wondering why the following works: filter!(a = a % 2 == 0)(map!(a = a + 1)([1,2,3,4,5])) but the following does not: [1,2,3,4,5] .map!(a = a + 1)() .filter!(a = a % 2 == 0)() ...giving me the error `Error: no property 'filter' for type 'Result'` The dot syntax works fine if I'm just doing one map/filter/etc., though. Is there a better way to do chaining like this? Am I misunderstanding how the dot syntax sugar works or how map/filter/etc work in D? I'd prefer not to use the first style as it can get a bit unwieldy... [...] The second syntax requires dmd 2.059, which is currently on beta. Earlier versions of dmd do not support this syntax. T -- Two wrongs don't make a right; but three rights do make a left...
Re: Name of files causes error. Why?
On Thursday, April 12, 2012 14:30:50 Xan wrote: But it's a messy limitation. Why we should have it? For C++ compatibilities? Messy? How so? You can't put any characters in a module name which aren't valid identifiers. So what? Just name your module differently. Is your complaint that you can't just rename your cpp-file.cpp to cpp-file.d, make a few tweaks to its contents, and then have it compile as D? If that's the case, the file name is the least of your concerns. And I don't know why else you'd care about any compatability with C++ due to file names. How D interacts with C/C++ has nothing to do with the file names of either. Module names can end up being used inside code to fully qualify symbol names. e.g. std.algorithm.sort(arr); If you could put characters in a module name which weren't valid in an identifier, this would cause serious issues for the lexer and parser. std.algo-rithm.sort(arr); So, it's a very reasonable restriction that a module name be required to be a valid identifier. And this is not unusal among programming languages with module systems. C/C++ doesn't have such restrictions, because they had the misfortune to choose the whole #include mess. Their choice is p probably due - at least in part - to computing restrictions at the time which would have made putting all of the symbols in memory too expensive, so as bad as it is, they probably didn't have much choice, but it still has horrible problems - some of which are listed here: http://www.drdobbs.com/blogs/cpp/228701711 D's modules are _far_ better, even if with their restrictions on file names. - Jonathan M Davis
Trying to understand RandomSample struct in std.random
Hello all, I'm trying to understand the internal operations of the RandomSample struct in std.random. What gets output at the end is clearly an array containing a subset of the original input. But I can't understand how this is constructed. The constructor sets various initial values and then calls a function prime() [looks like an implementation of Knuth's Algorithm S] which returns when the current _index value is selected. Otherwise, it moves along to the next index value. What I don't understand is where the selected values are stored or how they come to be available. I also don't understand the corresponding randomSample functions where a specified random number generator is passed; how it can work to set ret.gen = gen _after_ the RandomSample struct has been initialized. Can anyone help me to understand how this struct works? Thanks best wishes, -- Joe
Re: Trying to understand RandomSample struct in std.random
On 04/12/2012 11:30 AM, Joseph Rushton Wakeling wrote: What gets output at the end is clearly an array containing a subset of the original input. That's misleading. RandomSample is a lazy range. The output seems to be elements of an array only as you pull data out of this range. The constructor sets various initial values and then calls a function prime() [looks like an implementation of Knuth's Algorithm S] which returns when the current _index value is selected. Otherwise, it moves along to the next index value. What I don't understand is where the selected values are stored or how they come to be available. The actual values are produced by the range that is passed to RandomSample. RandomSample merely skips over some of those values. I also don't understand the corresponding randomSample functions where a specified random number generator is passed; how it can work to set ret.gen = gen _after_ the RandomSample struct has been initialized. It is ok because the returned RandomSample range is not used yet. It will be used only after having been returned from the randomSample() convenience function. Can anyone help me to understand how this struct works? I shamelessly provide a link to a chapter that I have written, which I think covers all of these topics: http://ddili.org/ders/d.en/ranges.html Thanks best wishes, -- Joe Ali
Re: Name of files causes error. Why?
Manfred Nowak: On the contrary: it requires work to implement limitations. Therefore limitations are implemented only to shield users from mess. Also, removing limitations from a language is usually FAR simpler than introducing them later :-) Bye, bearophile
Re: Sampling algorithms for D
Joseph Rushton Wakeling:
https://github.com/WebDrake/SampleD
Some comments on the details of your code:
import std.c.time;
In D there there is also the syntax:
import std.c.time: foo, bar, baz;
That tells the person that reads the code what names are used.
--
interface Sampler(UniformRandomNumberGenerator) {
The UniformRNG name induces shorter lines in your module and I think it's
easy enough to understand.
--
double uniform_open(UniformRandomNumberGenerator)
(double a, double b, ref UniformRandomNumberGenerator urng)
{
In D function/method names are pascalCased. I also suggest to indent the second
line, and unless you plan to modifying a and b inside that, to always mark them
as in (or const, or even immutable):
double uniformOpen(UniformRNG)
(double a, double b, ref UniformRNG urng)
{
--
do {
x = uniform(a,b,urng);
} while (x==a);
I suggest to put a space after a comma and before and after an operator:
do {
x = uniform(a, b, urng);
} while (x == a);
--
class Skipper(UniformRandomNumberGenerator) :
Sampler!(UniformRandomNumberGenerator) {
When there is only one template argument you are allowed to omit the (), and
generally in English there is no need for a space before a ::
class Skipper(UniformRNG): Sampler!UniformRNG {
--
size_t S = skip(urng);
sampleRemaining--;
recordsRemaining -= (S+1);
currentRecord += S;
Unless you plan to modify a variable, then on default define it as immutable,
and where that's not possible, as const, this avoids mistakes later, makes the
code simpler to understand, and helps the compiler too:
immutable size_t S = skip(urng);
sampleRemaining--;
recordsRemaining -= S + 1;
currentRecord += S;
--
final size_t records_remaining() { return recordsRemaining; }
final size_t records_total() { return recordsTotal; }
Generally where possible add const, pure and nothrow attributes to
functions/methods every where you can (and in some cases @safe too, if you
want):
final size_t records_remaining() const pure nothrow { return
recordsRemaining; }
final size_t records_total() const pure nothrow { return recordsTotal; }
--
protected:
size_t currentRecord = 0;
size_t recordsRemaining;
All D variables are initialized (unless you ask them to not be initialized,
using = void), so the first = 0 is not needed (but initializing D floating
point values to zero is often necessary):
protected:
size_t currentRecord;
size_t recordsRemaining;
--
y1 = pow( (uniform_open(0.0,1.0, urng) * (cast(double)
recordsRemaining) / qu1),
(1.0/(sampleRemaining - 1)) );
In D there is also the ^^ operator.
--
for( t=recordsRemaining-1; t=limit; --t)
y2 *= top--/bottom--;
Generally packing mutation of variables inside expressions is quite bad style.
It makes code less easy to understand and translate, and currently it's not
defined, just as in C (it will be defined, but it will keep being bad style).
for (t = recordsRemaining - 1; t = limit; t--) {
y2 *= top / bottom;
top--;
bottom--;
}
Also in D there is (I hope it will not be deprecated) foreach_reverse(), maybe
to replace this for().
--
writeln(Hello! I'm a very simple and stupid implementation of some
clever);
writeln(sampling algorithms.);
writeln();
writeln(What I'm going to do first is just take a sample of 5 records
out of);
writeln(100 using each of the algorithms.);
writeln();
D string literals are multi-line too:
writeln(
Hello! I'm a very simple and stupid implementation of some clever
sampling algorithms.
What I'm going to do first is just take a sample of 5 records out of
100 using each of the algorithms.
);
--
sampling_test_simple!(VitterA!Random,Random)(100,5,urng);
Currently your code doesn't work if you want to use a Xorshift generator.
--
sampling_test_aggregate!(VitterA!Random,Random)(100,5,urng,1000,true);
writeln();
sampling_test_aggregate!(VitterD!Random,Random)(100,5,urng,1000,true);
writeln();
I suggest to define one enum inside the main(), like this, with underscores
too, to improve readability, and use it in all the function calls:
enum int N = 10_000_000;
samplingTestAggregate!(VitterA!Random, Random)(100, 5, urng, N, true);
Bye,
bearophile
Re: Trying to understand RandomSample struct in std.random
On 12/04/12 20:39, Ali Çehreli wrote: That's misleading. RandomSample is a lazy range. The output seems to be elements of an array only as you pull data out of this range. Ahhh, it's lazy evaluation. That would explain why you can set ret.gen = gen in the randomSample functions and have it work. (... realized that before reading your explicit statement to that effect:-) I shamelessly provide a link to a chapter that I have written, which I think covers all of these topics: http://ddili.org/ders/d.en/ranges.html No shame required, your textbook is very nice :-) I think I understand better now -- that the initial value is calculated by the call to prime() in the constructor, which leaves _input.front as being the first selected value; and then popFront() calls prime() again to set the next value, and so on. What I _still_ don't understand is the statement in the constructor: // we should skip some elements initially so we don't always // start with the first ... as it seems to me that doing so would bugger up the selection algorithm. The whole point of Algorithm S is that it considers one by one each of the possible values in sequence.
Re: Sampling algorithms for D
On Thursday, 12 April 2012 at 16:59:31 UTC, Joseph Rushton Wakeling wrote: On 12/04/12 16:45, Joseph Rushton Wakeling wrote: What I thought I'd do is implement some clever algorithms for random sampling which I've already done in a C based on the GNU Scientific Library. I noticed that there is already a randomSample class in std.random, which by the look of it is using Knuth's Algorithm S. Would there be any interest in my adapting Vitter's Algorithms A and D (as in my library) for Phobos in order to make this function more efficient? I think there is always interest for better efficiency. You may submit your patches to Don Clugston for review.
Re: Trying to understand RandomSample struct in std.random
On 04/12/2012 01:27 PM, Joseph Rushton Wakeling wrote: What I _still_ don't understand is the statement in the constructor: // we should skip some elements initially so we don't always // start with the first ... as it seems to me that doing so would bugger up the selection algorithm. The whole point of Algorithm S is that it considers one by one each of the possible values in sequence. It is to keep front() trivial. Unless popFront() is called, front() should always return the same element. That's why the constructor goes to the first selection up front so that the first call to front() need not calculate anything. As a result it reduces the laziness of the whole thing though. Even if popFront() is never called, the original range is consumed. Ali
Re: Sampling algorithms for D
On 12.04.2012 20:59, Joseph Rushton Wakeling wrote: On 12/04/12 16:45, Joseph Rushton Wakeling wrote: What I thought I'd do is implement some clever algorithms for random sampling which I've already done in a C based on the GNU Scientific Library. I noticed that there is already a randomSample class in std.random, which by the look of it is using Knuth's Algorithm S. Would there be any interest in my adapting Vitter's Algorithms A and D (as in my library) for Phobos in order to make this function more efficient? Aye, and in general community does appreciate any enhancements via pull requests on github: https://github.com/D-Programming-Language -- Dmitry Olshansky
Re: Dear ChrisMiller: This is day 4 of me trying to Compile a (tutorial) myForm.d program with D/Dfl/Entice.
On Thursday, 12 April 2012 at 05:18:22 UTC, Andrej Mitrovic wrote: On 4/12/12, vmars316 vmars...@live.com wrote: What is looking for? *import* something? Remove the space between '-I' and the import path. Ah, Thank you very much, works perfectly. Ok, so that's Dmd with Dfl. The myForm.exe is 743K large. That doesn't seem right. Now, I would like to compile/run the myForm.d program with Dmd, Entice, and Dfl . My Run-Entice-myForm.bat file looks like this: pause START of Run-Entice-myForm.bat setlocal EnableDelayedExpansion set DFL_LIB=C:\D\dmd2\windows\Dfl\import\dfl\win32\dfl\dfl.lib set DFL_IMPORT=C:\D\dmd2\windows\Dfl\import\dfl\win32\ Entice.exe C:\D\dmd2\windows\Entice\vmPrograms\myForm\myForm.d -I%DFL_IMPORT% %DFL_LIB% If i have a -gui switch in there, i get an Unrecognized Switch -gui error. How can I get Entice to show GUI mode? Also, Entice reads in the entire dfl.lib into a separate Tab. Is that normal? I need some help with the Compile Command that Entice asks for. Nothng I try works. Thanks..vm
Re: Sampling algorithms for D
On 12/04/12 21:54, bearophile wrote:
Some comments on the details of your code:
Thanks ever so much for the extensive review.
import std.c.time;
In D there there is also the syntax:
import std.c.time: foo, bar, baz;
That tells the person that reads the code what names are used.
Is this advised for all D modules, or just for stuff using the C standard
library?
Generally where possible add const, pure and nothrow attributes to
functions/methods every where you can (and in some cases @safe too, if you want):
final size_t records_remaining() const pure nothrow { return
recordsRemaining; }
final size_t records_total() const pure nothrow { return recordsTotal; }
Whether I can do this would depend on whether I put in place a re-initialization
function to allow the sampler to be reset with new values, no?
All D variables are initialized (unless you ask them to not be initialized, using =
void), so the first = 0 is not needed (but initializing D floating point values
to zero is often necessary):
I want to be _certain_ that value is zero. ;-)
In D there is also the ^^ operator.
Ahh, another thing I once knew but had forgotten since the last time I looked
at D.
for( t=recordsRemaining-1; t=limit; --t)
y2 *= top--/bottom--;
Generally packing mutation of variables inside expressions is quite bad style.
It makes code less easy to understand and translate, and currently it's not
defined, just as in C (it will be defined, but it will keep being bad style).
OK. There's one other that should be a point of concern, where I have
return currentRecord++;
... in one function; I've added a selectedRecord variable to get round this.
final size_t select(ref UniformRNG urng)
{
assert(_recordsRemaining 0);
assert(_sampleRemaining 0);
immutable size_t S = skip(urng);
immutable size_t selectedRecord = _currentRecord + S;
_sampleRemaining--;
_recordsRemaining -= (S+1);
_currentRecord += (S+1);
return selectedRecord;
}
Also in D there is (I hope it will not be deprecated) foreach_reverse(), maybe
to replace this for().
I'll see what I can do with that. There may be a better way of expressing this
anyway -- as is it's pretty much a literal transcription of the Pascal-esque
pseudo-code in the original research paper describing the algorithm.
sampling_test_simple!(VitterA!Random,Random)(100,5,urng);
Currently your code doesn't work if you want to use a Xorshift generator.
Ack, enabling that is precisely why I bothered templatizing it in the first
place. Can you suggest a fix ... ? I don't understand why as-is it wouldn't work.
--
sampling_test_aggregate!(VitterA!Random,Random)(100,5,urng,1000,true);
writeln();
sampling_test_aggregate!(VitterD!Random,Random)(100,5,urng,1000,true);
writeln();
I suggest to define one enum inside the main(), like this, with underscores
too, to improve readability, and use it in all the function calls:
enum int N = 10_000_000;
samplingTestAggregate!(VitterA!Random, Random)(100, 5, urng, N, true);
Fair enough. I'd forgotten about the underscore notation for large numbers.
This stuff I'm not too worried about, because it's only a stupid demo thing, not
the important code ... :-)
Thanks again for the careful review, it's been very useful.
Best wishes,
-- Joe
Re: Sampling algorithms for D
On 12/04/12 21:54, bearophile wrote:
sampling_test_simple!(VitterA!Random,Random)(100,5,urng);
Currently your code doesn't work if you want to use a Xorshift generator.
Ahhh, I see what you mean now -- the sampler classes are fine, but the way the
main() function is written means you can't just tweak the RNG.
The original code I tried writing was something like,
sampling_test_simple!(VitterA, Random)(100, 5, urng);
... with the sampler object being created in the function with,
auto s = new SamplerType!UniformRNG(records, samples, urng);
... but the compiler objected to that with the error,
sampled.d:216: Error: template instance
sampling_test_simple!(VitterA,XorshiftEngine!(uint,128,11,8,19))
does not match template declaration
sampling_test_simple(SamplerType,UniformRNG)
Here's the complete (wrong) function:
void sampling_test_simple(SamplerType, UniformRNG)
(size_t records, size_t samples, ref UniformRNG urng)
{
auto s = new SamplerType!UniformRNG(records,samples,urng);
while(s.sampleRemaining 0) {
write(\trecord selected: , s.select(urng), .);
write(\trecords remaining: , s.recordsRemaining, .);
writeln(\tstill to sample: , s.sampleRemaining, .);
}
}
It's not clear to me why this fails or what I can do that would equate to this.
Re: Sampling algorithms for D
Joseph Rushton Wakeling:
Thanks ever so much for the extensive review.
They are shallow comments, mostly about syntax, etc. So writing
them requires little time.
Is this advised for all D modules, or just for stuff using the
C standard library?
I have said there is also the syntax instead it's better to do
this because some D programmers don't like to do that. You have
to be aware that syntax exists, and that's it's better to write:
import std.foo: bar, baz;
Than:
import std.foo; // for bar and baz functions
then personally I sometimes like to qualify my imports (writing
what I import from them), for various reasons, but it also
increases the amount of work to do when you want to modify the
code. So it's a personal choice.
Also, the more important is for you to not put bugs in a specific
module, the more tight/strongly statically typed is better to
write the code (like Ada language code). If for you the
correctness of a specific module is not very important, then
using a lazier coding style is acceptable :-) If you write code
lot of money/hardware or even people lives will depend on, you
have to adopt a progressively more and more error-proof style of
coding, eventually even using software to proof the correctness
of critical routines.
Whether I can do this would depend on
It depends on many things, including DMD bugs, D language design
faults, Phobos incomplete coverage of those annotations, and of
course on the semantics of your code, etc.
I want to be _certain_ that value is zero. ;-)
Then assign on more time, to be really sure :-)
int x = 0;
x = 0; // It must be ZERO, dammit.
final size_t select(ref UniformRNG urng)
{
assert(_recordsRemaining 0);
assert(_sampleRemaining 0);
Probably it's better to move those asserts in
preconditions/postconditions or in class/struct invariants.
And I think your code needs some unittests{} too.
Ack, enabling that is precisely why I bothered templatizing it
in the first place. Can you suggest a fix ... ? I don't
understand why as-is it wouldn't work.
If you try to use a Xorshift the compiler will tell you the
problems, I think with some work you will be able to fix them and
create a more flexible module:
void main() {
auto urng = Xorshift(23);
This stuff I'm not too worried about, because it's only a
stupid demo thing, not the important code ... :-)
In my opinion demo code is a bit like unittests. And unittests
require the same coding precision as the rest of the code :-)
Bye,
bearophile
Re: Sampling algorithms for D
On 12/04/12 23:34, Dmitry Olshansky wrote: Aye, and in general community does appreciate any enhancements via pull requests on github: https://github.com/D-Programming-Language OK, I'll see what I can do. I'd like to discuss and refine the design a bit further before making any pull request -- should I take things over to the Phobos mailing list for this ... ?
Re: Sampling algorithms for D
On 13/04/12 00:48, bearophile wrote:
final size_t select(ref UniformRNG urng)
{
assert(_recordsRemaining 0);
assert(_sampleRemaining 0);
Probably it's better to move those asserts in preconditions/postconditions or in
class/struct invariants.
Those asserts are deliberately intended for the function. To see why it
matters, consider setting up an instance of the class to select a sample of size
5, and then calling select() 6 times.
Of course, there may be a better way of handling that which I'm not aware of :-)
And I think your code needs some unittests{} too.
Agreed.
Ack, enabling that is precisely why I bothered templatizing it in the first
place. Can you suggest a fix ... ? I don't understand why as-is it wouldn't
work.
If you try to use a Xorshift the compiler will tell you the problems, I think
with some work you will be able to fix them and create a more flexible module:
void main() {
auto urng = Xorshift(23);
I realized afterwards what you were talking about, but am not sure how to fix
(cf. my other email). My first coding attempt was designed to be more flexible
but the compiler didn't like it. ;-)
In my opinion demo code is a bit like unittests. And unittests require the same
coding precision as the rest of the code :-)
Agree :-) They are imperfect tests for now, IMO, which is why I'm being lazy...
Re: Sampling algorithms for D
Joseph Rushton Wakeling:
final size_t select(ref UniformRNG urng)
{
assert(_recordsRemaining 0);
assert(_sampleRemaining 0);
Probably it's better to move those asserts in preconditions/postconditions
or in
class/struct invariants.
Those asserts are deliberately intended for the function.
Then use a function/method precondition:
final size_t select(ref UniformRNG urng)
in {
assert(_recordsRemaining 0);
assert(_sampleRemaining 0);
} body {
...
}
Bye,
bearophile
Library search path on Windows?
How do I pass a library search path to DMD on Windows? -- - Alex
Re: Library search path on Windows?
On 13-04-2012 03:10, Alex Rønne Petersen wrote: How do I pass a library search path to DMD on Windows? -L+path apparently... -- - Alex
Re: Library search path on Windows?
On Friday, 13 April 2012 at 01:10:40 UTC, Alex Rønne Petersen wrote: How do I pass a library search path to DMD on Windows? I would love to know too! Only place I found was to edit sc.ini sorry.
Re: Name of files causes error. Why?
On Wednesday, 11 April 2012 at 19:33:58 UTC, Xan wrote: Hi, With helloworld program named with score or underscore, I receive the following __annoying__ error: $ gdmd-4.6 hola-temp.d hola-temp.d: Error: module hola-temp has non-identifier characters in filename, use module declaration instead Why? Can someone fix it. It's really annoying Thanks in advance, Xan. Module names are used for import statements: import mymodule; As this is D code, it must have a valid identifier so that it parses import my-module; This could probably be special cased, but you can use these names in code auto a = my-module.foo(); Are you subtracting 'my' from 'module.foo()?' You can name you files whatever you want. Just include your module name at the top (recommended anyway) module my_module; In this case, if you module file is named my-module, then rdmd and other build tools that use your import information will be unable to locate my_module.d because that file does not exist.
FormatSpec struct
I'm trying to add formatted output to my decimal arithmetic module. Decimals should format like floating point, using 'E', 'F' and 'G', etc. I would expect a format string like %9.6e to parse as width = 9, precision = 6, using exponential notation. In std.format there is a FormatSpec struct that looks as if it will do the parsing for me. As far as I can tell the usage is: auto spec = std.format.FormatSpec!char(9.6e); writeln(fmtspec = , fmtspec); But it doesn't do what I think it should do. The output of the method is: fmtspec = address = 1637116 width = 0 precision = 2147483646 spec = s indexStart = 0 indexEnd = 0 flDash = false flZero = false flSpace = false flPlus = false flHash = false nested = trailing = 9.6e The width field should be 9, the precision field should be 6, and the spec field should be 'e'. Instead it seems to disregard the input string and return a default FormatSpec, with only the 'trailing' field populated, containing the input. What am I missing here? I've tried variations -- %9.6e, s, %s, etc, but the input is always relegated to the trailing field. Paul
