On 08/13/2014 01:32 PM, Marc Glisse wrote:
On Wed, 13 Aug 2014, Paolo Carlini wrote:
... fixed with the below.
Could you please use __sq instead of recomputing it?
Patch preapproved, thanks!
Paolo.
On Wed, 13 Aug 2014, Paolo Carlini wrote:
... fixed with the below.
Could you please use __sq instead of recomputing it?
--
Marc Glisse
... fixed with the below.
Thanks,
Paolo.
//
2014-08-13 Paolo Carlini
PR libstdc++/62118
* include/ext/random.tcc (uniform_on_sphere_helper<2, _RealType>::
operator()): Use std::hypot only when _GLIBCXX_USE_C99_MATH_TR1.
Index: include/ext/random.tc
Ulrich--
On 08/13/2014 09:36 AM, Bin.Cheng wrote:
On Sun, Aug 10, 2014 at 2:00 AM, Ulrich Drepper wrote:
On Sat, Aug 9, 2014 at 1:40 PM, Marc Glisse wrote:
__x = result_type(2.0) * __aurng() - 1.0;
You're right, we of course need the negatives as well.
Assuming the 2 coor
On Wed, Aug 13, 2014 at 3:36 PM, Bin.Cheng wrote:
> On Sun, Aug 10, 2014 at 2:00 AM, Ulrich Drepper wrote:
>> On Sat, Aug 9, 2014 at 1:40 PM, Marc Glisse wrote:
>>> __x = result_type(2.0) * __aurng() - 1.0;
>>
>> You're right, we of course need the negatives as well.
>>
>>> Assum
On Sun, Aug 10, 2014 at 2:00 AM, Ulrich Drepper wrote:
> On Sat, Aug 9, 2014 at 1:40 PM, Marc Glisse wrote:
>> __x = result_type(2.0) * __aurng() - 1.0;
>
> You're right, we of course need the negatives as well.
>
>> Assuming the 2 coordinates are obtained through a rescaling x->2
On Sat, Aug 9, 2014 at 1:40 PM, Marc Glisse wrote:
> __x = result_type(2.0) * __aurng() - 1.0;
You're right, we of course need the negatives as well.
> Assuming the 2 coordinates are obtained through a rescaling x->2*x-1, if
> __sq is not exactly 0, it must be between 2^-103 and
On Sat, 9 Aug 2014, Ulrich Drepper wrote:
How about the patch below?
Looks good, with two details:
+template
+ class uniform_on_sphere_helper<2, _RealType>
+ {
+ typedef typename uniform_on_sphere_distribution<2, _RealType>::
+ result_type result_type;
+
+ pu
On 08/09/2014 11:33 AM, Marc Glisse wrote:
On Sat, 9 Aug 2014, Ulrich Drepper wrote:
If you are going to specialize for dim 2, I imagine you won't be
computing
normal distributions, you will only generate a point uniformy in a
square
and reject it if it is not in the ball? (interestingly enoug
Marc Glisse writes:
> On Sat, 9 Aug 2014, Ulrich Drepper wrote:
> Yes, you still need the normalization step (divide by the norm).
I guess we can do this.
How about the patch below? Instead of specializing the entire class for
_Dimen==2 I've added a class at the implementation level.
I've als
On Sat, 9 Aug 2014, Ulrich Drepper wrote:
If you are going to specialize for dim 2, I imagine you won't be computing
normal distributions, you will only generate a point uniformy in a square
and reject it if it is not in the ball? (interestingly enough this is used
as a subroutine by the impleme
On Sat, Aug 9, 2014 at 8:34 AM, Marc Glisse wrote:
> Oh, a comment saying exactly what you just said would be fine with me (or
> even nothing).
We might at some point use a different method than Box-Muller sampling
so I'm OK with the test.
> If you are going to specialize for dim 2, I imagine y
On Sat, 9 Aug 2014, Ulrich Drepper wrote:
On Sat, Aug 9, 2014 at 3:15 AM, Marc Glisse wrote:
While there, do we want to also reject infinite norms?
I would have done: while (__sum < small || __sum > large)
but testing exactly for 0 and infinity seems good enough.
I guess the squaring can the
On Sat, Aug 9, 2014 at 3:15 AM, Marc Glisse wrote:
> While there, do we want to also reject infinite norms?
> I would have done: while (__sum < small || __sum > large)
> but testing exactly for 0 and infinity seems good enough.
I guess the squaring can theoretically overflow and produce infinity.
On Fri, 8 Aug 2014, Ulrich Drepper wrote:
Now also for a fix of the sphere distribution. Unless someone objects
I'll check in the patch below.
2014-08-08 Ulrich Drepper
* include/ext/random.tcc
(uniform_on_sphere_distribution::__generate_impl): Reject
vectors with
Jonathan Wakely writes:
> On 23/07/14 11:58 +0200, Marc Glisse wrote:
> As an aside, we already have divide-by-zero bugs in , it
> would be nice if someone could look at that.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60037
Sorry, it took a while to get back to tihs and now the referenced
On 24 July 2014 22:15, Ulrich Drepper wrote:
> On Wed, Jul 23, 2014 at 6:29 AM, Jonathan Wakely wrote:
>> As an aside, we already have divide-by-zero bugs in , it
>> would be nice if someone could look at that.
>
> I'll take a look at this soon.
That would be great, thanks!
On Wed, Jul 23, 2014 at 6:29 AM, Jonathan Wakely wrote:
> As an aside, we already have divide-by-zero bugs in , it
> would be nice if someone could look at that.
I'll take a look at this soon.
On 23/07/14 11:58 +0200, Marc Glisse wrote:
* can't we end up dividing by 0 if all values of the normal
distribution happen to be 0?
As an aside, we already have divide-by-zero bugs in , it
would be nice if someone could look at that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60037
On Sat, 12 Jul 2014, Ulrich Drepper wrote:
Ed's submission of the logistic regression distribution caused problems
for me because, like Ed, I have changes to the header in my
tree for a long time. Time to submit them.
This first one is a new distribution. It generates coordinates for
random
On Wed, Jul 16, 2014 at 11:01 AM, Paolo Carlini
wrote:
> Right. And reset too. I'm going to test and apply the below.
Sorry for not reacting to this, I was away from the machines I could
have done that work on.
Hi,
On 07/16/2014 01:05 PM, Ed Smith-Rowland wrote:
One thing we all forgot: the operator== is also non-trivial because it
needs to compare _M_n.
Right. And reset too. I'm going to test and apply the below.
Thanks,
Paolo.
///
2014-07-16 Paolo Carlini
* include/
On 07/14/2014 04:14 AM, Paolo Carlini wrote:
Hi,
On 07/14/2014 09:58 AM, Andreas Schwab wrote:
FAIL: ext/random/arcsine_distribution/cons/default.cc (test for
excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20140714/libstdc++-v3/include/ext/random.tcc:1587:22:
error: '_M_n' was not declar
> I've checked in a patch to save the _M_n state.
If it is r212496, did you test it?
It breaks many tests (see
https://gcc.gnu.org/ml/gcc-regression/2014-07/msg00213.html)
/opt/gcc/work/libstdc++-v3/include/ext/random.tcc: In function
'std::basic_ostream<_CharT, _Traits>&
__gnu_cxx::operator<
Hi,
On 07/14/2014 09:58 AM, Andreas Schwab wrote:
FAIL: ext/random/arcsine_distribution/cons/default.cc (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20140714/libstdc++-v3/include/ext/random.tcc:1587:22:
error: '_M_n' was not declared in this scope
/daten/aranym/gcc/gcc-20140714
FAIL: ext/random/arcsine_distribution/cons/default.cc (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20140714/libstdc++-v3/include/ext/random.tcc:1587:22:
error: '_M_n' was not declared in this scope
/daten/aranym/gcc/gcc-20140714/libstdc++-v3/include/ext/random.tcc:1598:22:
error:
Hi,
On 07/13/2014 06:44 PM, Ulrich Drepper wrote:
But your 4th and 7th call example by itself is not a reason. Again,
the input exclusively determined by the random numbers. Here, of
course, the 4th and 7th use will produce different results. But this
is not what the state of the distribution
On Sun, Jul 13, 2014 at 12:25 PM, Paolo Carlini
wrote:
> I don't think so. It depends on the past of the two different
> uniform_on_sphere: each time each uniform_on_sphere calls _M_n(__urng) the
> state of *its own* _M_n changes, evolves from the initial state.
I indeed should use the normal_dis
Hi,
On 07/13/2014 06:18 PM, Ulrich Drepper wrote:
On Sun, Jul 13, 2014 at 12:07 PM, Paolo Carlini
wrote:
Sorry, I still don't get it. When operator() of x and y, two
uniform_on_sphere_distribution, call _M_n(__urng) and those _M_n have a
different state, the numbers produced are in general dif
On Sun, Jul 13, 2014 at 12:07 PM, Paolo Carlini
wrote:
> Sorry, I still don't get it. When operator() of x and y, two
> uniform_on_sphere_distribution, call _M_n(__urng) and those _M_n have a
> different state, the numbers produced are in general different.
Correct. But in the case of this distr
Hi,
On 07/13/2014 06:03 PM, Ulrich Drepper wrote:
On Sun, Jul 13, 2014 at 11:43 AM, Paolo Carlini
wrote:
and I think: the normal distributions in x and y do have a non-trivial state
(_M_saved, _M_saved_available) which, at any given moment, is different in x
and y. Then the trivial inserter of
On Sun, Jul 13, 2014 at 11:43 AM, Paolo Carlini
wrote:
> and I think: the normal distributions in x and y do have a non-trivial state
> (_M_saved, _M_saved_available) which, at any given moment, is different in x
> and y. Then the trivial inserter of x is called and the trivial extractor of
> y is
Hi,
On 07/13/2014 04:11 PM, Ulrich Drepper wrote:
On Sun, Jul 13, 2014 at 9:55 AM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
So I would just serialize _M_n here.
It has fixed parameters. This would mean unnecessary work. When you
try to use the parameter of the sphere distribution the norm
On 07/13/2014 10:11 AM, Ulrich Drepper wrote:
On Sun, Jul 13, 2014 at 9:55 AM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
So I would just serialize _M_n here.
It has fixed parameters. This would mean unnecessary work. When you
try to use the parameter of the sphere distribution the normal
di
On Sun, Jul 13, 2014 at 9:55 AM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> So I would just serialize _M_n here.
It has fixed parameters. This would mean unnecessary work. When you
try to use the parameter of the sphere distribution the normal
distribution will be reset. So there really is n
> are these dummy implementations intended?
Yes. There is no state. The only parameter is the dimensionality
which is a template parameter.
We do often serialize underlying helper distributions, in your case the
normal distribution _M_n.
While the normal distribution mean and stddev are tr
Hi,
On 07/13/2014 12:04 PM, Ulrich Drepper wrote:
On Sun, Jul 13, 2014 at 5:24 AM, Paolo Carlini wrote:
are these dummy implementations intended?
Yes. There is no state. The only parameter is the dimensionality
which is a template parameter.
Ah, interesting, didn't look close enough, sorry.
On Sun, Jul 13, 2014 at 5:24 AM, Paolo Carlini wrote:
> are these dummy implementations intended?
Yes. There is no state. The only parameter is the dimensionality
which is a template parameter.
Hi,
On 07/13/2014 04:00 AM, Ulrich Drepper wrote:
+ template
+std::basic_ostream<_CharT, _Traits>&
+operator<<(std::basic_ostream<_CharT, _Traits>& __os,
+ const __gnu_cxx::uniform_on_sphere_distribution<_Dimen,
+
On Sat, Jul 12, 2014 at 10:00 PM, Ulrich Drepper wrote:
> The patch is tested against the current tree without causing additional
> problems.
>
> OK?
Ignore the values.cc test case, it's a left-over from copying existing
tests and modifying them for a new distribution. This test does not
apply t
Ed's submission of the logistic regression distribution caused problems
for me because, like Ed, I have changes to the header in my
tree for a long time. Time to submit them.
This first one is a new distribution. It generates coordinates for
random points on a unit sphere in arbitrarily many di
41 matches
Mail list logo
