Opened 10 years ago
Closed 10 years ago
#173 closed defect (fixed)
rnd(1000) gives faulty result
Reported by: | Alpar Juttner | Owned by: | Alpar Juttner |
---|---|---|---|
Priority: | critical | Milestone: | LEMON 1.1 release |
Component: | core | Version: | release branch 1.0 |
Keywords: | Cc: | ||
Revision id: | 4b2382fd80ef and r1.0 |
Description (last modified by )
If you call the operator() with an integer value, it will give faulty result (i.e. it is 0 all the time)
Attachments (1)
Change History (8)
Changed 10 years ago by
Attachment: | c4aa9f097ef1.patch added |
---|
comment:1 follow-up: 2 Changed 10 years ago by
Description: | modified (diff) |
---|---|
Priority: | major → critical |
Status: | new → assigned |
comment:2 follow-up: 3 Changed 10 years ago by
Replying to alpar:
- I just removed
real<Num>(Num)
andreal<Num>(Num,Num)
, as they suffer from the same problem and they are of no practical use.
We could have something like that:
template <typename Number> Number operator()(Number b) { return static_cast<Number>(real() * b); }
Or we could remove these functions, as you did. It depends on what we want. Should rnd(1000)
return a double
or an int
value? Should rnd(1000)
be the same as rnd(1000.0)
, or they should differ?
comment:3 follow-up: 4 Changed 10 years ago by
Replying to kpeter:
We could have something like that:
template <typename Number> Number operator()(Number b) { return static_cast<Number>(real() * b); }
No, no, no! This would suffer from the same problem as the current version plus would introduce two more:
- the generation of a
float
would slow down - the random
long double
would contain no more random bits than a randomdouble
Or we could remove these functions, as you did. It depends on what we want. Should
rnd(1000)
return adouble
or anint
value?
A double
, of course, it must return a uniformly distributed real number from [0,1000)
. For generating integers from the interval [0..999]
you must use rnd[1000]
.
Should rnd(1000)
be the same as rnd(1000.0)
, or they should differ?
It should certainly be the same.
comment:4 follow-up: 5 Changed 10 years ago by
Replying to alpar:
No, no, no! This would suffer from the same problem as the current version
Why? I think not, because in the above solution the double --> int
conversion would be preformed after the multiplaction, not before it.
plus would introduce two more:
- the generation of a
float
would slow down- a random
long double
would contain no more random bits than a randomdouble
It is true.
A
double
, of course, it must return a uniformly distributed real number from[0,1000)
. For generating integers from the interval[0..999]
you must usernd[1000]
.
Then your patch is the correct solution.
However I think it also suffers from the following problems:
- the generation of a
float
would slow down - the random
long double
would contain no more random bits than a randomdouble
comment:5 follow-up: 6 Changed 10 years ago by
Replying to kpeter:
Why? I think not, because in the above solution the
double --> int
conversion would be preformed after the multiplaction, not before it.
It is a bit better, but it still features the same problem: rnd(1000)
gives something different (i.e. a random integer) from what would be expected (i.e. a random real floating point number).
Then your patch is the correct solution.
However I think it also suffers from the following problems:
- the generation of a
float
would slow down- the random
long double
would contain no more random bits than a randomdouble
No, because operation()
is now obviously only for generating a double
. It is clear that if you want to generate a long double
(or a {{float}}} very fast), then you must use real<>()
.
comment:6 follow-up: 7 Changed 10 years ago by
Replying to alpar:
It is a bit better, but it still features the same problem:
rnd(1000)
gives something different (i.e. a random integer) from what would be expected (i.e. a random real floating point number).
Exactly. That's why I wrote at the beginning that the solution depends on what we want (in which I was not sure).
So I think your changeset should be merged into both branches.
comment:7 Changed 10 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
[c4aa9f097ef1] fixes this error by
double
as the parameters and return value ofoperator()
instead of a template parameters.real<Num>(Num)
andreal<Num>(Num,Num)
, as they suffer from the same problem and they are of no practical use.Please review the path so that it could be merge to the main as well as the 1.0 branch.