53 lines
3.7 KiB
Plaintext
53 lines
3.7 KiB
Plaintext
---------------------------- Developer's private notes (language may vary, bo tak czasem wygodniej) -----------------------------
|
|
- repair stop words feature
|
|
- document the code (classes, cfg files) and update tutorial
|
|
IN PROGRESS - concordia search zwraca pozycje tokenów z hash'a. Jak to odnieść do examples w korpusie? Należy przechowywać oryginalne pozycje tokenów w bazie danych concordia-server. Pozycje te będą obliczane przez funkcję generateTokenVector (przy użyciu listy oryginalnych pozycji, która będzie modyfikowana synchronicznie z każdą anonimizacją)
|
|
- wiele pamięci tłumaczeń: można je przechowywać w jednym indeksie, ale trzeba dodać tm_id jako metadane zdania (np. zamiast example length). Przy wyszukiwaniu należy filtrować wyniki, aby pochodziły z odpowiedniej pamięci tłumaczeń.
|
|
- testy zużycia pamięci
|
|
- Prawdopodobnie długość example w markers będzie potrzebna tylko anubisowi (który, jak się okazuje, jest wolny). Pomyśleć, do czego można wykorzystać markery, bo ich idea wydaje się niezła.
|
|
- Multi-threading? (przy concordia search jak najbardziej. Tylko wtedy trzebaby zastosować sortowanie po końcach przedziału przed liczeniem best overlay, co nawiasem mówiąc jest gotowe).
|
|
|
|
|
|
|
|
---------------------------- Archive -----------------------------
|
|
DONE - deal with 0 length patterns
|
|
DONE - repair concordia-console test feature
|
|
DONE - update tests
|
|
DONE - work on word regex pattern (allow for some symbols and digits within the word)
|
|
REJECTED - concordia_search_result nie musi przechowywać całego tokenVector (bo używa go tylko do odczytania size()).
|
|
DONE - implement tokenAnnotations vector as interval tree (not interval tree, but list, which is even better)
|
|
DONE (IT IS GOOD AS IT IS) - mess with gcc performance optimization options (https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html)
|
|
DONE - concordia-server (zastanowić się, czy nie napisać CAT-a oraz nad tym, czy nie oddzielić projektu concordia-server).
|
|
DONE - document the code
|
|
DONE - prepare website (home, downloads, documentation, tutorial, issues, sourceforge page, about author)
|
|
DONE - copyright libdivsufsort i psi-toolkit (in documentation)
|
|
|
|
DONE - puścić 100% search test na jrc
|
|
|
|
REJECTED - zastanowić się nad empty hash examples (rozwiązanie: w ogóle nie szukać fraz o pustym hashu, rzucać wyjątek).
|
|
|
|
DONE - wyłączyć stopWords
|
|
|
|
DONE - Przy concordia searCh dodatkowo obliczany ma być zestaw optymalnego pokrycia patternu. Może siłowo? (jeśli przyjąć max dł. zdania 500 tokenów, to nie powinno być źle)
|
|
|
|
DONE - wyszukiwanie zdania: wyszukanie najdłuższych pasujących fragmentów Anubisem, 1D (approximate) bin packing. Nazwijmy to concordia search. Wyszukiwane są wszystkie najdłuższe dopasowania patternu dzięki LCP search. Zwracany jest wynik w postaci listy najdłuższych dopasowanych fragmentów, posortowanych malejąco po długości, z maksymalnie 3 przedstawicielami każdej długości.
|
|
|
|
DONE 1. lokalizowane to_lower (wykorzystać utf8case, naprawić testy)
|
|
DONE 2. anonimizacja zdań
|
|
DONE 3. Dzielenie zdań (max 255 tokenów)
|
|
|
|
DONE Anubis search się komplikuje! Przy tworzeniu obiektu tmMatches dla przykładu trzeba podać id przykładu, długość patternu i długość przykładu. Dwa pierwsze mamy, ale niestety nie ma skąd wziąć długości przykładu. Pamiętamy tylko offset sufiksu.
|
|
|
|
DONE 1. Bitwise operators (i stałe!) przy rozmiarze index character oraz markerów
|
|
DONE 2. Wykonać anubis search na nowych markerach z długością zdania
|
|
|
|
|
|
DONE zastanowić się nad optymalizacją:
|
|
REJECTED - tmMatchesMap jako normalna mapa (nie ptr_map)
|
|
REJECTED - LCP array
|
|
DONE - !important! rezygnacja z ptr_vector
|
|
DONE - zwracanie wektorów
|
|
DONE - powyrzucać using namespace std
|
|
DONE - profiling
|
|
|