Skip to content

Mention computing Dragon Curve parity in constant time#42

Merged
maneatingape merged 1 commit intomaneatingape:mainfrom
ebblake:2016-16
Feb 16, 2026
Merged

Mention computing Dragon Curve parity in constant time#42
maneatingape merged 1 commit intomaneatingape:mainfrom
ebblake:2016-16

Conversation

@ebblake
Copy link
Contributor

@ebblake ebblake commented Feb 16, 2026

Description

The existing O(log n) solution solves in under 1µs, so there is not
really much to be shaved by swapping to an O(1) computation per bit.
But it is still a fun read, so worth documenting for anyone else using
this repository as a reference point.

It is also worth adding a unit test of the example given in part 1.

Type of change

  • Performance improvement
  • Bug fix
  • Other (docs, unit test)

Checklist

  • Pull request title and commit messages are clear and informative.
  • Documentation has been updated if necessary.
  • Code style matches the existing code. This one is somewhat subjective, but try to "fit in" by
    using the same naming conventions. Code should be portable, avoiding any architecture
    specific intrinsics.
  • Tests pass cargo test
  • Code is formatted cargo fmt -- `find . -name "*.rs"`
  • Code is linted cargo clippy --all-targets --all-features

Formatting and linting also can be executed by running just
(if installed) on the command line at the project root.

@ebblake ebblake force-pushed the 2016-16 branch 3 times, most recently from 075aa41 to 5a4ea53 Compare February 16, 2026 02:30
@ebblake
Copy link
Contributor Author

ebblake commented Feb 16, 2026

https://www.reddit.com/r/adventofcode/comments/1r642oc/2016_day_16_in_review_dragon_checksum/ mentions OEIS A255070 as a source for a similar derivation of O(1) Dragon parity

@maneatingape
Copy link
Owner

The existing nlog(n) solution is already under 1µs so my preference is to keep it, as it's easily explainable and understandable.

However askalskis post is an interesting read (especially I have no idea why it works, only that it does work. 😀 )
so how about we take the same approach as 2021 Day 19 and reduce this PR to a short comment linking to the post.

The existing O(log n) solution solves in under 1µs, so there is not
really much to be shaved by swapping to an O(1) computation per bit.
But it is still a fun read, so worth documenting for anyone else using
this repository as a reference point.

It is also worth adding a unit test of the example given in part 1.
@ebblake
Copy link
Contributor Author

ebblake commented Feb 16, 2026

The existing nlog(n) solution is already under 1µs so my preference is to keep it, as it's easily explainable and understandable.

Fair enough.

However askalskis post is an interesting read (especially I have no idea why it works, only that it does work. 😀 ) so how about we take the same approach as 2021 Day 19 and reduce this PR to a short comment linking to the post.

Patch revised in place. I did, however, salvage the unit test addition out of my bigger patch.

@ebblake ebblake changed the title Compute Dragon Curve parity in constant time Mention computing Dragon Curve parity in constant time Feb 16, 2026
@maneatingape
Copy link
Owner

Thanks for adding the test!

@maneatingape maneatingape merged commit a0cc05f into maneatingape:main Feb 16, 2026
3 checks passed
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.

2 participants