| OK, Simon, it looks as if Fergus and Tom are on board.
Fine. So I'll go with the optional genRange proposal.
In general, the standard libraries have no name conflicts;
you can import them all at will. That's not the only
possible policy (the other is to name similar things the same
and use
> So this is really an appeal for code contributions from people who know
> the subject intimately. nhc98 has the same primitive FFI as Hugs/ghc,
> so in theory, one good implementation in a mixture of C + Haskell
> should work for all systems. If you have written one, please make it
> available
> What about the other Haskell implementations?
> Do any of them implement the Haskell 98 Random module yet?
nhc98 does not yet implement Random, for the following reasons:
* substantial changes were made to the specification at a very
late stage;
* from the discussions then (when H'98 w
Fergus Henderson wrote:
>
> On 04-Feb-2000, Matt Harden <[EMAIL PROTECTED]> wrote:
> > >
> > > > class RandomGen g where
> > > >next :: g -> (Int, g)
> > > >split :: g -> (g, g)
> > > >genRange :: g -> (Int, Int)
> > > >genRange _ = (minBound, maxBound)
> >
> > Simon, do you thi
On 04-Feb-2000, Matt Harden <[EMAIL PROTECTED]> wrote:
> >
> > > class RandomGen g where
> > >next :: g -> (Int, g)
> > >split :: g -> (g, g)
> > >genRange :: g -> (Int, Int)
> > >genRange _ = (minBound, maxBound)
>
> Simon, do you think we could have the *optional* genRange desc
Matt Harden wrote:
>
> ... Darn. Now I want the genRange operation again. The
> "clarification" can really be a significant performance cost. Not to
> mention, you're also shortening the period of the RNG (perhaps by a
> factor of 4!).
>
> Can we have both (see below)?
>
> > class RandomGen
Jerzy Karczmarczuk wrote:
> > > class RandomGen g where
> > >next :: g -> (Int, g)
> > >split :: g -> (g, g)
> > >genRange :: g -> (Int, Int)
> > >genRange _ = (minBound, maxBound)
>
> Do you always use integer random numbers?
No. But this is the primitive class we're discussing
Jerzy Karczmarczuk writes:
> [...]
> I would love having 'next' returning reals as well...
> And vectors (with decently uncorrelated elements). Etc.
>
> Do you think that all that must be manufactured by the user, or
> can one parameterize the R. Gen. class a bit differently?
Try making ea
Jerzy Karczmarczuk ([EMAIL PROTECTED]) wrote:
[...]
: the Haskell standard libraries offer only the basic integer RNG,
: which will force all the users to reconstruct the needed reals,
: this is not extremely painful, but anyway.
: I would love having 'next' returning reals as well...
: And vec
Two things.
We have seen many times (last was Matt Harden) such definitions :
> > class RandomGen g where
> >next :: g -> (Int, g)
> >split :: g -> (g, g)
> >genRange :: g -> (Int, Int)
> >genRange _ = (minBound, maxBound)
Do you always use integer random numbers?
I don't know
Simon Peyton-Jones wrote:
>
> | This is a limitation, which precludes the usage of some clever
> | generation algorithms needing e.g. a prime modulus, or introducing
> | a computational overhead, most probably useless.
>
> The generator knows its own 'internal' range
> (e.g. your prime modulus).
| This is a limitation, which precludes the usage of some clever
| generation algorithms needing e.g. a prime modulus, or introducing
| a computational overhead, most probably useless.
The generator knows its own 'internal' range
(e.g. your prime modulus). All it needs to do is to generate
rando
Simon Peyton-Jones:
> ... --->>> genRange,
> I think it's worth adding. The reasons not to are
>
> a) it's a change to H98, which should be strongly discouraged
>
> b) I suppose it's possible that some RNG might not know
> its own range, or the range might chan
13 matches
Mail list logo
