eihli
/
darklimericks
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
main
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '5dbc532506'
${ noResults }
darklimericks/web/README_WGU.org

38 KiB
Raw Blame History Unescape Escape

RhymeStorm™ - WGU CSCI Capstone Project

WGU Evaluator Notes

Hello! I hope you enjoy your time with this evaluation!

Here's a quick introduction to help you navigate this project.

The document you are reading now contains or points to each of the requirements listed at the course task overview page for C964.

The section immediately following this contains notes on how to view and run the software locally. In addition, I'm hosting a demo of the application at https://darklimericks.com/wgu.

After I describe the steps to initialize a development environment, you'll find a Letter Of Transmittal, Technical Executive Summary, links to the final product and details of how it meets each requirement, and the remaining required documentation.

Evaluation Technical Documentation

It's probably not necessary for you to replicate my development environment in order to evaluate this project. You can access the deployed application at https://darklimericks.com/wgu and the libraries and supporting code that I wrote for this project at https://github.com/eihli/clj-tightly-packed-trie, https://github.com/eihli/syllabify, and https://github.com/eihli/prhyme. The web server and web application is not hosted publicly but you will find it uploaded with my submission as a .tar archive.

How To Initialize Development Environment

Required Software

Steps

  1. Run ./db/run.sh && ./kv/run.sh to start the docker containers for the database and key-value store.

    1. The run.sh scripts only need to run once. They initialize development data containers. Subsequent development can continue with docker start db && docker start kv.
  2. Start a Clojure REPL in Emacs, evaluate the dev/user.clj namespace, and run (init)
  3. Run npx shadow-cljs watch :frontend in the web/wgu-app directory to build the web interface.

How To Run Software Locally

Requirements

Steps

  1. Run ./db/run.sh && ./kv/run.sh to start the docker containers for the database and key-value store.

    1. The run.sh scripts only need to run once. They initialize development data containers. Subsequent development can continue with docker start db && docker start kv.
  2. The application's jar builds with a make run from the root directory. (See Makefile).
  3. Navigate to the root directory of this git repo and run java -jar darklimericks-dev.jar
  4. Visit http://localhost:8000/wgu

A. Letter Of Transmittal

Problem Summary

Songwriters, artists, and record labels can save time and discover better lyrics with the help of a machine learning tool that supports their creative endeavours.

Songwriters have several old-fashioned tools at their disposal including dictionaries and thesauruses. But machine learning exposes a new set of powerful possibilities. Using simple machine learning techniques, it is possible to automatically generate vast numbers of lyrics that match specified criteria for rhyming, syllable count, genre, and more.

Benefits

How many sensible phrases can you think of that rhyme with "war on poverty"? What if I say that there's a restriction to only come up with phrases that are exactly 14 syllables? That's a common restriction when a songwriter is trying to match the meter of a previous line. What if I add another restriction that there must be primary stress at certain spots in that 14 syllable phrase?

This is the process that songwriters go through all day. It's a process that gets little help from traditional tools like dictionaries and thesauruses.

And this is a process that is perfect for machine learning. Machine learning can learn the most likely grammatical structure of phrases and can make predictions about likely words that follow a given sequence of other words. Computers can iterate through millions of words, checking for restrictions on rhyme, syllable count, and more. The most tedious part of lyric generation can be automated with machine learning software, leaving the songwriter free to cherry-pick from the best lyrics and make minor touch-ups to make them perfect.

Product - RhymeStorm™

RhymeStorm™ is a tool to help songwriters brainstorm. It provides lyrics automatically generated based on training data from existing songs while adhering to restrictions based on rhyme scheme, meter, genre, and more.

The machine learning part of software that I described above can be implemented with a simple machine learning technique known as a Hidden Markov Model.

Without getting too technical, using a Hidden Markov Model will involve using an existing lyrics database as input and the output will be a function that returns the likelihood of a word following a sequence of previous words.

A choice of many different programming languages and algorithms are sufficient to handle the other parts of the product, like splitting a word into phonetic sounds, finding rhymes, and matching stress between phrases.

An initial version of the software will be trained on the heavy metal lyrics database at http://darklyrics.com and a website will be created where users can type in a "seed" sequence of word(s) and the model will output a variety of possible completions.

This auto-complete functionality will be similar to the auto-complete that is commonly found on phone keyboard applications that help users type faster on phone touchscreens.

Data

The initial model will be trained on the lyrics from http://darklyrics.com. This is a publicly available data set with minimal meta-data. Record labels will have more valuable datasets that will include meta-data along with lyrics, such as the date the song was popular, the number of radio plays of the song, the profit of the song/artist, etc…

The software can be augmented with additional algorithms to account for the type of meta-data that a record label may have. The augmentations can happen in iterative software development cycles, using Agile methodologies.

Objectives

This software will accomplish its primary objective if it makes its way into the daily toolkit of a handful of singers/songwriters.

Several secondary objectives are also desirable and reasonably expected. The architecture of the software lends itself to existing as several independently useful modules.

For example, the Markov Model can be conveniently backed by a Trie data structure. This Trie data structure can be released as its own software package and used any application that benefits from prefix matching.

Another example is the package that turns phrases into phones. That package can find use for a number of natural language processing and natural language generation tasks, aside from the task required by this particular project.

Development Methodology - Agile

This project will be developed with an iterative Agile methodology. Since a large part of data science and machine learning is exploration, this project will benefit from ongoing exploration in tandem with development.

Additionally, the developer(s) working on the project won't have (and won't need to have) access to the data sets that songwriters and record labels may have. Work can begin immediately with an iterative approach and future data sets can be integrated as they become available.

The prices quoted below are for an initial minimum-viable-product that will serve as a proof-of-concept. Future contracts can be negotiated for ongoing development at similar rates.

Costs

Funding requirements are minimal. The initial dataset is public and freely available. On a typical consumer laptop, Hidden Markov Models can be trained on fairly large datasets in short time and the training doesn't require the use of expensive hardware like the GPUs used to train Deep Neural Networks.

For the initial product, the only development expensive would be the hourly rate of a full-stack developer. The ongoing expensive for the website hosting the user interface would be roughly $20 to $200 per month depending on how many users access the site at the same time.

These are my estimates for the time and cost of different aspects of initial development.

Task Hours Cost
Trie 60 $600
Phonetics 30 $300
HMM Training Algorithms 60 $600
Web User Interface 80 $800
Web Server 60 $600
Testing 20 $200
Quality Assurance 20 $200
Total 330 $3,300

NO the impact of the solution on stakeholders

This seems redundant or irrelevant. The only stakeholders in the project I'm describing would be the record labels or songwriters and the impact on them is described in the /eihli/darklimericks/src/commit/5dbc5325065edb0a026a5806188497b8d68b13f6/web/Benefits section above.

Ethical And Legal Considerations

Web scraping, the method used to obtain the initial dataset from http://darklyrics.com, is protected given the ruling in https://en.wikipedia.org/wiki/HiQ_Labs_v._LinkedIn.

The use of publicly available data in generative works is less clear. But Microsoft's lawyers deemed it sound given their recent release of Github CoPilot (https://www.theverge.com/2021/7/7/22561180/github-copilot-legal-copyright-fair-use-public-code).

Expertise

I have 10 years experience as a programmer and have worked extensively on both frontend technologies like HTML/JavaScript, backend technologies like Django, and building libraries/packages/frameworks.

I've also been writing limericks my entire life and hold the International Limerick Imaginative Enthusiast's ILIE award for the years 2013 and 2019.

B. Executive Summary - RhymeStorm™ Technical Notes And Requirements

Write an executive summary directed to IT professionals that addresses each of the following requirements:

Decision Support Opportunity

Songwriters expend a lot of time and effort finding the perfect rhyming word or phrase. RhymeStorm™ is going to amplify user's creative abilities by searching its machine learning model for sensible and proven-successful words and phrases that meet the rhyme scheme and meter requirements requested by the user.

When a songwriter needs to find likely phrases that rhyme with "war on poverty" and has 14 syllables, RhymeStorm™ will automatically generate dozens of possibilities and rank them by "perplexity" and rhyme quality. The songwriter can focus there efforts on simple touch-ups to perfect the automatically generated lyrics.

