Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generalized weight-aggregation functions instead of only + #79

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

alexandergunnarson
Copy link

Made some simple changes to use a function waf, short for weight-aggregation function. Defaults to +, as the affected graph functions previously implicitly used.

Affected functions include dijkstra-traverse, dijkstra-span,bellman-ford-transform, and johnson.

The reason for this commit is that weights won't always be simply added: they might be multiplied, subtracted, or divided. Suppose one were to perform unit conversion, for instance, where to get from one unit to another one would multiply by a constant (or equivalently, divides by the inverse of the constant). To aggregate the conversions needed from seconds to nanoseconds using all-pairs-shortest-paths, one would need to not add 1/1000 to get to milliseconds, then another 1/1000 to get to microseconds, then another to get to nanoseconds, but rather to multiply them, resulting in a conversion factor of 1/1,000,000,000. There are certainly examples when weight-aggregation functions might be more complex than simply * or +, but I will not touch on them here.

Made some simple changes to use a function `waf`, short for
`weight-aggregation function`. Defaults to `+`, as the affected graph
functions previously implicitly used.

Affected functions include `dijkstra-traverse`, `dijkstra-span`,
`bellman-ford-transform`, and `johnson`.

The reason for this commit is that weights won't always be simply added
- they might be multiplied, subtracted, or divided. Suppose one were to
perform unit conversion, for instance, where to get from one unit to
another one would multiply by a constant (or equivalently, divides by
the inverse of the constant). To aggregate the conversions needed from
seconds to nanoseconds using `all-pairs-shortest-paths`, one would need
to not *add* 1/1000 to get to milliseconds, then another 1/1000 to get
to microseconds, then another to get to nanoseconds, but rather to
*multiply* them. There are certainly examples when weight-aggregation
functions might be more complex than simply `*` or `+`, but I will not
touch on them here.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant