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
To Tom Pledger's <[EMAIL PROTECTED]>
>> instance (Bounded a, Enum a) => Random a where ...
>>
>> But, every type in (Bounded, Enum) has a potential instance of Random,
>> using no properties of the type except its Bounded and Enum functions.
> [..]
Marcin 'Qrczak' Kowalczyk <[EMAIL PROT
On 04-Feb-2000, S.D.Mechveliani <[EMAIL PROTECTED]> wrote:
> If goodOp is an operation of *class* C, then C.goodOp
> - when needed, - looks like a good disambiguation forgoodOp
> (is it of Haskell ?).
No, Haskell doesn't allow that.
Nor does Mercury allow the equivalent, though thi
I wrote recently on the need of prefix or suffix for `next',`split'
of Random.
Somebody corrected me, saying that Random.next
is, at least, possible.
It is all right. But I would like to add something.
If goodOp is an operation of *class* C, then C.goodOp
- when needed, - looks like a
S.D.Mechveliani wrote:
| Haskell uses the names `next', `split' for Random.
| Maybe, it is better to add some prefix or suffix?
No!
Haskell has a perfectly fine module system which can take
care of these kind of issues. If you have other definitions
of "split" or "next", use "Random.split" or
More on randoms.
Haskell uses the names `next', `split' for Random.
Maybe, it is better to add some prefix or suffix?
For there are so many basic operations in the universe that can be
naturally called `next' and `split'. And Random does not look so
priveleged to enjoy privately such a simple n
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
10 matches
Mail list logo
