The lujvo making algorithm!
Go to file
ciuak 168dde83af pamphlet 2019-06-15 22:55:53 +02:00
LICENSE Initial commit 2019-06-15 22:21:55 +02:00
README.md pamphlet 2019-06-15 22:55:53 +02:00
go.mod I have no words 2019-06-15 22:28:54 +02:00
jvozba.go I have no words 2019-06-15 22:28:54 +02:00
jvozba_test.go I have no words 2019-06-15 22:28:54 +02:00
lujvo.go I have no words 2019-06-15 22:28:54 +02:00
lujvo_test.go I have no words 2019-06-15 22:28:54 +02:00
main.go no way 2019-06-15 22:30:47 +02:00
zbasu.go I have no words 2019-06-15 22:28:54 +02:00
zbasu_test.go I have no words 2019-06-15 22:28:54 +02:00

README.md

jvozba

An O(n) implementation of the lujvo-making algorithm to save the world.

What's the big deal with O(n), anyway?

All the jvozba I've seen over the years are of exponential complexity (O(c^n), where 1 ≤ c ≤ 4), because the algorithm they implement is basically collecting all possible combinations of rafsi in an array, mapping the array to a score function, and sorting. This means that prefixing an input tanru with just one bloti will quadruple the time and memory it takes for the lujvo to compute. To put this into perspective: in order to find the lujvo for bloti bloti bloti bloti bloti bloti bloti bloti bloti bloti, the algorithm will have to call the score function a million times. Double theinput length and your 32-bit machine will explode. (Or wake up the OOM killer.)

This jvozba, on the other hand, is linear in complexity, which means it can compute even a million-bloti lujvo in about a second. How does it achieve that?, I hear you asking. Simply put, it goes through each tanru unit and finds the best lujvo so far, with a separate tally for tosmabru words for soundness. There's a bunch more performance tweaks in the code I encourage you to perhaps read it.

Usage

main.go should give you an idea of how to use the (extremely simple) basic API. If you want to customise stuff, dig into the code and you should find the right procedures to call.