- wyłączyć stopWords
IN PROGRESS - concordia search zwraca pozycje tokenów z hash'a. Jak to odnieść do examples w korpusie?
- 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?
- concordia-server (zastanowić się, czy nie napisać CAT-a)
- zastanowić się nad empty hash examples (rozwiązanie: w ogóle nie szukać fraz o pustym hashu, rzucać wyjątek).
- puścić 100% search test na jrc



---------------------------- Archive -----------------------------

DONE - Przy concordia searh 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