headers
John Phillips | 1 Feb 01:25
Picon

Re: Numeric constants

Max wrote:

> 
> :-) with my face getting red for a while.
> 
> B/Rgds
> Max
> 

   Sorry. I guess that came out a little more snarky than I intended.

			John

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 1 comment |
headers
Max | 1 Feb 02:34
Favicon

Re: Numeric constants

> > :-) with my face getting red for a while.
> >
> > B/Rgds
> > Max
> >
> 
>    Sorry. I guess that came out a little more snarky than I intended.
> 
> 			John

Not at all. Thanks for your comments. :-)

B/Rgds
Max

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
James Porter | 1 Feb 03:14
Picon

Re: Interest check: memoization

Mathias Gaunard wrote:
> James Porter wrote:
> 
>> The recursize memoizer is useful for memoizable functions that call 
>> themselves. The basic memoizer doesn't easily allow for this
> 
> Couldn't it be done using a Y combinator?

Possibly. I wouldn't exactly call that "easy" though (unless you already 
have a Y combinator handy). :) The recursive_memoizer class template is 
designed to make that subtype of memoization problems trivial to implement.

In general, I'd say that memoization is not a conceptually difficult 
idea, so the interfaces should reflect that.

- Jim

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Sean Farrow | 1 Feb 12:01
Picon

tokenizer feature request

Hi: 
I would like to request a hash function for tokenizer be implemented.
I'm not sure how doable this is, but need to use this for a project I'm
involved in.
Cheers
Sean.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Sean Farrow | 1 Feb 12:42
Picon

test--please ignore


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Bjørn Roald | 1 Feb 18:01

Re: Interest in a library for building simulations of dynamical systems?

Jay Graham wrote:
> Is there interest in a library for building simulations of dynamical
> systems represented by time-based differential equations?
>   

Yes.

> The proposed library would implement ideas found in the C++ Model Developer
> (CMD) library developed by Ray Sells, but in a more generic way. 
>   

Ok

> For more information on CMD see:
>
> http://www.dtic.mil/srch/doc?collection=t2&id=ADA433836
>
> and
>
> http://rocket.itsc.uah.edu/u/education/files/R/IPT_Producer/AIAA/Sells/Sells.ppt
>   

These documents indicate that CMD itself comes in an open source 
distribution with permissive licensing.  However, I was not able to find 
a download site for the distribution.  Anybody have a pointer to where 
this may be downloaded?    

--

-- 
Bjørn
(Continue reading)

Permalink | Reply | 1002 comments |
headers
Edouard A. | 1 Feb 18:49

[parallel_sort] Proposal

Howdy,

I just finished the first working version of parallel_sort. It seems there
is a lot of interest for this function in the C++ community, and in the
boost community specifically, which is the motivation for this post. ;)

My implementation is somewhat very different in nature from the one present
in Intel's TBB. It's designed to take advantages of a multi-core user
machine, it's not designed to run on a grid for massive sorting operation. 

It only uses the STL and the boost library. It doesn't have any fancy
prerequisites, except having several cores to unleash its power!

Current benchmarks on my Q6600 vs2008-64-bit default allocator:

2 threads : 160 % faster

4 threads : 260 % faster

Keep in mind the Q6600 is not a real equivalent to a quad-cpu machine and
that the default memory allocator is not multithreading friendly.

It can be heavily customized. I already offer the possibility to choose
between quick sorting and merge sorting, and for quick sorting I offer two
pivot algorithms : fast or secure. Then you can of course specify a
predicate and a fallback sorting algorithm for when you run out of threads.

If you don't care to customize, no problem! Just write:

parallel_sort<2>(v.begin(), v.end()); // sort with 2 threads
(Continue reading)

Permalink | Reply | 20 comments |
headers
Beman Dawes | 1 Feb 18:53
Picon
Favicon
Gravatar

[filesystem] Version 3 request for comments

A prototype implementation of version 3 of Boost.Filesystem is available 
for comment.

The critical feature of this prototype is the replacement of the class 
basic_path template with a single class path that supports both narrow 
and wide character paths.  It also supports user supplied types, and 
will support the new C++0x char16_t and char32_t character types as 
compiler and standard library support becomes available.

There is still a lot of additional work before V3 could be added to the 
trunk and eventually released. For example, work so far has concentrated 
on the new functionality, and ignored breaking changes to existing code. 
But enough stuff is working to make requesting comments useful.

See 
http://svn.boost.org/svn/boost/sandbox/filesystem-v3/libs/filesystem/doc/v3_design.html 
for a fuller description of the prototype and links to the prototype 
implementation.

I've got some specific issues I'd like opinions on, but would first like 
to hear comments from anyone interested.

--Beman
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 21 comments |
headers
Christopher Jefferson | 1 Feb 19:14

Re: [parallel_sort] Proposal


On 1 Feb 2009, at 17:49, Edouard A. wrote:

> Howdy,
>
>
> If you don't care to customize, no problem! Just write:
>
>
>
> parallel_sort<2>(v.begin(), v.end()); // sort with 2 threads

Does templating on the number of threads produce a large gain, as  
opposed to making it a run-time option? Having to compile separate  
executables for different numbers of cores seems a bit limiting.

Chris

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 5 comments |
headers
Beman Dawes | 1 Feb 19:20
Picon
Favicon
Gravatar

Re: [1.38] CMake support added to release branch?

On Sat, Jan 31, 2009 at 11:57 AM, John Maddock <john <at> johnmaddock.co.uk> wrote:
> I see from the 1.38 news section that experimental CMake support has been
> added to the release: I thought we were going to have a review before this
> happened?

Hum... I must have missed that discussion, and OK'ed the request to merge.

The CMake support is certainly experimental, but do you think there is
any harm done by including it in the release in its current state?  We
can certainly publicize the fact that the support is experimental.

--Beman
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 10 comments |

Gmane