[Boost-users] Boost 1.35 Release Date

[Chauhan, Vikas]

Hello all,

Following on the original post. Does anybody have anymore updates on
BOOST 1.35 (rc1) release date?
Is there a location on Boost website where I can get this information?

Thanks and regards,
Vikas

> Message: 6
> Date: Wed, 28 Nov 2007 16:37:43 +0100
> From: "Tarjei Knapstad" <tarjei....@gmail.com>
> Subject: Re: [Boost-users] Boost 1.35 release date
> To: boost...@lists.boost.org
> Message-ID:
> <ff5e09cc0711280737g1a1...@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 26/11/2007, Chauhan, Vikas <Vikas....@anritsu.com> wrote:
> >
> > Hello,
> >
> > Can you please advise the planned release date for BOOST
> 1.35 version.
> >
>
> >From Beman's post on the main Boost list:
> <quote>
> * Merge for release complete: Sunday, November 25th.
> * Start testing release candidate build process: Monday, December 3rd.
> * Release Candidate 1: Monday, December 10th.
> </quote>
>
> So I'm guessing early next year if there's not too much
> trouble with the RC's. My guess is as good as yours though :)
>
> --
> Tarjei
>
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Scott Meyers]

Chauhan, Vikas wrote:
> Hello all,
>
> Following on the original post. Does anybody have anymore updates on
> BOOST 1.35 (rc1) release date?
> Is there a location on Boost website where I can get this information?

I did not see a followup to this, and I, too, am interested in where I can get
information on the timing and content of 1.35.

Thanks,

Scott

[Scott Meyers]

Chauhan, Vikas wrote:
> Hello all,
>
> Following on the original post. Does anybody have anymore updates on
> BOOST 1.35 (rc1) release date?
> Is there a location on Boost website where I can get this information?

I did not see a followup to this, and I, too, am interested in where I can get

information on the timing and content of 1.35.

Thanks,

Scott

_______________________________________________

[Lars-Peter Ellekilde]

Hi
I have been trying to use the a* implementation in BGL to do a shortest
path search in en undirected graph. In my application I can not
guarantee that the graph only contains a single connected components,
thus a solution may not always exist. Given a query where start and goal
are in two different components the a* algorithm appears to loop forever.

Is this expected behavior or does it indicate that I might be using it
wrong somehow? If it is expected, what will be the best way to make the
algorithm terminate and indicate there is no solution (perhaps I use the
visitor for this purpose).

Best regards and thanks
- Lars-Peter

[Aaron Windsor]

On Jan 15, 2008 2:13 AM, Lars-Peter Ellekilde <l...@mmmi.sdu.dk> wrote:
> Hi
> I have been trying to use the a* implementation in BGL to do a shortest
> path search in en undirected graph. In my application I can not
> guarantee that the graph only contains a single connected components,
> thus a solution may not always exist. Given a query where start and goal
> are in two different components the a* algorithm appears to loop forever.
>
> Is this expected behavior or does it indicate that I might be using it
> wrong somehow? If it is expected, what will be the best way to make the
> algorithm terminate and indicate there is no solution (perhaps I use the
> visitor for this purpose).
>
> Best regards and thanks
> - Lars-Peter

Hi Lars-Peter,

Can you give more information about the case were the implementation
appears to loop forever? What platform are you using? Do you have a
relatively small example that causes it to loop? There's a note in the
code that mentions a case where the implementation can loop on x86
Linux.

The generally accepted way to break out of any BGL traversal early is
to have the visitor throw an exception, so if you have an easy way of
detecting that you won't be able to find the goal at all, you may want
to consider this approach.

Regards,
Aaron

[Lars-Peter Ellekilde]

Hi
Thanks for the reply. I haven't seen the comment about x86 Linux in the
code, but guess it very well be my problem.
The program I am writing constructs a graph with random data, thus it is
difficult for me to reproduce the error in a small example.

Any good ideas on how best to detect if it enters an infinite loop?
Would it be possible just to use the visitor and see if the vertex under
examination is the same as the previous one?

Regards
Lars-Peter

[Aaron Windsor]

> On Jan 17, 2008 7:05 AM, Lars-Peter Ellekilde <l...@mmmi.sdu.dk> wrote:
> Hi

> Thanks for the reply. I haven't seen the comment about x86 Linux in the
> code, but guess it very well be my problem.
> The program I am writing constructs a graph with random data, thus it is
> difficult for me to reproduce the error in a small example.
>
> Any good ideas on how best to detect if it enters an infinite loop?
> Would it be possible just to use the visitor and see if the vertex under
> examination is the same as the previous one?

The comment about looping seems to indicate that the A* visitor's
"edge_not_relaxed" method will be repeatedly called. You may want to
stick a std::cout in this method and see what's happening when the
looping occurs - I don't know whether it will loop on the same edge or
on a sequence of edges, but you may be able to short-circuit the
search there.

Regrds,