Talk:Bellman–Ford algorithm

RELAX?!?!? DON'T TELL ME TO RELAX WITHOUT DEFINING IT!!!

What a terrible, atrocious article, made all the worse by that fact that I cannot find a single decent explanation of it online (at least nowhere on the first page of Google results). This article doesn't explain the algorithm. It just puts a bunch of jargon up and walks away. You call that an explanation? Fuck you and the jargon-speaking horse you rode in on! How do I submit this article for deletion? 98.180.51.94 (talk) 23:14, 30 April 2013 (UTC)

Good job David Eppstein! You seem like an awesome fellow! Hats off to you. :-) 98.180.51.94 (talk) 02:16, 1 May 2013 (UTC)

yeah can find a decent step by step guide to this on line. one that describes each detail of each step otherwise im not going to get it. — Preceding unsigned comment added by 84.203.48.54 (talk) 19:53, 21 May 2013 (UTC)

Pseudocode bug?

The pseudocode in the article states:

for i from 1 to size(vertices)-1:

I'm pretty sure that it's supposed to be

for i from 0 to size(vertices)-1:

or, equivalently

for i from 1 to size(vertices):

The program I made based on the pseudocode didn't work until I made this change. Can anyone confirm that this is indeed the case (and not just some other bug in my program) and if so, correct the article? --Smallhacker (talk) 15:38, 3 March 2011 (UTC)

One more clarification on the Pseudocode

for each edge (u, v) with weight w in edges:

in this line what is u ? I beleive u should be changed to i or vice versa. — Preceding unsigned comment added by 49.203.64.216 (talk) 08:38, 25 May 2014 (UTC)

proposed answer

   for i from 1 to size(vertices) - 1

is correct.

in other other words: you intentionally leave one vertex out. reason: let a shortest path from s to an arbitrary vertex v contain k edges. that means, the path p from s to v can be described as follows: p = (s = v₀, v₁, ..., v_k-1, v_k = v). in the worst case the shortest path visits all vertices of the graph. these are size(vertices). but the path between s and v only contains size(vertices) - 1 edges. the algorithm tries to relax all edges for every edge on the shortest path - followingly, only size(vertices) - 1 relax-iterations have to be computed.

Pop up shortest-path figure

The "shortest path" link in the first sentence pops up a figure whose caption refers to edge weights, yet the figure doesn't show any. Mdmi (talk) 21:25, 2 April 2019 (UTC)

That is an issue with the shortest path problem article, not with this article. The pop-up always picks the first image in the article, and the first image of that article was not a particularly useful one. —David Eppstein (talk) 00:05, 3 April 2019 (UTC)

Bellman–Ford algorithm in the informational description of the black hole

Write the text.

Does the shortest path of the informational chunks always result in a mixed state? We want that because a pure state will lead to informational loss. One other option is that informational loss exists, but isn't fundamental, because it is the result of untangling a more fundamental field, and dissipating that infoloss into the same spacetime field as virtual particles. — Preceding unsigned comment added by 2A02:587:4118:7CA3:2891:994B:40B:F97D (talk) 21:15, 7 August 2020 (UTC)

Whether this has anything real to do with shortest paths, or is just buzzword salad, I'm not sure, but it doesn't appear to have anything to do with this article, which is about a specific method for finding shortest paths and not on the general topic of shortest paths. And it also appears to be off-topic for this talk page, which is about improvements to the article based on published reliable sources. —David Eppstein (talk) 21:42, 7 August 2020 (UTC)

Animated example

The animated gif in the article, while it is a very good initiative, seems to be either wrong or at least confusing.

First of all, what do the numbers next to the vertices mean? If they're the estimated distances, then iiuc they're not supposed to increase. But they do: v4 changes from 4 to 6 between frame #5 and frame #6, just as v3 does between frame #4 and frame #5.

Also, aren't there supposed to be 5 frames instead of 6? That is, the initial state plus the |V|-1 = 4 steps of the algorithm.

And what do the thick arrows and grey vertices mean? Are they the vertices we already have the final distances of, and the shortest paths leading to them? The problem with this is that the algorithm is not supposed to "know" these at that point - if we stop there, we cannot be sure that we would not get better results (shorter paths) for these vertices in a later step.

Thoughts by another editor

I agree with the confusion. I believe that v3 and v4 incorrectly update. There is no possible path by which the cost to v4 is 4, so there's no way the algorithm should ever update the weight to 4. And like the parent said, the algorithm should never increase the weight, so v3 shouldn't temporarily change to 6 and back to 4. I think the original creator of the gif simply swapped the two values by accident.

It also converges after 3 cycles, which is common for this algorithm. In fact, this algorithm can converge after 1 cycle, if the optimal path is (randomly) selected.

I think removing the bold edges, darkening of the vertexes, and stopping the animation after the 3rd frame would really help this page, but I didn't make the change in case I misunderstand the algorithm.

P.S. First comment. Please don't bite the newcomer. I couldn't find a way to comment on the original post so I added to it.

Lothsahn (talk) 21:47, 31 October 2021 (UTC)

Seems that the gif has been updated since then, but I still think it's not correct. On the frame that "t" changes from 6 to 2, shouldn't z change to -2 too instead of happening in the next frame? It suggests that z updates on the next loop after the t update one, but if I'm not mistaken it should be on the same frame since t changes to 2 and then after checking x and y, when it checks for z it should see that t is now -2 and not 6. Atleast that's what I understand should happen after reading the pseudocode. Marco2124 (talk) 20:01, 7 December 2022 (UTC)

New preprint

Seems soon (after peer-review) there finally might be an improvement to this absolutely classical algorithm https://arxiv.org/abs/2311.02520 2A00:20:5:B593:5C8F:D801:68C2:458 (talk) 00:29, 8 November 2023 (UTC)