Prev: preprocessing issue with Visual Studio
Next: Functions with side effects in I/O list
From: glen herrmannsfeldt on 29 Jun 2010 01:29
Richard Maine <nospam(a)see.signature> wrote:
(snip)

> I haven't been directly involved with much after f2003, and in
> particular, with the coarray stuff. (In fact, until I saw your later
> mention of coarrays, I didn't pick up what you were talking about when
> you said "images". Nothing wrong with your usage; I just haven't been
> imersed in it enough that the term makes coarray stuff imediately pop
> into my mind. My initial reaction was to wonder why anyone thought the
> Fortran standard would say anything about picture images.)

That was my first thought, too. There was some years ago much
discussion on the then-popular PRNGs being used to generate
coordinates in three-dimensions, and not being so random as
one might want. I was still trying to figure that out when
I went to the next page and found what he was asking about.

-- glen
From: glen herrmannsfeldt on 29 Jun 2010 02:02
Richard Maine <nospam(a)see.signature> wrote:
> GaryScott <garylscott(a)sbcglobal.net> wrote:

>> I would like a "truly" (or whatever
>> the best you can get is) random sequence generator.

> That would be a bit out of line for a software standard. The question of
> what "truly random" means is perhaps as much philosophical as anything,
> but most definitions would rule out anything implemented purely in
> software. If it is generated purely by software, then is is
> pseudorandom, pretty much by definition. Sounds to me like you are
> talking about a spec for a hardware peripheral. Don't hold your breath
> for anything even vaguely close in the Fortran standard.

You might start on the Wikipedia page for Crypographically secure
pseudorandom number generator. Not that I believe Fortran should
require a CSPRNG, but it does describe some of the problems with
other generators.

> I can't interpret your "or whatever the best you can get is". Maybe that
> means you aren't really talking about a hardware peripheral, but instead
> are asking for a "good quality" pseudorandom generator, that being all
> you can do in software. But as to exactly what the "best" one would
> be...If you want the Fortran standard to specify that the best one be
> used, you'd first have to get agreement on exactly what would define
> such a "best" one. Methinks you are in the wrong group for that (and
> that you aren't going to get agreement on a definitive answer anytime
> soon.)

You might have a good generator with billions of bits of state,
such that it won't repeat within many times the age of the universe,
but you still need a good seed.

My complaint about the Fortran standard version is that it
doesn't provide a way to generate a good seed. That is, with most
generators there are properties that the seed should have, but
there is no way to know that for a given implementation.

-- glen
From: nmm1 on 12 Jul 2010 11:15
In article <87wrt0burk.fsf(a)NaN.sparse.dyndns.org>,
Jason Riedy <jason(a)acm.org> wrote:
>
>> It is not commonly realised, but approach (3) is FAR more reliable
>> than approach (1) though not, of course, as reliable as approach (2).
>
>No kidding. I've run into many problems lately with "random" data being
>so far from even pseudorandom... Hey, look, we generate a mountain of
>duplicate graph edges!

Yup.

>> There were people who wanted the standard to specify approach (1) and
>> I and some others objected strongly, not just for that reason, but
>> because approach (3) is arguably the most appropriate for a shared
>> memory coarray implementation. So the specification was written to
>> allow all three, and to leave the matter as 'quality of implementation',
>> exactly as for serial random numbers and the intrinsic functions.
>
>And now the burden is on us app/library writers to provide our own for
>portable correctness. I know well that the right but difficult / slow
>thing is kept as a quality-of-implementation issue, but it sucks for us.
>Kinda. I also know that not all parallel generators will look correct
>for all uses, so...

I have tried thinking of how one could specify quality in standardese,
and failed dismally. It could be done for the numerical intrinsics,
but that is an easier task (technically) - the chances of getting
consensus are negligible, though.


Regards,
Nick Maclaren.
First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: preprocessing issue with Visual Studio
Next: Functions with side effects in I/O list