/*
* Copyright (C) 2012, 2013
* Dale Weiler
- *
+ * Wolfgang Bumiller
+ *
* Permission is hereby granted, free of charge, to any person obtaining a copy of
* this software and associated documentation files (the "Software"), to deal in
* the Software without restriction, including without limitation the rights to
* out of all possible corrections that maximizes the probability of C
* for the original identifer I.
*
- * Bayes' Therom suggests something of the following:
+ * Thankfully there exists some theroies for probalistic interpretations
+ * of data. Since we're operating on two distictive intepretations, the
+ * transposition from I to C. We need something that can express how much
+ * degree of I should rationally change to become C. this is called the
+ * Bayesian interpretation. You can read more about it from here:
+ * http://www.celiagreen.com/charlesmccreery/statistics/bayestutorial.pdf
+ * (which is probably the only good online documentation for bayes theroy
+ * no lie. Everything else just sucks ..)
+ *
+ * Bayes' Thereom suggests something like the following:
* AC P(I|C) P(C) / P(I)
- * Since P(I) is the same for every possibly I, we can ignore it giving
+ *
+ * However since P(I) is the same for every possibility of I, we can
+ * completley ignore it giving just:
* AC P(I|C) P(C)
*
* This greatly helps visualize how the parts of the expression are performed
* enumerates all feasible values of C, to determine the one that
* gives the greatest probability score.
*
- * In reality the requirement for a more complex expression involving
+ * In reality the requirement for a more complex expression involving
* two seperate models is considerably a waste. But one must recognize
* that P(C|I) is already conflating two factors. It's just much simpler
* to seperate the two models and deal with them explicitaly. To properly
*
* Our control mechanisim could use a limit, i.e limit the number of
* sets of edits for distance X. This would also increase execution
- * speed considerably.
+ * speed considerably.
*/
-#define CORRECT_POOLSIZE (128*1024*1024)
+#define CORRECT_POOL_SIZE (128*1024*1024)
/*
* A forward allcator for the corrector. This corrector requires a lot
* of allocations. This forward allocator combats all those allocations
static GMQCC_INLINE void correct_pool_new(void) {
correct_pool_addr = 0;
- correct_pool_this = (unsigned char *)mem_a(CORRECT_POOLSIZE);
+ correct_pool_this = (unsigned char *)mem_a(CORRECT_POOL_SIZE);
vec_push(correct_pool_data, correct_pool_this);
}
static GMQCC_INLINE void *correct_pool_alloc(size_t bytes) {
void *data;
- if (correct_pool_addr + bytes >= CORRECT_POOLSIZE)
+ if (correct_pool_addr + bytes>= CORRECT_POOL_SIZE)
correct_pool_new();
- data = correct_pool_this;
+ data = (void*)correct_pool_this;
correct_pool_this += bytes;
correct_pool_addr += bytes;
-
return data;
}
}
/*
- * A fast space efficent trie for a disctonary of identifiers. This is
+ * A fast space efficent trie for a dictionary of identifiers. This is
* faster than a hashtable for one reason. A hashtable itself may have
* fast constant lookup time, but the hash itself must be very fast. We
* have one of the fastest hash functions for strings, but if you do a
* lost of hashing (which we do, almost 3 million hashes per identifier)
- * a hashtable becomes slow. Very Very Slow.
+ * a hashtable becomes slow.
*/
correct_trie_t* correct_trie_new() {
correct_trie_t *t = (correct_trie_t*)mem_a(sizeof(correct_trie_t));
void* correct_trie_get(const correct_trie_t *t, const char *key) {
const unsigned char *data = (const unsigned char*)key;
+
while (*data) {
- unsigned char ch = *data;
- const size_t vs = vec_size(t->entries);
- size_t i;
const correct_trie_t *entries = t->entries;
+ unsigned char ch = *data;
+ const size_t vs = vec_size(entries);
+ size_t i;
+
for (i = 0; i < vs; ++i) {
if (entries[i].ch == ch) {
t = &entries[i];
void correct_trie_set(correct_trie_t *t, const char *key, void * const value) {
const unsigned char *data = (const unsigned char*)key;
while (*data) {
- const size_t vs = vec_size(t->entries);
- unsigned char ch = *data;
correct_trie_t *entries = t->entries;
+ const size_t vs = vec_size(entries);
+ unsigned char ch = *data;
size_t i;
for (i = 0; i < vs; ++i) {
* Implementation of the corrector algorithm commences. A very efficent
* brute-force attack (thanks to tries and mempool :-)).
*/
-static size_t *correct_find(correct_trie_t *table, const char *word) {
+static GMQCC_INLINE size_t *correct_find(correct_trie_t *table, const char *word) {
return (size_t*)correct_trie_get(table, word);
}
-static int correct_update(correct_trie_t* *table, const char *word) {
+static GMQCC_INLINE bool correct_update(correct_trie_t* *table, const char *word) {
size_t *data = correct_find(*table, word);
if (!data)
- return 0;
+ return false;
(*data)++;
- return 1;
+ return true;
}
void correct_add(correct_trie_t* table, size_t ***size, const char *ident) {
* 2) transposition
* 3) alteration
* 4) insertion
+ *
+ * These functions could take an additional size_t **size paramater
+ * and store back the results of their new length in an array that
+ * is the same as **array for the memcmp in correct_exists. I'm just
+ * not able to figure out how to do that just yet. As my brain is
+ * not in the mood to figure out that logic. This is a reminder to
+ * do it, or for someone else to :-) correct_edit however would also
+ * need to take a size_t ** to carry it along (would all the argument
+ * overhead be worth it?)
*/
static size_t correct_deletion(const char *ident, char **array, size_t index) {
size_t itr = 0;
*/
static int correct_exist(char **array, size_t rows, char *ident) {
size_t itr;
- for (itr = 0; itr < rows; itr++)
+ /*
+ * As an experiment I tried the following assembly for memcmp here:
+ *
+ * correct_cmp_loop:
+ * incl %eax ; eax = LHS
+ * incl %edx ; edx = LRS
+ * cmpl %eax, %ebx ; ebx = &LHS[END_POS]
+ *
+ * jbe correct_cmp_eq
+ * movb (%edx), %cl ; micro-optimized on even atoms :-)
+ * cmpb %cl, (%eax) ; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+ * jg correct_cmp_gt
+ * jge correct_cmp_loop
+ * ...
+ *
+ * Despite how much optimization went in to this, the speed was the
+ * being conflicted by the strlen(ident) used for &LHS[END_POS]
+ * If we could eliminate the strlen with what I suggested on line
+ * 311 ... we can accelerate this whole damn thing quite a bit.
+ *
+ * However there is still something we can do here that does give
+ * us a little more speed. Although one more branch, we know for
+ * sure there is at least one byte to compare, if that one byte
+ * simply isn't the same we can skip the full check. Which means
+ * we skip a whole strlen call.
+ */
+ for (itr = 0; itr < rows; itr++) {
if (!memcmp(array[itr], ident, strlen(ident)))
return 1;
+ }
return 0;
}
static GMQCC_INLINE char **correct_known_resize(char **res, size_t *allocated, size_t size) {
size_t oldallocated = *allocated;
char **out;
- if (size+1 < *allocated)
+ if (size+1 < oldallocated)
return res;
- *allocated += 32;
- out = correct_pool_alloc(sizeof(*res) * *allocated);
+ out = correct_pool_alloc(sizeof(*res) * oldallocated + 32);
memcpy(out, res, sizeof(*res) * oldallocated);
+
+ *allocated += 32;
return out;
}
end = correct_edit(array[itr]);
row = correct_size(array[itr]);
- for (; jtr < row; jtr++) {
+ /* removing jtr=0 here speeds it up by 100ms O_o */
+ for (jtr = 0; jtr < row; jtr++) {
if (correct_find(table, end[jtr]) && !correct_exist(res, len, end[jtr])) {
res = correct_known_resize(res, &nxt, len+1);
res[len++] = end[jtr];
projects / xonotic / gmqcc.git / blobdiff