Re: 1st draft of complete class-based std.random successor
On Thursday, 20 March 2014 at 01:32:41 UTC, Chris Williams wrote: On Wednesday, 19 March 2014 at 23:49:41 UTC, Joseph Rushton Wakeling wrote: Hello all, As some of you may already know, monarch_dodra and I have spent quite a lot of time over the last year discussing the state of std.random. To cut a long story short, there are significant problems that arise because the current RNGs are value types rather than reference types. Any chance that you could describe them? I was about to resume porting the dcrypt library into Phobos, and had intended to flip the classes into structs, to match what the rest of the library was doing. The issue isn't class vs struct, but rather value semantic vs reference semantic (classes are always ref, but structs can be either). Basically, if you make a copy, and modify the copy, will the original range be modified? The problem with value semantics is that it always un-expected duplication of the range, which is a critical blocker problem as far as random goes. The tell-tale usecase is: // auto g = rndGen(); g.take(10).writeln(); g.take(10).writeln(); // This will write the same sequence... TWICE!
Re: 1st draft of complete class-based std.random successor
On Thursday, 20 March 2014 at 00:09:51 UTC, bearophile wrote: Joseph Rushton Wakeling: * std.random2.adaptor, random adaptors such as randomShuffle, randomSample, etc. Please don't use stuttering names like std.random2.randomShuffle. std.random2.shuffle is enough. Agreed. `randomShuffle` can be made a deprecated alias: This way, random2 should still be mostly drop in replacement, but we won't drag along the bad names. My own feeling is that ultimately it is a responsibility of the language to offer nice ways to allocate classes without necessarily relying on new or the GC. I don't think the language is yet there. So I think currently this is not a good idea. I think there is 0 doubt that reference semantics is the way to go. An advantage of using class is that it is still *possible* to place them on the stack with Scoped, or with some future language mechanic. On the other hand, if we implement as reference structs, then that's that. Furthermore, even in terms of performance, I think a heap allocated PRNG will still flat-out beat the value based one, if only because of the size of the damn thing. That said, being able to allocate them on the malloc heap, and not the GC heap, would be (IMO) also a valid design. A simple and dumb design might be to still implement them with value semantic but: 1. Disable postblit. 2. Make .save() return a Random* This would mean 1. No dangers of accidental copy. 2. Range* is a ForwardRange. 3. Trivially allows GC/malloc/stack allocation. With good aliases (alias Random = RadomImpl*;), and a make! template we could make the default useage transparent to this mechanism yet make it easy to get our hands under the hood. But at this point, we are really beating around the bush on this issue. There are two things for sure: 1. Reference semantics by default. 2. There comes a point where we have to move forward. I didn't check the code yet, but a middle ground could be to make all constructors private, and disable T.init. Then, we force construction through a make! template. This might not be what's most convenient, but it would allow us to potentially change the design at a later stage, without breaking user code. Do you have a simple but very fast function that generates uniforms in [0.0, 1.0]? :-) AFAIK, the allocation issue is only for ranges? uniform is just a function, I don't think it affected by the issue. Even if you are operating on a passed range, either ranges are reference semantics, and you take by value, or they are value semantic, and you take by ref. Either way, you have to pay for the indirection.
Re: 1st draft of complete class-based std.random successor
On Thursday, 20 March 2014 at 19:04:01 UTC, Andrea Fontana wrote: Still no cmwc rng... IMO cmwc should replace mt as default RNG. Faster. Longer period. More passed tests (if i'm right MT didn't pass testu01). And it is parametric to get faster result or longer period. http://en.wikipedia.org/wiki/Multiply-with-carry#Complementary-multiply-with-carry_generators Would a Lagged Fibonacci generator instead fit your needs? I wrote one, but it was held of until `random` was updated. It's goal, first, is to replace the old module. It'll add new stuff once it has achieved that goal.
Re: Start of dmd 2.064 beta program
On Monday, 14 October 2013 at 13:25:23 UTC, Benjamin Thaut wrote: I'm also getting random missing symbol linker errors with both dmd 2.063.2 and dmd 2.064. But only on 32-bit windows. On 64-bit windows it works fine. This is really frustrating... I've encountered this too. I'll try to reduce, but the test case isn't easy.
Re: Start of dmd 2.064 beta program
On Monday, 14 October 2013 at 19:17:25 UTC, 1100110 wrote: *BOTH* of you write dates in an odd way. http://xkcd.com/1179/ Amen. ISO 8601 FTW. The Japanese got it correct natively though. It's year, then month then day, seperated either by explicit 年月日 (year, month, day), or by / or -. At university, we mostly used -. Well, that's when they don't use their imperial dates :/ On Monday, 14 October 2013 at 20:39:12 UTC, Jesse Phillips wrote: I've chosen to try writing dates using the ISO 2013-10-14 Always causes confusion, thus leading people to actually figure out the numbers. :) Of course programmers don't have an issue with it. Sadly, it can't be shortened: 13-10-14 or 10-14 I'm also ok with 2013/10/14 even though ISO isn't. It minimum, I try to keep it to .*MM.*DD. Also, when naming files, it sorts automatically, which is always good. That's how I name my photos anyways: format(%04-%02 - LOCATION_OR_EVENT - %03, year, month, ++counter).
Re: GHC 2013 in Paris
On Saturday, 24 August 2013 at 22:52:50 UTC, Iain Buclaw wrote: Hi Guys, Thanks for making it down. Are you going to be around tomorrow? Feel free to ping me or message me and we'll arrange something. :o) Will be at the IRIS building at 9.00am (this time I will be present at that time). And will be staying in Paris until around 2.00pm, which is when I have to check in for train back to London. Regards Sorry for being there so little time. It *was* a *GNU* conference to begin with, and I kind of appeared only for your talk, out of nowhere, so I didn't want to stay un-invited for what followed (dinner and whatnot). Sorry I left without saying goodbye, I didn't want to bother anyone during a talk. I enjoyed your talk very much, and learned a lot about things I knew nothing about. Sorry I can't make it back down to Paris today, but as you may have noticed, moving is a bit difficult for me at the moment. In any case, I hope you'll enjoy your last day in Paris, even under the rain :/
Re: GHC 2013 in Paris
On Friday, 23 August 2013 at 16:31:17 UTC, Iain Buclaw wrote: I've jsut been told there's no reception on Saturdays, so after 9.00am might be a slight problem, but I think they will leave a number for you to call. I *could* excuse myself to let you in, but that would require relying on me to remember what time you are arriving. :o) Hum... The forum was down yesterday, so I couldn't post this any earlier. I actually only intend to see your talk, so I won't be there before 16:00. I'll be at the gates *before* 15:30, and see if/how I can get it from there. FWI, I'll be the guy who walks with a crutch. I don't if anyone will be seeing this today, but if you don't see me in the building by 15:50, then it means I failed to get in, and am waiting outside...
Re: GHC 2013 in Paris
On Tuesday, 20 August 2013 at 07:31:29 UTC, Iain Buclaw wrote: Will be arriving in Paris tomorrow. Is it only you two who will be around? Hey! I had no idea this was going on! I'll definitely try to catch your talk. I'm still super sour about having missed dconf :( They say you need a badge to enter on week-ends? I hope I can just walk up to this conference and enter.
Re: D reaches 1000 questions on stackoverflow
On Thursday, 15 August 2013 at 06:11:32 UTC, Walter Bright wrote: On 8/14/2013 10:05 PM, Brad Anderson wrote: On Thursday, 15 August 2013 at 02:30:42 UTC, Jonathan M Davis wrote: On Wednesday, August 14, 2013 22:56:30 Andre Artus wrote: As with many things it depends on what you want to achieve. Answering on SO is as much about establishing awareness as it is about answering the question. For a newcomer to D StackOverflow may be their first port of call, if questions go unanswered, or are answered after long delays, then the likelihood of the person persisting with D is diminished. I answer questions on SO all the time And I have to thank you for that. You leave some great, in-depth answers on Stack Overflow. I'll chime in thanking Jonathan for this valuable contribution. I think I'll chip in by answering questions on SO too. I enjoy helping.
Re: Darwin 32 release broken (in uni.d)
On Tuesday, 13 August 2013 at 04:39:11 UTC, Dmitry Olshansky wrote: 12-Aug-2013 17:57, monarch_dodra пишет: It looks like the darwin 32 release is broken at the phobos unittest stage. It would appear the breakage is in the uni.d debug step: make[1]: *** [generated/osx/debug/32/unittest/std/uni] Segmentation fault: 11 I don't think it is the new uni module that is responsible, since it worked fine when it was merged. I haven't pinned down which pull triggered the breakage, but I figure the first step to getting the release fixed is to announce it as broken. Or I should file a report instead? That's right but ... In the phobos mailing list next time :) Right... I'll do that next time. On Tuesday, 13 August 2013 at 06:37:28 UTC, Jacob Carlborg wrote: On 2013-08-12 15:57, monarch_dodra wrote: It looks like the darwin 32 release is broken at the phobos unittest stage. It would appear the breakage is in the uni.d debug step: make[1]: *** [generated/osx/debug/32/unittest/std/uni] Segmentation fault: 11 I don't think it is the new uni module that is responsible, since it worked fine when it was merged. I haven't pinned down which pull triggered the breakage, but I figure the first step to getting the release fixed is to announce it as broken. Or I should file a report instead? It should be reverted now. I change the compiler from GCC to Clang, apparently that didn't work out. Walter did fix a bunch of warnings tough :) Cool. Thanks for the feedback. I closed the ticket then.
Darwin 32 release broken (in uni.d)
It looks like the darwin 32 release is broken at the phobos unittest stage. It would appear the breakage is in the uni.d debug step: make[1]: *** [generated/osx/debug/32/unittest/std/uni] Segmentation fault: 11 I don't think it is the new uni module that is responsible, since it worked fine when it was merged. I haven't pinned down which pull triggered the breakage, but I figure the first step to getting the release fixed is to announce it as broken. Or I should file a report instead?
Re: A new blog article detailing the alternative function syntax
On Friday, 9 August 2013 at 08:03:45 UTC, Gary Willoughby wrote: On Thursday, 8 August 2013 at 22:37:04 UTC, Andrei Alexandrescu wrote: If you want me to post to reddit tomorrow morning, let me know. My good post karma is likely to push the post into visibility quickly. On the other hand, if you post it yourself it will improve _your_ karma. Tradeoffs, tradeoffs... Sure go ahead. Good read. I think I already knew all of it, but seeing it all written in a concise and organized way is always a good refresher, and also reminds you of the why things are the way they are.
Re: Article: Increasing the D Compiler Speed by Over 75%
On Thursday, 1 August 2013 at 07:47:25 UTC, Joakim wrote: On Wednesday, 31 July 2013 at 22:58:56 UTC, Walter Bright wrote: Have you ever seen those cards that some electrical engineers carry around, with the following equations on them: V = I * R R = V / I I = V / R ? I found it: https://docs.google.com/drawings/d/1StlhTYjiUEljnfVtFjP1BXLbixO30DIkbw-DpaYJoA0/edit?hl=enpli=1 Unbelievable. The author of it writes: I'm going to explain to you how to use this cheat sheet in case you've never seen this before. http://blog.ricardoarturocabral.com/2010/07/electronic-electrical-cheat-sheets.html Makes you want to cry. No real electrical engineer would ever use that card, as you connote with your quotes. If they don't have Ohm's law and the resulting algebra drilled into their head, they better find another job. I suspect that chart is for amateurs from other backgrounds who happen to be doing some electrical work. Screw engineers, *anybody* who doesn't know these laws shouldn't be allowed anywhere *near* electricity :D
Re: Article: Increasing the D Compiler Speed by Over 75%
On Monday, 29 July 2013 at 20:19:34 UTC, John Colvin wrote: On Monday, 29 July 2013 at 19:08:28 UTC, JS wrote: Please study up on basic math before building any bridges. I know computers have made everyone dumb And again: Honestly, I don't know why you are still trying... At this point, it's not the math that's a problem anymore, it's basic communication. Back to the main subject: Congrats Walter! Those are some incredible numbers ;)
Re: monarch dodra granted write access to phobos, druntime, and tools
On Monday, 22 July 2013 at 18:08:36 UTC, Andrei Alexandrescu wrote: Please join me in congratulating monarch dodra for his admission among our github committers. We're starting with phobos, druntime, and tools access, and if all goes well, we'll extend write rights to dmd also. Thanks, Andrei Hey! Sorry it took me 4 days to discover the D announce thread. I must admit it wasn't one of the threads I looked over (although this will change starting today, lots of interesting articles here). In any case, thank you everyone for your support and kind words :) I don't think granting me dmd rights would be necessary, as I don't really know how the compiler works, and I mostly only contribute to phobos anyways (sometimes druntime). I may in the future try to contribute to dmd itself, but I wouldn't ever pull anything in there myself anyways, so giving me pull rights (at this point) would be mostly pointless. Well, here's to making D as best as it can be ^^
Re: echo: -n, the next installment
On Saturday, 27 July 2013 at 12:39:24 UTC, monarch_dodra wrote:
On Friday, 26 July 2013 at 00:38:46 UTC, John Colvin wrote:
After a few weeks of not getting around to it, here's my
second post:
http://foreach-hour-life.blogspot.co.uk/2013/07/the-first-corner-n-for-echo.html
I tried to post a comment on your blog, but I failed. Anyways,
I wanted to post:
And here is the second comment I wanted to put:
When parsing the options, you use an if-else. I don't know if its
just me, but I find that using a switch is clearer (it's what you
do in your second example). It also introduces string cases
(illegal in C++), and labeled control statements.
The code becomes:
import std.stdio : writef, writeln;
void main(string[] args)
{
assert(args.length);
args = args[1 .. $];
bool writeNewline = true;
size_t i = 0;
myForeach: foreach(arg; args)
{
switch(arg)
{
case -n:
writeNewline = false;
++i;
break;
default:
break myForeach;
}
}
args = args[i .. $];
writef(%-(%s %), args);
if(writeNewline)
writeln();
}
PS: If I figure out how to comment on your blog, I'll paste the
comments there :)
Re: echo: -n, the next installment
On Saturday, 27 July 2013 at 12:19:44 UTC, John Colvin wrote: On Saturday, 27 July 2013 at 01:09:03 UTC, Jesse Phillips wrote: On Friday, 26 July 2013 at 00:38:46 UTC, John Colvin wrote: After a few weeks of not getting around to it, here's my second post: http://foreach-hour-life.blogspot.co.uk/2013/07/the-first-corner-n-for-echo.html BTW, std.getopt is a good way to parse arguments. Not sure if it is relevant to what you want to teach, but should generally be preferred over handwritten. I'm pretty sure it wouldn't work ideally for echo as the behaviour depends on the order of the arguments. getopt knows how to handle ordering, it's really just a matter of echo's argument parsing rules being different from classic getopt. For example, echo does not handle -- argument (end of options mark), which means it is literally impossible for echo's first string argument to be -n. So for example, while echo -- -n would print -- -n, a getopt echo would print -n. Arguably, this is better behavior, but if the goal is exact replication, then it's wrong :/
