This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: using tr1's random in parallel/random_number.h


 
> I think we can use TR1 functionality for some or all of this file.
> Here's a patch to use TR1's mersenne_twister. The next step would be
> trying to replace __gnu_parallel::random_number with TR1 equivalents
> and change usage.

Hmmm.

Well, here's the evolution of this patch. It uses tr1/random and
tr1/cstdint for some of the types in parallel mode. It's more of a
"request for help" than a patch submission.

It's not done yet though.... I am having problems with random_shuffle.
I'm not quite sure how to work the templates in that file: in this
diff I think I confused random number generators with engines. Part
of this problem is the existing issues with this in the code....
also, why does  DRSSorterPU take a RandomNumberGenerator template
parameter if there is nothing dependent on this type in the class? 

With this patch I get two new failures that demonstrate the incomplete
nature of this transition.

FAIL:
25_algorithms/random_shuffle/requirements/explicit_instantiation/2.cc
(test for excess errors) FAIL:
25_algorithms/random_shuffle/requirements/explicit_instantiation/pod.cc
(test for excess errors)

In addition, these new fails (expected) for using tr1:

FAIL: 17_intro/using_namespace_std_tr1_neg.cc  (test for errors, line
64)

Anyway. 

I also have not checked the performance implications of this patch.

I do think that re-using more standard types for stuff in parallel mode
is a good idea. Thoughts?

-benjamin

Attachment: p.20071221-1
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]