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

Stale tape detection implementation #55

Merged
merged 2 commits into from
Feb 12, 2019
Merged

Stale tape detection implementation #55

merged 2 commits into from
Feb 12, 2019

Conversation

Necried
Copy link
Collaborator

@Necried Necried commented Feb 12, 2019

This is an implementation for issue #26. While I think the view portion of this code is satisfactory, I did not follow the recommendation mentioned in the issue.

I will expound on the implementation here (this can be copypasted into the issue thread too):

  • We still maintain the Array Character representation of tapes. Now consider the two operations
    on individual tapes, Add a character, or Delete a character (from the right):
    1. We do not perform a check on adding. The assumption is that users can only add characters
      defined in the Sigma of the machine. Constant time!
    2. However, when delete is called, we perform the check to see if any offending characters still exist.
      For simplicity, we assume a constant cost of conversion between intermediary data structures.
      The algorithm then becomes: For each character in the array, check if there exists its transition
      in Sigma. Construction of Sigma is linear w.r.t the number of transition edges in the machine.
      The runtime for checking one tape is then O(#transitions + length(tape)).
  • We can naively assume that the runtime for checking all tapes (as will happen when onEnter is
    called) will then be O(#tapes *(#transitions + length(tape))).

Storing as CharacterID will save time on checking, but the argument is that #tapes and tape length is small anyway. This part of the code should then be under consideration when we look to optimize.

Copy link
Owner

@CSchank CSchank left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree we should consider optimizations if they make sense in the future, but given that this is user-defined data, it would be hard for them to define a large enough input to the point where it would make an appreciable difference. Thank you!

@CSchank CSchank merged commit 8058f5f into master Feb 12, 2019
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