Customer Needs And Product Description

Songwriters spend money on dictionaries, compilations of slang, thesauruses, and phrase dictionaries. They spend their time daydreaming, brainstorming, contemplating, and mixing and matching the knowledge they acquire through these traditional means.

A simple experiment you can try yourself will show that it takes between 5 and 30 seconds to look up a word in a dictionary or thesaurus. Then it takes an equal amount of time to look up each synonym, antonym, or other word that comes to mind. A few of those words may rhyme, but each word requires building an entire sentence around it that meets restrictions for sensibility, meter, and scheme.

This process can take a person hours for a single line and weeks for a single song.

Computers can process and sort this information and sort the results by quality millions of times faster. A few minutes of a songwriter specifying filters, restrictions, and requirements can save them days of traditional brainstorming.

Existing Products

We're all familiar with dictionaries, thesauruses, and their shortcomings.

There is a small amount of technology being applied to this problem. A popular site to find rhymes is https://www.rhymezone.com.

RhymeZone is limited in its capability. It doesn't do well finding rhymes for phrases more than a couple of words and it can't generate suggestions for lyric completions.

Available Data And Future Data Lifecycle

The initial dataset will be gathered by downloading lyrics from http://darklyrics.com and future models can be generated by downloading lyrics from other websites. Alternatively, data can be provided by record labels and combined with meta-data that the record label may have, such as how many radio plays each song gets and how much profit they make from each song.

RhymeStorm™ can offer multiple models depending on the genre or theme that the songwriter is looking for. With the initial dataset from http://darklyrics.com, all suggestions will have a heavy metal theme. But future data sets can be trained on rap, pop, or other genres.

Songs don't get released fast enough that training needs to be an automated ongoing process. Perhaps once a year, or whenever a new dataset becomes available, someone can run a script that will update the data models.

The script to generate data models will accept as arguments a directory containing files of songs, a filepath to save the completed model, the "rank" of the Hidden Markov Model, and it will generate a Trie representing the HMM and save it to disk at the specified location.

Each new model can be uploaded to the web server and users can select which model they want to use.

Methodology - Agile

RhymeStorm™ development will proceed with an iterative Agile methodology. It will be composed of several independent modules that can be worked on independently, in parallel, and iteratively.

The Trie data structure that will be used as a backing to the Hidden Markov Model can be worked on in isolation from any other aspect of the project. The first iteration can use a simple hash-map as a backing store. The second iteration can improve memory efficiency by using a ByteBuffer as a Tightly Packed Trie. Future iterations can continue to improve performance metrics.

The web server can be implemented initially without security measures like HTTPS and performance measures like load balancing. Future iterations can add these features as they become necessary.

The user interface can be implemented as a wireframe and extended as new functionality becomes available from the backend.

Much of data science is exploratory and taking an iterative Agile approach can take advantage of delaying decisions while information is gathered.

Deliverables

Three aspects of this project are available as open source repositories on Github.

Tightly Packed Trie

Phonetics and Syllabification

Data Processing, Markov, and Rhyme Algorithms

The trained data model and web interface has been deployed at the following address and the code will be provided in an archive file.

Web GUI and Documentation

Implementation Plan And Anticipations

the plan for implementation of your data product, including the anticipated outcomes from this development

I'll start by writing and releasing the supporting libraries and packages: Tries, Syllabification/Phonetics, Rhyming.

Then I'll write a website that imports and uses those libraries.

Since I'll be writing and releasing these packages iteratively as open source, I'll share them publicly as I progress and can use feedback to improve them before RhymeStorm™ takes its final form.

In anticipation of user growth, I'll be deploying the final product on DigitalOcean Droplets. They are virtual machines with resources that can be resized to meet growing demands or shrunk to save money in times of low traffic.

Requirements Validation And Verification

the methods for validating and verifying that the developed data product meets the requirements and subsequently the needs of the customers

For the known requirements, I'll perform personally perform manual tests and quality assurance. This is a small enough project that one individual can thoroughly test all of the primary requirements.

Since the project is broken down into isolated sub-projects, unit tests will be added to the sub-projects to make sure they meet their own goals and performance standards.

The final website will integrate multiple technologies and the integrations won't be ideal for unit testing. But as mentioned, the user acceptance requirements are not major and can be manually ensured.

Programming Environments And Costs

the programming environments and any related costs, as well as the human resources that are necessary to execute each phase in the development of the data product

One of the benefits of a Hidden Markov Model is its relative computational affordability when compared to other machine learning techniques, like Deep Neural Networks.

We don't require a GPU or long training times on powerful computers. The over 200,000 songs obtained from http://darklyrics.com can be trained into a 4-gram Hidden Markov Model in just a few hours on a consumer laptop.

The training process never uses more than 20 gigabytes of ram.

All code was written and all models were trained on a Lenovo T15G with an Intel i9 2.4 ghz processor and 32gb of RAM.

Timeline And Milestones

Sprint Start End Tasks
1 2021-07-01 2021-07-07 Acquire corpus - Explore Modelling - Review Existing Material
2 2021-07-07 2021-07-21 Data Cleanup - Feature Extraction - Lyric Generation (POC)
3 2021-07-21 2021-07-28 Lyric Generation Restrictions (Syllable-count, Rhyme, Etc…)
4 2021-07-28 2021-08-14 Train Full-scale Model - Performance Tuning
5 2021-08-14 2021-08-21 Create Web Interface And Visualizations
6 2021-08-21 2021-09-07 QA - Testing - Deploy And Release Web App

C. RhymeStormg™ Capstone Requirements Documentation

RhymeStorm™ is an application to help singers and songwriters brainstorm new lyrics.

Descriptive And Predictive Methods

Descriptive Method

Most Common Grammatical Structures In A Set Of Lyrics

By filtering songs by metrics such as popularity, number of awards, etc… we can use this software package to determine the most common grammatical phrase structure for different filtered categories.

Since much of the data a record label might want to categorize songs by is likely proprietary, filtering the songs by whatever metric is the responsibility of the user.

Once the songs are filtered/categorized, they can be passed to this software where a list of the most popular grammar structures will be returned.

In the example below, you'll see that a simple noun-phrase is the most popular structure with 6 occurrences, tied with a sentence composed of a prepositional-phrase, verb-phrase, and adjective.

