WCRFT

Mam sporo uwag do ostatniej wersji (z poniedziałku — 7 kwietnia).
Obecna wersja ma niewiele wspólnego z zaplanowanymi założeniami.

W szczególności podczas ostatniej rozmowy ustaliliśmy, że do klasy Wcrft przenosimy funkcje opisane wyżej, które same tworzą reader i writery tj.:

void tag_input(
    const std::string &in_path, // if "" then reads from stdin
    const std::string &out_path, // if "" then writes to stdout
    const std::string &input_format, // e.g. "text", "xces" 
    const std::string &output_format, // e.g. "xces,flat", "ccl" 
    bool preserve_chunks = true, // WIEM, że to było domyślnie false w pytonie, ale to był bład :D
    bool preserve_ambiguity = false
);

void train_and_save(const std::string &in_path, const std::string &input_format);

Funkcja tagująca string w string jest kontrowersyjna i jeśli w ogóle jest tu dla niej miejsce, to powinna się nazywać tak, by użytkownik wiedział, że należy tego unikać (to jest koszmarnie niewydajne, trzeba cały tekst załadować do jednego wielkiego stringa i potem generuje całe wyjście do bufora i robi z niego stringa). Chodzi mi o funkcję z obecnego kodu:

std::string tag_input(std::string input);

Jeśli już, to powinna się nazywać np. tag_input_from_string i w komentarzu dodać coś w stylu „Warning: this may be very inefficient, especially for longer input. It is strongly recommended to use tag_input instead unless you really know what you are doing.”

Poza tym, nie możemy tutaj zakładać, że na wyjściu jest iob_chan. Format powinien być tak samo parametryzowalny jak w przypadku pozostałych funkcji — const std::string &input_format oraz const std::string &output_format.

Kolejna rzecz to uczenia tagera. Nie da się nauczyć tagera jednym zdaniem / akapitem. Ta funkcja nie ma sensu. Proponuję trzymać się API, które jest w pytonie, znowu input format i pozostałe parametry readera.