On Friday, 10 October 2014 at 09:21:37 UTC, eles wrote:
> ;) It was a joke. The link that I posted was supposed to make things clear. :)

You two-faced person, you. ;-)

On Friday, 10 October 2014 at 06:28:06 UTC, Iain Buclaw via Digitalmars-d wrote:
> http://www.wired.com/2012/12/what-does-randomness-look-like/

... yes, allowing for the reasonable expectations one can have for extended runs of heads in a regular 50/50 coin-flip process.

Actually, related to that article, in my very first stats lecture at university, the first slide the lecturer showed us (on the overhead projector...) was, side by side, two patterns of dots each within a rectangular area.

He asked: "Do you think these points are distributed at random?"  Well, they pretty much looked the same to the naked eye.

Then he took another transparency, which placed grids over the two rectangular dot-filled areas.  In one, the dots were here, there, with some grid squares containing no dots at all, some containing clusters, whatever.

In the other, every single grid square contained exactly one dot.

I still think that was one of the single most important lessons in probability that I ever had.

On 10/10/2014 2:26 AM, Marco Leise via Digitalmars-d wrote:
> Am Wed, 08 Oct 2014 16:30:19 +0100
> schrieb Bruno Medeiros <bruno.do.medeiros+dng@gmail.com>:
>
>> I don't think memory-safety is at the core of the issue. Java is
>> memory-safe, yet if you encounter a null pointer exception, you're still
>> not sure if your whole application is now in an unusable state, or if
>> the NPE was just confined to say, the operation the user just tried to
>> do, or some other component of the application. There are no guarantees.
>
> I know a Karaoke software written in .NET, that doesn't check
> if a list view is empty when trying to select the first
> element. It results in a popup message about the Exception and
> you can continue from there.
>
> It is a logic error (aka assertion), but being tailored
> towards user interfaces, .NET doesn't kill the app.
> Heck, if Mono-D closed down on every NPE I wouldn't be using
> it any more. ;)

How much you want to bet that if it did exit the app, that the bug would actually have been addressed rather than still remain broken?

On Friday, 10 October 2014 at 18:53:46 UTC, Brad Roberts via Digitalmars-d wrote:
> How much you want to bet that if it did exit the app, that the bug would actually have been addressed rather than still remain broken?

It more likely would cause maintainer to abandon the project after encountering raging users he can't help. Most of such Mono-D issues simply are not reproducable on Alex side and remain unfixed because of that. I can't remember a single case when he remained willingly ignorant of an unhandled exception.

On 10/10/2014 05:31 AM, Joseph Rushton Wakeling wrote:
> On Friday, 10 October 2014 at 06:28:06 UTC, Iain Buclaw via
> Digitalmars-d wrote:
>> http://www.wired.com/2012/12/what-does-randomness-look-like/
>
> ... yes, allowing for the reasonable expectations one can have for
> extended runs of heads in a regular 50/50 coin-flip process.
>
> Actually, related to that article, in my very first stats lecture at
> university, the first slide the lecturer showed us (on the overhead
> projector...) was, side by side, two patterns of dots each within a
> rectangular area.
>
> He asked: "Do you think these points are distributed at random?" Well,
> they pretty much looked the same to the naked eye.
>
> Then he took another transparency, which placed grids over the two
> rectangular dot-filled areas.  In one, the dots were here, there, with
> some grid squares containing no dots at all, some containing clusters,
> whatever.
>
> In the other, every single grid square contained exactly one dot.
>
> I still think that was one of the single most important lessons in
> probability that I ever had.

I like that. I actually have a similar classroom probability story too (involving one of the best teachers I ever had):

As part of a probability homework assignment, we were asked to flip a coin 100 times and write down the results. "Uhh, yea, there's no way I'm doing that. I'm just gonna write down a bunch of T's and F's."

Having previously played around with PRNG's (using them, not actually creating them), I had noticed that you do tend to get surprisingly long runs of one value missing, or the occasional clustering. I carefully used that knowledge to help me cheat.

During the next class, the teacher pointed out that "I can tell, most of you didn't actually flip a coin, did you? You just wrote down T's and F's..." Which turned out to be the whole *point* of the assignment. Deliberately get students to "cheat" and fake randomness - poorly - in order to *really* get them to understand the nature of randomness.

Then he turned to me and said, "Uhh, Nick, you actually DID flip a coin didn't you?" Hehe heh heh. "Nope :)" I got a good chuckle out of that.

On 10/9/2014 9:33 AM, Johannes Pfau wrote:
> A point which hasn't been discussed yet:
>
> Errors and therefore assert can be used in nothrow functions. This is a
> pita for compilers because it now can't do certain optimizations. When
> porting GDC to ARM we started to see problems because of that (can't
> unwind from nothrow functions on ARM, program just aborts). And now we
> therefore have to worsen the codegen for nothrow functions because of
> this.
>
> I think Walter sometimes suggested that it would be valid for a
> compiler to not unwind Errors at all (in release mode), but simply kill
> the program and dump a error message. This would finally allow us to
> optimize nothrow functions.

Currently, Errors can be caught, but intervening finally blocks are not necessarily run. The reasons for this are:

1. better code generation

2. since after an Error the program is likely in an unknown state, the less code that is run after an Error, the better, because it may make things worse

On 10/9/2014 10:31 AM, Dicebot wrote:
> On Thursday, 9 October 2014 at 16:33:53 UTC, Johannes Pfau wrote:
>> I think Walter sometimes suggested that it would be valid for a
>> compiler to not unwind Errors at all (in release mode), but simply kill
>> the program and dump a error message. This would finally allow us to
>> optimize nothrow functions.
>
> I think this is reasonable in general but as long as assert throws Error and
> assert is encouraged to be used in unittest blocks such implementation would
> mark compiler as unusable for me.

All assert actually does is call a function in druntime. You can override and insert your own assert handling function, and have it do as you need. It was deliberately designed that way.


> We may need to have another look at what is truly an Error and what is not
> before going that path.

This involves making some hard decisions, but is worthwhile.

On Saturday, 4 October 2014 at 05:26:52 UTC, eles wrote:
> On Friday, 3 October 2014 at 20:31:42 UTC, Paolo Invernizzi wrote:
>> On Friday, 3 October 2014 at 18:00:58 UTC, Piotrek wrote:
>>> On Friday, 3 October 2014 at 15:43:59 UTC, Sean Kelly wrote:

>
> For the curious, the flight analysis here:
>
> http://www.popularmechanics.com/technology/aviation/crashes/what-really-happened-aboard-air-france-447-6611877
>

A just-printed new analysis of the same:

http://www.vanityfair.com/business/2014/10/air-france-flight-447-crash

On 10/11/2014 1:34 PM, Nick Sabalausky wrote:
> Having previously played around with PRNG's (using them, not actually creating
> them), I had noticed that you do tend to get surprisingly long runs of one value
> missing, or the occasional clustering. I carefully used that knowledge to help
> me cheat.

Election fraud is often detected by examining the randomness of the least significant digits of the vote totals.

On Saturday, 11 October 2014 at 22:06:38 UTC, Walter Bright wrote:
> All assert actually does is call a function in druntime. You can override and insert your own assert handling function, and have it do as you need. It was deliberately designed that way.

A while ago I have been a looking for a way to throw Exception instead of Error for failing assertions inside unittest blocks but druntime didn't seem to provide needed context. Do you think this can be a worthy addition?