(require '[com.owoga.corpus.markov :as markov]
         '[com.owoga.prhyme.nlp.core :as nlp]
         '[clojure.string :as string]
         '[clojure.java.io :as io])

(let [lines (transduce
             (comp
              (map slurp)
              (map #(string/split % #"\n"))
              (map (partial remove empty?))
              (map nlp/structure-freqs))
             merge
             {}
             (eduction (markov/xf-file-seq 0 10) (file-seq (io/file "/home/eihli/src/prhyme/dark-corpus"))))]
  (take 5 (sort-by (comp - second) lines)))
(TOP (NP (NNP) (.))) 6
(TOP (S (NP (PRP)) (VP (VBP) (ADJP (JJ))) (.))) 6
(INC (NP (JJ) (NN)) nil (IN) (NP (DT)) (NP (PRP)) (VBP)) 4
(TOP (NP (NP (JJ) (NN)) nil (NP (NN) (CC) (NN)))) 4
(TOP (S (NP (JJ) (NN)) nil (VP (VBG) (ADJP (JJ))))) 4

Prescriptive Method

Most Likely Word To Follow A Given Phrase

To help songwriters think of new lyrics, we provide an API to receive a list of words that commonly follow/precede a given phrase.

Models can be trained on different genres or categories of songs. This will ensure that recommended lyric completions are apt.

In the example below, we provide a seed suffix of "bother me" and ask the software to predict the most likely words that precede that phrase. The resulting most popular phrases are "don't bother me", "doesn't bother me", "to bother me", "won't bother me", etc…

(require '[com.darklimericks.server.models :as models]
         '[com.owoga.trie :as trie])

(let [seed ["bother" "me"]
      seed-ids (map models/database seed)
      lookup (reverse seed-ids)
      results (trie/children (trie/lookup models/markov-trie lookup))]
  (->> results
       (map #(get % []))
       (sort-by (comp - second))
       (map #(update % 0 models/database))
       (take 10)))
don't 36
doesn't 21
to 14
won't 9
really 5
not 4
you 4
it 3
even 3
shouldn't 3

Datasets

The dataset currently in use was generated from the publicly available lyrics at http://darklyrics.com.

Further datasets will need to be provided by the end-user.

Decision Support Functionality

Choosing Words For A Lyric Based On Markov Likelihood

Entire phrases can be generated using the previously mentioned functionality of generating lists of likely prefix/suffix words.

The software can be seeded with a simple "end-of-sentence" or "beginning-of-sentence" token and can be asked to work backwards to build a phrase that meets certain criteria.

The user can supply criteria such as restrictions on the number of syllables, number of words, rhyme scheme, etc…

Choosing Words To Complete A Lyric Based On Rhyme Quality

Another part of the decision support functionality is filtering and ordering predicted words based on their rhyme quality.

The official definition of a "perfect" rhyme is when two words have matching phonemes starting from their primary stress.

For example: technology and ecology. Both of those words have a stress on the second syllable. The first syllables differ. But from the stressed syllable on, they have exactly matching phones.

A rhyme that might be useful to a songwriter but that doesn't fit the definition of a "perfect" rhyme would be "technology" and "economy". Those two words just barely break the rules for a perfect rhyme. Their vowel phones match from their primary stress to their ends. But one of the consonant phones doesn't match.

Singers and songwriters have some flexibility and artistic freedom and imperfect rhymes can be a fallback.

Therefore, this software provides functionality to sort rhymes so that rhymes that are closer to perfect are first in the ordering.

In the example below, you'll see that the first 20 or so rhymes are perfect, but then "hypocrisy" is listed as rhyming with "technology". This is for the reason just mentioned. It's close to a perfect rhyme and it's of interest to singers/songwriters.

(require '[com.darklimericks.linguistics.core :as linguistics]
         '[com.darklimericks.server.models :as models])

(let [results
      (linguistics/rhymes-with-frequencies-and-rhyme-quality
       "technology"
       models/markov-trie
       models/database)]
  (->> results
       (map
        (fn [[rhyming-word
              rhyming-word-phones
              frequency-count-of-rhyming-word
              target-word
              target-word-phones
              rhyme-quality]]
          [rhyming-word frequency-count-of-rhyming-word rhyme-quality]))
       (take 25)
       (vec)
       (into [["rhyme" "frequency count" "rhyme quality"]])))
rhyme frequency count rhyme quality
technology 318 8
apology 68 7
pathology 42 7
mythology 27 7
psychology 24 7
theology 23 7
biology 20 7
ecology 11 7
chronology 10 7
astrology 9 7
biotechnology 8 7
nanotechnology 5 7
geology 3 7
ontology 2 7
morphology 2 7
seismology 1 7
urology 1 7
doxology 0 7
neurology 0 7
hypocrisy 723 6
democracy 238 6
atrocity 224 6
philosophy 181 6
equality 109 6
ideology 105 6

Featurizing, Parsing, Cleaning, And Wrangling Data

The data processing code is in https://github.com/eihli/prhyme

Each line gets tokenized using a regular expression to split the string into tokens.

(def re-word
  "Regex for tokenizing a string into words
  (including contractions and hyphenations),
  commas, periods, and newlines."
  #"(?s).*?([a-zA-Z\d]+(?:['\-]?[a-zA-Z]+)?|,|\.|\?|\n)")

Along with tokenization, the lines get stripped of whitespace and converted to lowercase. This conversion is done so that words can be compared: "Foo" is the same as "foo".

(def xf-tokenize
  (comp
   (map string/trim)
   (map (partial re-seq re-word))
   (map (partial map second))
   (map (partial mapv string/lower-case))))

Data Exploration And Preparation

The primary data structure and algorithms supporting exploration of the data are a Markov Trie

The Trie data structure supports a lookup function that returns the child trie at a certain lookup key and a children function that returns all of the immediate children of a particular Trie.

All Trie code is hosted in the git repo located at https://github.com/eihli/clj-tightly-packed-trie.

(defprotocol ITrie
  (children [self] "Immediate children of a node.")
  (lookup [self ^clojure.lang.PersistentList ks] "Return node at key."))

(deftype Trie [key value ^clojure.lang.PersistentTreeMap children-]
  ITrie
  (children [trie]
    (map
     (fn [[k ^Trie child]]
       (Trie. k
              (.value child)
              (.children- child)))
     children-))

  (lookup [trie k]
    (loop [k k
           trie trie]
      (cond
        ;; Allows `update` to work the same as with maps... can use `fnil`.
        ;; (nil? trie') (throw (Exception. (format "Key not found: %s" k)))
        (nil? trie) nil
        (empty? k)
        (Trie. (.key trie)
               (.value trie)
               (.children- trie))
        :else (recur
               (rest k)
               (get (.children- trie) (first k))))))

TODO Data Visualization Functionalities For Data Exploration And Inspection

  • graph of phrase complexity on one axis and rhyme quality on another axis.

TODO Implementation Of Interactive Queries

Interactive query capability at https://darklimericks.com/wgu.

Implementation Of Machine Learning Methods

The machine learning method chosen for this software is a Hidden Markov Model.

Each line of each song is split into "tokens" (words) and then the previous n - 1 tokens are used to predict the nth token.

The algorithm is implemented in several parts which are demonstrated below.

  1. Read each song line-by-line.
  2. Split each line into tokens.
  3. Partition the tokens into sequences of length n.
  4. Associate each sequence into a Trie and update the value representing the number of times that sequence has been encountered.

That is the process for building the Hidden Markov Model.

The algorithm for generating predictions from the HMM is as follows.

  1. Look up the n - 1 tokens in the Trie.
  2. Normalize the frequencies of the children of the n - 1 tokens into percentage likelihoods.
  3. Account for "unseen n grams" (Simple Good Turing).
  4. Sort results by maximum likelihood.
(require '[com.owoga.prhyme.data-transform :as data-transform]
         '[clojure.pprint :as pprint])

(defn file-seq->markov-trie
  "For forwards markov."
  [database files n m]
  (transduce
   (comp
    (map slurp)
    (map #(string/split % #"[\n+\?\.]"))
    (map (partial transduce data-transform/xf-tokenize conj))
    (map (partial transduce data-transform/xf-filter-english conj))
    (map (partial remove empty?))
    (map (partial into [] (data-transform/xf-pad-tokens (dec m) "<s>" 1 "</s>")))
    (map (partial mapcat (partial data-transform/n-to-m-partitions n (inc m))))
    (mapcat (partial mapv (data-transform/make-database-processor database))))
   (completing
    (fn [trie lookup]
      (update trie lookup (fnil #(update % 1 inc) [lookup 0]))))
   (trie/make-trie)
   files))

(let [files (->> "/home/eihli/src/prhyme/dark-corpus"
                 io/file
                 file-seq
                 (eduction (data-transform/xf-file-seq 501 2)))
      database (atom {:next-id 1})
      trie (file-seq->markov-trie database files 1 3)]

 (pprint/pprint [(map (comp (partial map @database) first) (take 10 (drop 105 trie)))]))
[(("<s>" "call" "me")
  ("<s>" "call")
  ("<s>" "right" "</s>")
  ("<s>" "right")
  ("<s>" "that's" "proportional")
  ("<s>" "that's")
  ("<s>" "don't" "</s>")
  ("<s>" "don't")
  ("<s>" "yourself" "in")
  ("<s>" "yourself"))]

The results above show a sample of 10 elements in a 1-to-3-gram trie

The code sample below demonstrates training a Hidden Markov Model on a set of lyrics where each line gets reversed. This model is useful for predicting words backwards, so that you can start with the rhyming end of a word or phrase and generate backwards to the start of the lyric.

It also performs compaction and serialization. Song lyrics are typically provided as text files. Reading files on a hard drive is an expensive process, but we can perform that expensive training process only once and save the resulting Markov Model in a more memory-efficient format.

(require '[com.owoga.corpus.markov :as markov]
         '[taoensso.nippy :as nippy]
         '[com.owoga.prhyme.data-transform :as data-transform]
         '[clojure.pprint :as pprint]
         '[clojure.string :as string]
         '[com.owoga.trie :as trie]
         '[com.owoga.tightly-packed-trie :as tpt])

(defn train-backwards
  "For building lines backwards so they can be seeded with a target rhyme."
  [files n m trie-filepath database-filepath tightly-packed-trie-filepath]
  (let [database (atom {:next-id 1})
        trie (markov/file-seq->backwards-markov-trie database files n m)]
    (nippy/freeze-to-file trie-filepath (seq trie))
    (println "Froze" trie-filepath)
    (nippy/freeze-to-file database-filepath @database)
    (println "Froze" database-filepath)
    (markov/save-tightly-packed-trie trie database tightly-packed-trie-filepath)
    (let [loaded-trie (->> trie-filepath
                           nippy/thaw-from-file
                           (into (trie/make-trie)))
          loaded-db (->> database-filepath
                         nippy/thaw-from-file)
          loaded-tightly-packed-trie (tpt/load-tightly-packed-trie-from-file
                                      tightly-packed-trie-filepath
                                      (markov/decode-fn loaded-db))]
      (println "Loaded trie:" (take 5 loaded-trie))
      (println "Loaded database:" (take 5 loaded-db))
      (println "Loaded tightly-packed-trie:" (take 5 loaded-tightly-packed-trie))
      (println "Successfully loaded trie and database."))))

(let [files (->> "/home/eihli/src/prhyme/dark-corpus"
                 io/file
                 file-seq
                 (eduction (data-transform/xf-file-seq 0 4)))
      [trie database] (train-backwards
                       files
                       1
                       5
                       "/tmp/markov-trie-4-gram-backwards.bin"
                       "/tmp/markov-database-4-gram-backwards.bin"
                       "/tmp/markov-tightly-packed-trie-4-gram-backwards.bin")])

(def markov-trie (into (trie/make-trie) (nippy/thaw-from-file "/tmp/markov-trie-4-gram-backwards.bin")))
(def database (nippy/thaw-from-file "/tmp/markov-database-4-gram-backwards.bin"))
(def markov-tight-trie
  (tpt/load-tightly-packed-trie-from-file
   "/tmp/markov-tightly-packed-trie-4-gram-backwards.bin"
   (markov/decode-fn database)))

(println "\n\n Example n-grams frequencies from Hidden Markov Model:\n")
(pprint/pprint
 (->> markov-tight-trie
      (drop 600)
      (take 10)
      (map
       (fn [[ngram-ids [id freq]]]
         [(string/join " " (map database ngram-ids)) freq]))))
Froze /tmp/markov-trie-4-gram-backwards.bin
Froze /tmp/markov-database-4-gram-backwards.bin
Loaded trie: ([(1 1 1 1 2) [2 2]] [(1 1 1 1 11) [11 1]] [(1 1 1 1 14) [14 2]] [(1 1 1 1 17) [17 1]] [(1 1 1 1 22) [22 1]])
Loaded database: ([hole 7] [trash 227] [come 87] [275 overkill] [breaking 205])
Loaded tightly-packed-trie: ([(1 1 1 1 2) [2 2]] [(1 1 1 1 11) [11 1]] [(1 1 1 1 14) [14 2]] [(1 1 1 1 17) [17 1]] [(1 1 1 1 22) [22 1]])
Successfully loaded trie and database.


 Example n-grams frequencies from Hidden Markov Model:

(["</s> behind from attack cowards" 1]
 ["</s> behind from attack" 1]
 ["</s> behind from" 1]
 ["</s> behind" 1]
 ["</s> hate recharging , crushing" 1]
 ["</s> hate recharging ," 1]
 ["</s> hate recharging" 1]
 ["</s> hate" 1]
 ["</s> bills and sins pay" 1]
 ["</s> bills and sins" 1])

Functionalities To Evaluate The Accuracy Of The Data Product

Since creative brainstorming is the goal, "accuracy" is subjective.

We can, however, measure and compare language generation algorithms against how "expected" a phrase is given the training data. This measurement is "perplexity".

(require '[taoensso.nippy :as nippy]
         '[com.owoga.tightly-packed-trie :as tpt]
         '[com.owoga.corpus.markov :as markov])

(def database (nippy/thaw-from-file "/home/eihli/.models/markov-database-4-gram-backwards.bin"))

(def markov-tight-trie
  (tpt/load-tightly-packed-trie-from-file
   "/home/eihli/.models/markov-tightly-packed-trie-4-gram-backwards.bin"
   (markov/decode-fn database)))

(let [likely-phrase ["a" "hole" "</s>" "</s>"]
      less-likely-phrase ["this" "hole" "</s>" "</s>"]
      least-likely-phrase ["that" "hole" "</s>" "</s>"]]
  (run!
   (fn [word]
     (println
      (format
       "\"%s\" has preceeded \"hole\" \"</s>\" \"</s>\" a total of %s times"
       word
       (second (get markov-tight-trie (map database ["</s>" "</s>" "hole" word]))))))
   ["a" "this" "that"])
  (run!
   (fn [word]
     (let [seed ["</s>" "</s>" "hole" word]]
       (println
        (format
         "%s is the perplexity of \"%s\" \"hole\" \"</s>\" \"</s>\""
         (->> seed
              (map database)
              (markov/perplexity 4 markov-tight-trie))
         word))))
   ["a" "this" "that"]))
"a" has preceeded "hole" "</s>" "</s>" a total of 250 times
"this" has preceeded "hole" "</s>" "</s>" a total of 173 times
"that" has preceeded "hole" "</s>" "</s>" a total of 45 times
-12.184088569934774 is the perplexity of "a" "hole" "</s>" "</s>"
-12.552930899563904 is the perplexity of "this" "hole" "</s>" "</s>"
-13.905719644461469 is the perplexity of "that" "hole" "</s>" "</s>"

The results above make intuitive sense. The most common word to preceed "hole" at the end of a sentence is the word "a". There are 250 instances of sentences of "… a hole.". That can be compared to 173 instances of "… this hole." and 45 instances of "… that hole.".

Therefore, "… a hole." is has the lowest "perplexity".

This standardized measure of accuracy can be used to compare different language generation algorithms.

Security Features

Artists/Songwriters place a lot of value in the secrecy of their content. Therefore, all communication with the web-based interface occurs over a secure connection using HTTPS.

Security certificates are generated using Let's Encrypt and an Nginx web server handles the SSL termination.

With this precaution in place, attackers will not be able to snoop the content that songwriters are sending to or receiving from the servers.

TODO Tools To Monitor And Maintain The Product

  • Script to auto-update SSL cert

TODO A User-Friendly, Functional Dashboard That Includes At Least Three Visualization Types

  • oz graph of perplexity/rhyme quality
  • tables (sortable?)

D. Documentation

Create each of the following forms of documentation for the product you have developed:

Business Vision

Provide rhyming lyric suggestions optionally constrained by syllable count.

Requirements

  • Given a word or phrase, suggest rhymes (ranked by quality) (Trie)

  • Given a word or phrase, suggest lyric completion (Hidden Markov Model)

    • Restrict suggestion by syllable count
    • Restrict suggestion by rhyme quality
    • Show graph of suggestions with perplexity on one axis and rhyme quality on the other

Data Sets

See resources/darklyrics-markov.tpt

Data Analysis

See src/com/owoga/darklyrics/core.clj

See https://github.com/eihli/prhyme

Assessment

See visualization of rhyme suggestion in action.

See perplexity?

Visualizations

See visualization of smoothing technique.

See wordcloud

Accuracy

• assessment of the product’s accuracy

Testing

• the results from the data product testing, revisions, and optimization based on the provided plans, including screenshots

Source

• source code and executable file(s)

Quick Start

• a quick start guide summarizing the steps necessary to install and use the product

Notes

http-kit doesn't support https so no need to bother with keystore stuff like you would with jetty. Just proxy from haproxy.