headers
Steven Watanabe | 1 Nov 02:17
Picon

Re: [phoenix] accumulate with data member binding

AMDG

Christian Henning wrote:
> bind( &point::_prob, arg1 )
>   

std::accumulate takes a binary function object.  Try:

arg1 + bind(&point::_prob, arg2)

In Christ,
Steven Watanabe
Permalink | Reply | 1 comment |
headers
Sergey Sadovnikov | 1 Nov 10:52
Picon

Re: [phoenix] accumulate with data member binding

Hello, Christian.

Saturday, November 1, 2008 at 1:15:54 AM you wrote:

CH> Hi there, the following snippet doesn't compile which surprises me a
CH> little. Could somebody tell what's wrong?

Try following:
double sum_prob = std::accumulate( d.begin()
                                 , d.end()
                                 , 0.0
                                 , bind( &point::_prob)(arg1)
                                 );

--

-- 
Best Regards,
 Sergey
Permalink | Reply | 2 comments |
headers
Vaclav Haisman | 1 Nov 10:53
Picon
Picon

Re: using boost::tokenizer within boost::bimap

Sean Farrow wrote:
> Hi: 
> I'd like to use boost::tokenizer in boost::bimap.
> I currently have:
> boost::bimaps::bimap<boost::bimaps::unordered_set_of<boost::tokenizer<bo
> ost::char_separator<char>>>, std::string> CodeList; 
> 
> I'm getting the following errors:
> 
> 1>------ Build started: Project: VDux, Configuration: Release Win32
> ------
> 
> 1>Compiling...
> 
> 1>VDux.cpp
> 
> 1>c:\program files\boost\boost/functional/hash/extensions.hpp(72) :
> error C2665: 'boost::hash_value' : none of the 16 overloads could
> convert all the argument types
> 
> 1> c:\program files\boost\boost/functional/hash/hash.hpp(33): could be
> 'size_t boost::hash_value(bool)'
> 
> 1> c:\program files\boost\boost/functional/hash/hash.hpp(34): or 'size_t
> boost::hash_value(char)'
> 
> 1> c:\program files\boost\boost/functional/hash/hash.hpp(35): or 'size_t
> boost::hash_value(unsigned char)'
> 
> 1> c:\program files\boost\boost/functional/hash/hash.hpp(36): or 'size_t
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sean Farrow | 1 Nov 13:10
Picon

Re: using boost::tokenizer within boost::bimap

Hi: 
Any help with either creating a hash function, or storing pointers
accepted.
Cheers
Sean. 

-----Original Message-----
From: boost-users-bounces <at> lists.boost.org
[mailto:boost-users-bounces <at> lists.boost.org] On Behalf Of Vaclav Haisman
Sent: 01 November 2008 09:54
To: boost-users <at> lists.boost.org
Subject: Re: [Boost-users] using boost::tokenizer within boost::bimap

Sean Farrow wrote:
> Hi: 
> I'd like to use boost::tokenizer in boost::bimap.
> I currently have:
> boost::bimaps::bimap<boost::bimaps::unordered_set_of<boost::tokenizer<
> bo ost::char_separator<char>>>, std::string> CodeList;
> 
> I'm getting the following errors:
> 
> 1>------ Build started: Project: VDux, Configuration: Release Win32
> ------
> 
> 1>Compiling...
> 
> 1>VDux.cpp
> 
> 1>c:\program files\boost\boost/functional/hash/extensions.hpp(72) :
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stjepan Rajko | 1 Nov 18:26
Picon

Re: non-deterministic state diagram

Hi Andrej,

On Thu, Oct 23, 2008 at 6:26 PM, Andrej van der Zee <mavdzee <at> yahoo.co.uk> wrote:
> Hi,
>
> I need to calculate the non-deterministic state diagram from raw data and was wondering how boost can hep me.
>
> More specific, I have many state transition sequences (lets say up to 100-thousand) that all start at
state A, such as:
> A -> B -> D -> B -> E
> A -> D -> B -> C -> B
> A -> E -> D -> F -> D
>
> Now I want to calculate the non-deterministic state diagram with a chance for each transition, and
desirable in real-time. For example, for the raw data above, the transition for A -> B is 0.33.
>

What do you mean by 'in real time'?  Do you get a new transition
sequence at a certain frame rate, and need to update your
probabilities?  Or do you get a new element of each sequence?  (or
something else?)

I am working on a pattern recognition library (temporal patterns, for
now), and a part of it involves calculating transition probabilities
for a probabilistic model (hidden markov model-based).  The problem
that the library deals with is slightly more general than what you
have here, but would do the trick.  It might not be as efficient as
you might need it for the size of your problem, though.

The library has so far only offered models that are specific to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stjepan Rajko | 1 Nov 20:22
Picon

[signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st

Hello all,

The review for the Signals2 library (formerly known as
thread_safe_signals) submitted by Frank Mori Hess begins today (Nov
1st) and is scheduled to end on Nov 10th.  I would like to thank Franz
Alt, Terry Golubiewski, Doug Gregor, Ravikiran Rajagopal and Andrew
Webber for making this review possible by committing to reviewing the
library.

How to submit a review:
--------

As usual, EVERYONE is welcome to participate in the review discussions
and to submit a review.   I strongly encourage participation from
reviewers that would examine the library from a purely user standpoint
(commenting on the interface and / or the documentation), as well as
reviewers that would be willing to look into the details of the
implementation (i.e., you don't have to focus on both).

Here are some questions you might want to answer in your review (feel
free to skip those that don't apply to your analysis):

    * What is your evaluation of the design?
    * What is your evaluation of the implementation?
    * What is your evaluation of the documentation?
    * What is your evaluation of the potential usefulness of the library?
    * Did you try to use the library? With what compiler? Did you have
any problems?
    * How much effort did you put into your evaluation? A glance? A
quick reading? In-depth study?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael | 1 Nov 22:21
Picon

Re: shared_ptr leaking memory and crashing / gcc 3.4.6

Peter Dimov wrote:
>> Anybody interested in this or could point me to a different boost list?
>>
>> Michael wrote:
>>> Hello,
>>>
>>> I figured that shared_ptr (boost 3.4, but I don't think this is 
>>> really a boost problem) will lose memory in the following example
> ...
>>> int main(int argc, char** argv)
>>> {
>>>   while (true)
>>>   {
>>>     XRef myX;
>>>     try
>>>     {
>>>       myX = getx();
>>>     }
>>>     catch(...)
>>>     {
>>>     }
>>>   }
>>> }
> ...
>>> Platform is FreeBSD 6, gcc 3.4.6. It only happens when compiled like 
>>> above (without optimization).
> 
> I'm interested in principle in everything concerning shared_ptr, but I'm 
> not sure what we can do about this specific case. Maybe report it to the 
> GCC Bugzilla? Is 3.4.6 even being maintained?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christian Henning | 1 Nov 22:46
Picon

Re: [phoenix] accumulate with data member binding

Thanks Steven. That worked.

On Fri, Oct 31, 2008 at 9:17 PM, Steven Watanabe <watanabesj <at> gmail.com> wrote:
> AMDG
>
> Christian Henning wrote:
>>
>> bind( &point::_prob, arg1 )
>>
>
> std::accumulate takes a binary function object.  Try:
>
> arg1 + bind(&point::_prob, arg2)
>
> In Christ,
> Steven Watanabe
>
> _______________________________________________
> Boost-users mailing list
> Boost-users <at> lists.boost.org
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
Permalink | Reply | 0 comments |
headers
Christian Henning | 1 Nov 22:48
Picon

Re: [phoenix] accumulate with data member binding

Sergey, I tried your code but it fails on me when using Visual Studio
9. It creates 18 errors. Here is a snippet:

1>c:\boost\boost\spirit\home\phoenix\core\detail\function_eval.hpp(40)
: error C2825: 'boost::phoenix::detail::function_eval<0>::result<Env,F>::fn':
must be a class or namespace when followed by '::'
1>        with
1>        [
1>            Env=boost::phoenix::basic_environment<>,
1>            F=boost::phoenix::value<double point::* >
1>        ]
1>        c:\boost\boost\spirit\home\phoenix\core\detail\composite_eval.hpp(88)
: see reference to class template instantiation
'boost::phoenix::detail::function_eval<0>::result<Env,F>' being
compiled
1>        with
1>        [
1>            Env=boost::phoenix::basic_environment<>,
1>            F=boost::phoenix::value<double point::* >
1>        ]
1>        c:\boost\boost\spirit\home\phoenix\core\composite.hpp(64) :
see reference to class template instantiation
'boost::phoenix::detail::composite_eval<1>::result<Composite,Env>'
being compiled
1>        with
1>        [
1>            Composite=boost::phoenix::composite<boost::phoenix::detail::function_eval<0>,boost::fusion::vector<boost::phoenix::value<double
point::* >,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_,boost::fusion::void_>>,
1>            Env=boost::phoenix::basic_environment<>
1>        ]
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Dimov | 1 Nov 23:07

Re: shared_ptr leaking memory and crashing / gcc 3.4.6

Michael:
...

>>>> int main(int argc, char** argv)
>>>> {
>>>>   while (true)
>>>>   {
>>>>     XRef myX;
>>>>     try
>>>>     {
>>>>       myX = getx();
>>>>     }
>>>>     catch(...)
>>>>     {
>>>>     }
>>>>   }
>>>> }

...

> Posting a bug at the gcc mailing list would only be an option if I can 
> track this further down so I can report it without referring to boost 
> (otherwise I'm pretty sure they will tell me to report this to the boost 
> mailing list :).

FWIW, I have reported g++ bugs in the past that made boost::shared_ptr 
misbehave, and they did get acknowledged and fixed, so this might still be 
worth a try. I did not need to distill it down to an example that did not 
#include anything Boost, although I think I did follow
(Continue reading)

Permalink | Reply | 0 comments |

Gmane