http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #30 from paolo at gcc dot gnu.org
2012-04-29 23:36:15 UTC ---
Author: paolo
Date: Sun Apr 29 23:36:09 2012
New Revision: 186948
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186948
Log:
2012-04-29 Marc Glisse
Paolo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #29 from paolo at gcc dot gnu.org
2012-02-01 11:10:35 UTC ---
Author: paolo
Date: Wed Feb 1 11:10:30 2012
New Revision: 183795
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183795
Log:
2012-02-01 Paolo Carlini
PR lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #28 from Paolo Carlini 2012-01-30
15:52:00 UTC ---
As a matter of fact, I'm not able to prove that things can go wrong with the
normal Schrage when x == m - 1, at least given our other conds (eg, a < m). I
guess better not fiddling wi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #27 from Paolo Carlini 2012-01-28
10:51:12 UTC ---
It seems to me that something still safe to do now for 4.7.0 is special casing
the case x == m - 1 to x' = m - a, because, if I understand correctly what I'm
reading around, in that c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #26 from paolo at gcc dot gnu.org
2012-01-27 23:30:41 UTC ---
Author: paolo
Date: Fri Jan 27 23:30:28 2012
New Revision: 183655
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183655
Log:
2012-01-27 Paolo Carlini
PR lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #25 from Marc Glisse 2012-01-27
22:32:17 UTC ---
On the other hand, you can test the boost implementation without looking at the
code and notice the assertion failure if you ask for uint32_t (with uint64_t,
there is enough space to do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #24 from Paolo Carlini 2012-01-27
22:01:14 UTC ---
There aren't if afterwards you don't submit a patch to GCC ;) Seriously, I'm
pretty sure that there are many implementations around and Boost would be by
and large ok, but normally it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #23 from spoon.reloaded at gmail dot com 2012-01-27 21:52:48 UTC ---
By the way, the Boost library also has an implementation of this. Are there any
problems with the license to look at it?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #22 from Paolo Carlini 2012-01-27
21:43:50 UTC ---
Thanks for the link!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #21 from Paolo Carlini 2012-01-27
21:42:53 UTC ---
Paolo, not Paulo, by the way. Sure, you are right, I didn't personally write
these bits of random and for years I simply trusted the documentation which
doesn't point to any restricti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #20 from spoon.reloaded at gmail dot com 2012-01-27 21:39:11 UTC ---
Someone posted a thread here:
http://objectmix.com/java/312426-extending-schrage-multiplication.html
about ways to overcome the preconditions of Shrage's algorithm. Ma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #19 from spoon.reloaded at gmail dot com 2012-01-27 21:21:40 UTC ---
Paulo, in response to your suggestion to simply do multiplication and modulo in
#7 and #8, I don't think that would work in general. The example I gave
happened to hav
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #18 from Paolo Carlini 2012-01-27
14:04:28 UTC ---
Okay, thanks, but for generate we are 'lucky'. Thus, for 4.7 I'm going to add
the static_assert in linear_congruential and tweak generate to not use __mod at
all. Then we'll see.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #17 from Marc Glisse 2012-01-27
13:57:43 UTC ---
(In reply to comment #15)
> I'm not sure to understand: is using floating point quantities the way to go
> or
> not?
> Note we can also use long double.
I don't think there is any gua
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #16 from Paolo Carlini 2012-01-27
13:54:44 UTC ---
Uhm, in the case of generate, however, "each operation is to be carried out
modulo 2^32", thus I guess it's safe to not use __mod at all for the
multiplication.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #15 from Paolo Carlini 2012-01-27
13:42:27 UTC ---
I'm not sure to understand: is using floating point quantities the way to go or
not? I'm particularly worried by generate, as I said, much more than linear
congruential. Note we can a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #14 from Marc Glisse 2012-01-27
13:35:29 UTC ---
(In reply to comment #12)
> I see. Before asking: 26.5/4 says that "all descriptions of calculations in
> this subclause use mathematical real numbers".
Ok, no need to ask then.
> Thu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #13 from Paolo Carlini 2012-01-27
13:23:01 UTC ---
Note that besides the case of the linear_congruential (where we could
definitely static_assert, I don't consider such uses really important in
practice, given also that generators muc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #12 from Paolo Carlini 2012-01-27
13:17:22 UTC ---
I see. Before asking: 26.5/4 says that "all descriptions of calculations in
this subclause use mathematical real numbers". Thus should we use floats?!?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #11 from Marc Glisse 2012-01-27
13:12:05 UTC ---
(In reply to comment #10)
> Really, I don't think the intent here is involving arbitrary size integers.
> This stuff must be quick, and all the integers are unsigned. I don't think we
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #10 from Paolo Carlini 2012-01-27
13:01:23 UTC ---
Really, I don't think the intent here is involving arbitrary size integers.
This stuff must be quick, and all the integers are unsigned. I don't think we
have here something like the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #9 from Marc Glisse 2012-01-27
12:53:38 UTC ---
(In reply to comment #6)
> Marc, can you see a "quick and dirty" (ie, suited for 4.7 too) way to fix
> this?
Note that I am not a specialist.
1) add an assertion "not implemented yet,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #8 from Paolo Carlini 2012-01-27
12:47:10 UTC ---
Eg:
Index: random.h
===
--- random.h(revision 183615)
+++ random.h(working copy)
@@ -263,7 +263,7 @@
res
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #7 from Paolo Carlini 2012-01-27
12:35:28 UTC ---
As a matter of fact, I don't see why here (and elsewhere, eg generate) we have
to use the Schrage trick to avoid integer overflow: we know that the integers
are unsigned and I don't se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
Paolo Carlini changed:
What|Removed |Added
CC|paolo.carlini at oracle dot |marc.glisse at normalesup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #5 from Paolo Carlini 2012-01-27
11:41:28 UTC ---
Roughly, we have to fix either __calc or the generator itself to work fine also
when isn't true that __a << __m (which is the "normal" situation)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #4 from Paolo Carlini 2012-01-27
11:32:10 UTC ---
The problem is that isn't true that __r < __q, thus one of the preconditions
for the algorithm (as explained in eg, Numerical Recipes) is violated.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
Paolo Carlini changed:
What|Removed |Added
CC||paolo.carlini at oracle dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51795
--- Comment #1 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2012-01-27
04:48:39 UTC ---
I random.tcc in _Mod
__x = 1103527590
__m = 2147483648
__a = 1103515245
__c = 12345
static const _Tp __q = __m / __a; // 1
static cons
31 matches
Mail list logo
