Na jednym ze starych armów których używamy, odkryliśmy bład w pythonowym programie, gdzie podczas testowania punktów poza okręgiem o promieniu 30, niekiedy wartości wyskakiwały poza skalę.
W okręgu r<30 mamy ~60 punktów z wartościami, które im dalej od środka, tym bardziej się powinny zmniejszać. Dla punktów spoza okręgu r>30 musimy to ekstrapolować, bo do nich danych nie mamy.
Lokalnie na komputerze wszystko mi działało, choć metoda ekstrapolacji wartości RBFInterpolator(korzystamy ze starszej wersji scipy - nie możemy jej niestety łatwo podnieść na urządzeniu, by przetestować czy została naprawiona) dawała nieco niepoprawne i zawyżone wyniki.
Dla pewności ujednoliciłem wersje wszystkich pakietów(głównie zależności pośrednich, bo główne zależności były w tej samej wersji) pomiędzy urządzeniem i komputerem, jednak nie przyniosło to żadnej poprawy.
Przełożony na wieść że nie występuje problem lokalnie, zasugerował bym upewnił się że wszystko lokalnie sprawdzam z tymi samymi parametrami co na urządzeniu. Niezbyt wziął pod uwagę moje wątpliwości co do tego, że może jest to wina biblioteki - szczerze mówiąc się mu nie dziwię, bo z jego strony nie wyglądało to zbyt dobrze - gościu tylko od roku programujacy mówi że być może to nie jego wina i problem może występować w jednej z najpopularniejszych bibliotek pythona i w issues na githubie nie było nawet jednego podobnego wątku.
Ostatecznie udało mi się zilustrować wartości w siatce w kwadracie (od -100 do 100) przy użyciu matplotlib, gdzie widoczne było że na komputerze wartości w miarę regularnie zmniejszają w miarę oddalania od środka. W przypadku urządzenia ARM, wartości promieniście odchodzące z kątów 0,90,180,270 stopni poza okręgiem(r>30), są wybite poza wszelkie granice.
Wygląda więc że w przyszłości będziemy musieli, zainstalować na produkcyjnym sprzęcie pytest, by sprawdzić czy wszystko działa tak jak powinno na armowym urządzeniu, skoro nikomu już nie można wierzyć.
#python
#programowanie
@qarmin - super - no to teraz znajdź ten problem w kodzie biblioteki i stwórz poprawkę
@koszotorobur Być może problem jest naprawiony w nowszej wersji, ale nie możemy tego sprawdzić, więc zabawa w naprawianie błędu nie ma zbytnio sensu, jeśli nie możemy sprawdzić czy nie jest on przypadkiem już naprawiony.
Korzystamy ze starej wersji scipy na urządzeniu, ale nie dlatego że chcemy lub jesteśmy masochistami, tylko dlatego że nasz system budowania zależy od setuptools a nowsze wersje używają pyproject(a zmienić tego się łatwo nie da).
@qarmin - jak to nie macie tego jak sprawdzić? Nie macie środowiska developerskiego działającego na tej samej architekturze gdzie można uaktualnić zależności ręcznie i dostosować podejrzaną część kodu by zadziałał?
Ja wiem, że to dodatkowa robota ale to przynajmniej potwierdzi czy nowa wersja SciPy ma ten problem naprawiony czy nie - a jak nie to da wam możliwość stworzyć issue na GitHubie.
To jest świetne zadanie dla juniora aby się pokazać.
@koszotorobur Zrobiliśmy obejście implementując własną funkcję a teraz używamy jej jedynie do interpolacji, gdzie przetestowaliśmy że działa ona tam poprawnie.
wszystkie pakiety są cross-kompilowane ze zwyklłego serwera x86-64 przy użyciu Ubuntu przy użyciu skomplkowanych skryptów - nie wgłębiałem się w to, ale nie sądzę by to było proste i szybkie a poza tym mam na głowie inne zadania, którymi chyba lepiej się wykażę.
@qarmin
a na tym arm jaką masz implementację float? Słabiutkie ARM to softwareowe implementacje lub single precision only (jak algorytm nie uwzględnia wielkości epsilona maszynowego, to będzie problem)
Pierwsza malinka miała z tym problem i sporo distro latało na software fpu.
@globalbus Na pewno hard float, ale nie mam infa o precyzji - ale dane nie są jakieś graniczne ani nie wymagają dużej precyzji, więc nie sądzę by aż takie rozbieżności były z tego powodu.
@qarmin Szczerze, bardzo średnio chce mi się w to wierzyć. Przygotuj sobie wektory testowe i porównaj wyniki w kontrolowanym środowisku. Najprawdopodobniej masz odrobine inne dane wejściowe, dlatego dostajesz bs. Ewentualnie problemy ze zmiennym przecinkiem.
@groman43 Wszystkie dane mamy zaszyte w plikach pythonowych, bo nie jest tego dużo i nie korzystamy z zewnętrznych danych.
Akurat deploy programu na urządzenie jest robiony na podstawie branchy w gicie i jestem pewny że ta sama wersja była testowana lokalnie i na urządzeniu.
@qarmin Dane wejściowe od razu trafiają do podejrzanej funkcji, czy po drodze jest milion ifów, tysiąc pętli i trzydzieści siedem innuch rzeczy?
Edit: Pewnie Twój ARM ma 32-bity, a testujesz na maszynie 64-bitowej. To również może mieć znaczenie, bo zawsze coś gdzieś może się przekręcić.
Link to issue or didn't happened ( ͡° ͜ʖ ͡°)
@cec Ale jakiego issue? Nigdzie nie wspominałem że taki stworzyłem.
Cała rozmowa toczyła się na czacie firmowym i z wiadomych względów, nawet jej części tu nie umieszczę.
Co do issue w repo scipy, to jak wspominałem, używamy starszej wersji i być może jest to naprawione w nowej, jednak nie mamy jak tego przetestować(przynajmniej teraz).
Domyślam się że utworzeniu zgłoszenia o błędzie, pierwsze co by twórcy biblioteki zrobili, to napisali "Czy problem występuje w najnowszej wersji/wersji git?" lub po prostu od razu zamknęli zgłoszenie z tego powodu
Ja znalazłem błąd w Excelu. Znalazłem może za dużo powiedziane, bo okazuje się, że błąd został już zgłoszony kilka razy i Microsoft wie o nim przynajmniej od 2004(!) roku.
Polega on na tym że jak w arkuszu zabezpieczysz jakiś zakres komórek do edycji to na pozostałych nie działa zwiakszanie wcięcia poprzez przycisk na ribbonie. Działa za to przez menu formatowania komórki.
Czyli znalazles blad i nic z tym nie zrobisz? Sprobuj (jak juz ktos wspominal) namierzyc go w bibliotece, potem to samo miejsce sprawdzisz w nowszej wersji biblioteki i wyjdzie, czy to poprawili czy nie
Niesamowite że ktoś pomyślał że może z tym nie być problemu - zawsze powinno się budować, uruchamiać testy na docelowym sprzęcie (przecież tam będzie to wszystko działać na nie na kompie programisty lol). Dobrym pomysłem jest nawet redundancja, macie joba który uruchomi testy na x86_64 i joba na ARM, oba muszą przejść. Gdybyście kompilowali, to również im więcej kompilatorów tym lepiej. W embedded trzeba spodziewać się niespodziewanego.
A już totalną ignorancją okazali się prowadzący ten projekt jeśli uruchamiacie testy na 64 bitowej platformie, a docelową platformą jest 32 bitowy ARM
@ZohanTSW - ktoś bez pojęcia o architekturach procesorów, budowaniu aplikacji i jej testowaniu zaprojektował i wdrożył jakieś gówno CI/CD - a junior nie ma mocy przebicia by problem wzięli na poważnie - trzeba się więc jedynie spodziewać wykrycia większej ilości podobnych problemów w przyszłości
Najgorzej jak znajdziesz buga w Firefoxie i okazuje się że podobny błąd został zgłoszony w 2006 roku i od 18 lat toczy się pod nim dyskusja. Co jakiś czas ktoś pyta kiedy to będzie naprawione, następnie ktoś z mozilli odpowiada że nad tym pracuje by za dwa lata znowu dostać pytanie o postępy xD
Zauważyłem np że firefox na androidzie bardzo często odświeża strony po powrocie do niego, tak jakby od razu po przeskoczeniu do innej apki czyścił dane strony z pamięci. Oczywiście zgłoszony bug wisi od paru lat w backlogu bo niby ważny błąd ale jakoś tak nie umieją go odtworzyć
(sorki za offtop xD)
@Ilirian a to jest podobno cecha wszystkich przeglądarek na Android poza Chrome. Specjalistą nie jestem ale czytałem, że to celowe zamierzenie Google
Używacie biblioteki scipy i się dziwicie… zaciągnijcie normalnie z github a nie z jakiejś cipy…
Zaloguj się aby komentować