fextor

hmm wygląda, jakby obiekt tworzony przez fextor2lexcsd a obiekt tworzony przez ltcore.io.load_matrix były innymi obiektami. Konkretnie, na tym co robi fextor2lexcsd nie mogę odpalić np. takiego align_to_first_matrix, bo wyskakuje "'LexCSDMatrix' object has no attribute 'get_extractor_for_column'". Śjakieś to dziwne, chciałem choć trochę uniknąć ciągłego zapisywania do pliku i wczytywania z powrotem, tylko żeby trochę operacji dało się w pamięci robić, ale nawet tutaj nie mam wyjścia i muszę utworzyć macierz w fextor2lexcsd, zapisać (make_tarfile), wczytać ją (load_matrix), zrobić align, zapisać (save_matrix), i jeszcze raz sam klasyfikator ją będzie wczytywał bo musi wyczuć, czy potrzeba mu 'numeric' czy nie.. Na takie ciągłe wczytywanie i zapisywanie niepotrzebni się traci czas imho.

W każdym razie wracając do tematu, może dlatego właśnie nie jest używane save_matrix tylko własna metoda fextor2.lexcsd.make_tarfile, skoro te obiekty chyba nie do końca są takie same

Tak, to nie są te same obiekty. Wewnątrz f2l po prostu mam wrapper na macierz LexCSD z inną reprezentacją macierzy.

A w jaki sposób jest zapewniona spójność pomiędzy tymi dwoma reprezentacjami? Są chociaż jakieś testy jednostkowe? Jest to opisane w komentarzach klas/metod, że spójność trzeba utrzymać?

Wyobrażam sobie taki scenariusz: ktoś (kto może nawet nie wiedzieć o istnieniu fextora) zmienia subtelnie reprezentację macierzy, fextor pozornie działa, bo to python ale ze względu na wprowadzone zmiany w macierzach wyniki działania całego systemu idą do śmieci...

Na podstawie "wrappera" tworzona jest macierz LexCSD (zapisywana na dysku). Bezpośrednio w fextorze nie ma obiektu ltcore.SparseMatrix, być może warto uwzględnić aby obiekt konwertowany był w pamięci, a zapis odbywał się za pomocą ltcore.io.matrix.save_matrix i wtedy trzeba będzie zadbać o spójność pomiędzy reprezentacjami.

Paweł Kędzia wrote:

Na podstawie "wrappera" tworzona jest macierz LexCSD (zapisywana na dysku). Bezpośrednio w fextorze nie ma obiektu ltcore.SparseMatrix, być może warto uwzględnić aby obiekt konwertowany był w pamięci, a zapis odbywał się za pomocą ltcore.io.matrix.save_matrix i wtedy trzeba będzie zadbać o spójność pomiędzy reprezentacjami.

Przy tym proponowanym rozwiązaniu spójność jest częściowo wymuszona, bo operujemy na tej samej reprezentacji danych... Testy jednostkowe też by pomogły...

Nie wiem czy dobrze zrozumiałem, to co Barek napisałeś odnośnie proponowanej reprezentacji, czy może ja się niejasno wyraziłem :-)
Generalnie chodzi mi o to, że to co jest aktualnie nie korzysta bezpośrednio z ltcore.SparseMatrix, każde pole macierzy w kolejnych krokach zapisywane jest na dysk twardy. Czyli testy jednostkowe w tym przypadku chyba nie będą odpowiednie, bo z tego co mi się wydaje, to testy takie nie powinny korzystać z zewnętrznych zasobów (jak na przykład pliki tymczasowe).
W przypadku, kiedy mówiąc o proponowanym rozwiązaniu chodzi o jednoczesne trzymanie w pamięci f2l.LexCSDMatrix oraz ltcore.SparseMatrix, to oczywiście spójność powinna być zachowana i jak najbardziej testy jednostkowe tutaj pomogą ją utrzymać.

Tylko wpadł mi właśnie do głowy pomysł... czy przypadkiem nie dojdzie do takiej sytuacji, kiedy w jednym czasie będziemy trzymać w pamięci dwie macierze i one po prostu się nie zmieszczą? Wtedy taki ciąg jak jest aktualnie, czyli konwersja do macierzy (na dysk), wczytanie tej macierzy oszczędzą trochę pamięci, choć wiadomo, że czasowo to nie będzie tak wydajne. Może warto rozważyć oba podejścia?

Trzymanie dwóch macierzy to problem. Testy jednostkowe - rzeczywiście to nie byłyby testy jednostkowe, ale można by skorzystać z mechanizmów testów jednostkowych do zrobienia testów bardziej funkcjonalnych. No i oczywiście trzeba to dosadnie napisać w dokumentacji (na zasadzie: zmieniasz coś tutaj, to sprawdź czy działa też tam).

Podsumowując, zostawiamy przejście konwersji jakie jest, ale należy dodać testy "spójności" pomiędzy "wrapperem" macierzy, a macierzą zapisaną na dysku?

Nadal nie jest dla mnie jasne, dlaczego jest używany wrapper a nie "rzeczywity" obiekt z lexcsd. Dlaczego nie można było użyć rzeczywistego obiektu z lexcsd i potem save_matrix, tylko wrappera, który wymaga potem swojej własnej metody zapisu i ostrożności w synchronizacji "semantycznej" z rzeczywistą klasą? Gdyby w ogóle nie używać wrappera tylko od razu macierzy, nie byłoby sytuacji równoważnej istnieniu dwóch macierzy w pamięci.

Jeśli rzeczywisty obiekt ma jakieś ograniczenia przeszkadzające w jego przyrostowej konstrukcji w locie i stąd potrzeba było wrappera, to może raczej zamiast wrappera lepiej by było zmienić rzeczywisty obiekt, podnosząc jego użyteczność i zapewniając, że fextor i fextor2lexcsd się nie rozjedzie.

Oczywiście w naturze mamy takie sytuacje, że dokumenty są zapisywane przez różne oprogramowanie do tego samego formatu, ale też różny tego bywa skutek np. MS Office i OpenOffice. Tak jak jest nie jest zatem aż tak wyjątkowa sytuacja, jednak prosi się o dokładną dokumentację formatu zapisu macierzy i tego, by wszystkie narzędzia z tym formatem były trzymane w synchronizacji "na słowo honoru". To zresztą i tak dobry pomysł gdyby ktoś chciał pisać jeszcze jakieś inne narzędzia nie na bazie lexcsd w Pythonie tylko np. C++. Skoro jednak kontrolujemy kod lexcsd i fextor2lexcsd, oba w pythonie, gdzie ten drugi i tak już pewne zależności z pierwszego bierze (choć chyba tylko logowani, więc dałoby się przeżyć) przyjrzałbym się argumentom, skąd ten dualizm klas w tym przypadku.

Jestem oczywiście w stanie przyjąć argument, że jest jak jest bo miało być "na już" i działać, a teraz nie ma czasu zastanawiać się nad ulepszaniem. Jednak gdy mnie nachodzą pewne wątpliwości wolę je wyartykułować może na jakieś lepsze czasy :)

Adam Wardyński wrote:

Skoro jednak kontrolujemy kod lexcsd i fextor2lexcsd, oba w pythonie, gdzie ten drugi i tak już pewne zależności z pierwszego bierze (choć chyba tylko logowani, więc dałoby się przeżyć) przyjrzałbym się argumentom, skąd ten dualizm klas w tym przypadku.

Nie mam teraz za bardzo czasu aby dokładnie prześledzić gita, ale wydaje mi się, że na samym początku nie było założenia, że fextor ma zależności w stronę LexCSD. Dopiero po którejś iteracji oraz po iluś rozmowach wyszła sprawa związana z logowaniem, aby korzystać z loggera, a nie wypisywać komunikatów bezpośrednio na stderr/stdout. I dopiero wtedy fextor2lexcsd wykorzystał logowanie oraz spójność pomiędzy nawami plików bezpośrednio z LexCSD. Jednak wtedy obsługa 'wrappera' była już gotowa, więc nie zastanawiałem się nad tym aby przepisać to co jest jeszcze raz tylko po to aby skorzystać z tego co jest w LexCSD.

Adam Wardyński wrote:

Jestem oczywiście w stanie przyjąć argument, że jest jak jest bo miało być "na już" i działać, a teraz nie ma czasu zastanawiać się nad ulepszaniem. Jednak gdy mnie nachodzą pewne wątpliwości wolę je wyartykułować może na jakieś lepsze czasy :)

Myślę, że jeżeli komuś będzie się kiedyś chciało i będzie miał czas, to może to spokojnie przepisać (?). Tylko wtedy pociągnie to za sobą trochę zmian aby wpisywać wartości bezpośrednio do matrix.data. I właśnie... matrix.data jest typu scipy.sparse.lil_matrix, co wtedy jak będzie wiele cech, których generowane wartości będą różnego typu? sparse.lil_matrix, chyba nie może przechowywać różnych typów?