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

Don't assume stored children #53

Open
goretkin opened this issue May 19, 2020 · 4 comments
Open

Don't assume stored children #53

goretkin opened this issue May 19, 2020 · 4 comments

Comments

@goretkin
Copy link

There's a trait for ParentLinks and SiblingLinks, it would be great if there was a ChildrenLinks trait too. Of course, a tree needs at least one of {link to children, link to parent}.

@Keno
Copy link
Collaborator

Keno commented Aug 20, 2021

I think this is potentially reasonable, but a lot of the appeal of this package is the printing (and a very distant second the tree traversal code), neither of which you can do without being able to retrieve children. Do you have a particular usecase in mind?

@goretkin
Copy link
Author

Backtracking pointers in dynamic programming, e.g. storing the prev vertex is the use case I have in mind.

@Keno
Copy link
Collaborator

Keno commented Aug 20, 2021

How would that application benefit from generic code written with other kinds of trees in mind? I guess I'm trying to figure out if those kinds of trees really fit in.

@goretkin
Copy link
Author

I don't have a good answer to that question unfortunately. I think it had struck me as a natural generalization, however I see your point.

An iterator from node to root (which I believe this package does not provide yet) would work on trees without children links.

There could also be functions to convert between representations.

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

No branches or pull requests

2 participants