Skip to content

Rolling Windows #9

Description

@jdamerow

Requester: Scott Kleinman
GitHub repo: https://github.com/scottkleinman/rollingwindows
Programming Language: Python
Authors and contributors:
The main developer for both the Lexos API and the rollingwindows module is Scott Kleinman. The work is based on the Lexos web app (https://github.com/wheatonCS/Lexos/), developed by a large team of developers over a number of years (with Scott Kleinman as one of the project leaders).
Field:
The code was developed for use in literary or similar text analysis with small to medium-sized corpora. The Lexos API is an attempt to create a flexible programming interface that can be used for scripting, in notebooks, or for further development of the Lexos web app. Part the intent is also to go beyond raw text analysis by enabling the use of language models and NLP tools.

Supporting papers:
The use of rolling windows is described in Michael D.C. Drout and Elie Chauvet (2015). “Tracking the Moving Ratio of þ to ð in Anglo-Saxon Texts: A New Method, and Evidence for a lost Old English version of the ‘Song of the Three Youths.’” Anglia 133.2: 278-319 (https://www.degruyter.com/document/doi/10.1515/ang-2015-0024/html).

Standards/Required Domain Knowledge:
No domain knowledge is required to experiment with the code, but some familiarity with spaCy (https://spacy.io/) is helpful. For further notes, see https://github.com/scottkleinman/rollingwindows/blob/main/notes_for_DHTech_code_review.md.

Requirements:
The code requires Python 3.9 or greater, the lexos Python package, and a few other installed dependencies noted at https://github.com/scottkleinman/rollingwindows/blob/main/notes_for_DHTech_code_review.md.

Anything else:
"The code for rollingwindows was developed over the course of 2023, and then much of it was lost due to an unexplained corruption of my Python environment before I could push the code to GitHub. As a result, much of the code had to be reconstructed. As a result, there is still a certain amount of legacy code in the module, and function and variable names may not be as clean or informative as desired. Unit tests are also a bit messy, although the coverage is pretty good.

At present, I need some outside perspective on the following topics:

  • Overall usability of the code
  • How it might be streamlined
  • Whether there are any broken functions or if the code fails any stress tests
  • How the processing speed of the Averages calculator could be improved (whilst keeping a fairly consistent API).
  • Whether there are additional features that users of the module might find useful."

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions