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
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
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)
Używacie biblioteki scipy i się dziwicie… zaciągnijcie normalnie z github a nie z jakiejś cipy…
Zaloguj się aby komentować
