Nie wiem, czy to normalne, ale powinno być normalne dla wszystkich recenzentów, aby podejmowali rozsądne wysiłki w celu sprawdzenia, czy twierdzenia autorów są prawidłowe, więc o ile nie jest to normalne, Mogę tylko pochwalić recenzenta za gotowość do podjęcia wysiłku, którego nie podejmują inni recenzenci. To, co czujesz jako „nieufność”, to to, że recenzent wykonuje swoją pracę, nic więcej lub mniej (i prawdopodobnie jest dość trafne stwierdzenie, że zadaniem recenzenta jest nieufność do twierdzeń autora, więc nie widzę idei bycia nieufnym ze strony recenzenta jako coś, czego należy się wstydzić lub obrażać).

Nawiasem mówiąc, powinno być również normalne, że autorzy udostępniają wszelkie oprogramowanie (w tym kod źródłowy, jeśli to możliwe) potrzebne do powielenia i weryfikacji ich wyników. Jeśli więc nie jesteś zadowolony z tego, że recenzent wraca do ciebie z irytującymi prośbami, które opóźniają decyzję w sprawie twojego artykułu, następnym razem możesz zapobiec takim problemom, publikując swój kod źródłowy (lub przynajmniej przesyłając go do czasopisma) wraz z rękopisem. Jestem pewien, że recenzent byłby znacznie szczęśliwszy i ostatecznie wszyscy skorzystaliby, łącznie z tobą.

Pochodzę z innej dziedziny, w której kod, którego używamy, nie jest głównym wynikiem. Ale jeśli sędzia poprosiłby o kod, udzielilibyśmy go i szczęśliwie. Większość naszej pracy jest wykonywana w Pythonie, więc plik wykonywalny nie byłby normalny, a źródło byłoby (również prawdziwe dla matlab).

Właściwie jedyną rzeczą, która wydaje mi się nieco dziwna, jest użycie wykonywalne zamiast źródła.

Nie obrażaj się żądaniem z kilku powodów: nie jest zadaniem recenzentów ufać tobie; ich zadaniem jest sprawdzenie twojego papieru. Jeśli recenzent na tyle interesuje się twoją pracą, że chce uruchomić kod, nie odrzucił twojej pracy z ręki.

Podsumowując sytuację na podstawie danych: -

1) Wymyśliłeś algorytm na papierze / Matlabie / czymkolwiek.

2) Zaimplementowałeś ten algorytm w niektórych programach

3) Zbudowałeś zestaw danych testowych, aby przetestować algorytm, i dostałeś kilka wyników, które pokazują, co powinien robić w teorii.

4) Umieściłeś ten test dane za pośrednictwem kodu i otrzymałem wyniki pokazujące to, co robi w praktyce.

W tym procesie jest wiele miejsc, w których może wystąpić problem z Twoją metodologią. Twój kod może nie odzwierciedlać poprawnie Twojego algorytmu. Twoje dane testowe mogły zostać przetworzone wstecz od kodu zamiast do przodu od algorytmu. Twoje dane testowe dla algorytmu i dane testowe dla kodu mogą się różnić.

Chyba że recenzent ma algorytm i kod źródłowy i wszystkie dane testowe zarówno dla , jak i wszystkich danych wyjściowych dla obu, nie mogą one zweryfikować, czy Twoja praca jest solidna i czy wnioski są prawidłowe. Nie podlega to sporze - jest to logicznie niemożliwe, jeśli chcą odpowiednio przejrzeć Twoją pracę. Cokolwiek innego to przyjmowanie założeń, które mogą być nieważne.

Osobiście byłem dotknięty tą sytuacją, kiedy moja firma kupiła od badacza jakąś IP teorii sterowania. Napisał artykuły na temat tego, jak to miało działać i stojącej za tym teorii, a następnie zbudował trochę elektroniki, aby wdrożyć swoją teorię. Jego artykuły obejmowały teorię, a także zawierały schematy elektroniki. Kiedy przeczytałem to, aby dowiedzieć się, jak zaimplementować jego teorię w oprogramowaniu, stwierdziłem, że schemat zawiera dodatkowy filtr. Działanie tego filtra okazało się krytyczne dla stabilności, a nawet skuteczności systemu, ale nigdzie nie zostało udokumentowane w jego pracy. Dopiero gdy rozmawialiśmy z nim telefonicznie, dowiedzieliśmy się, do czego służy filtr i jak mieliśmy go dostroić.

Było to w artykule, który teoretycznie był recenzowany w momencie publikacji. Najwyraźniej nie został on wystarczająco dokładnie oceniony! Jego wyniki pokazały, że przy tych samych danych wynik implementacji był bardzo zbliżony do teoretycznego oczekiwanego wyniku, a efekt filtra był w innym miejscu w odpowiedzi. Mimo to implementacja nigdy nie działałaby bez obecnego filtra i nie byłoby wcale trudno uwzględnić to w modelu teoretycznym. Mógłby nawet powiedzieć, że „ten filtr jest wymagany z tych powodów, ale można go zignorować w tym obszarze odpowiedzi, na którą patrzymy z tych powodów” i zostałby objęty. To, co jest niedopuszczalne, to to, co zrobił, czyli w ogóle o tym nie wspominając, ponieważ końcowym rezultatem tego jest to, że ktoś próbujący wdrożyć jego pracę nie byłby w stanie.

Jak powiedziałem, on nadal publikuje swoją pracę i nikt nie narzekał w tym czasie. Powinien jednak zostać zauważony przez jego oryginalnych recenzentów. W Twoim przypadku recenzent powinien szukać takich rozbieżności - to cały punkt recenzji. Więc jeśli ludzie proszą Cię o rzeczy, których nie udostępniłeś, (a) to dobry znak, że dokładnie sprawdzają, i (b) powinieneś był to udostępnić w pierwszej kolejności jako najlepsza praktyka.

Zgłaszanie artefaktów to rzecz w CS. Widziałem, że przygotowujesz maszynę wirtualną, na której oprogramowanie jest już skonfigurowane i gotowe do przeprowadzania eksperymentów. Dlatego recenzent może odnosić się do tego, że czasopismo ma jakąś oficjalną procedurę zgłaszania artefaktów. Alternatywnie, niektórzy autorzy po prostu udostępniają kod źródłowy swoich narzędzi i testów porównawczych za pośrednictwem usług takich jak github, a recenzent może sugerować, że powinieneś to zrobić. Jeśli chodzi o nieufność, informatycy są naturalnie ostrożni w stosunku do testów porównawczych i narzędzi, ponieważ ostateczne dane mogą w dużej mierze zależeć od sposobu skonfigurowania eksperymentu (np. Jeśli porównujesz z własną implementacją istniejącego algorytmu, czy zaimplementowałeś go poprawnie ). Może się również zdarzyć, że liczby, które podajesz w artykule, wydają się nieco dziwne, ale wtedy recenzent wskazałby, co dokładnie im nie pasuje.

Przesłanie pliku wykonywalnego to nie to samo, co przesłanie kodu źródłowego. Plik wykonywalny tak naprawdę nie daje odbiorcy dostępu do oryginalnego kodu (co oczywiście student informatyki powinien już wiedzieć). Nie widzę problemu z tą prośbą.

Biorąc pod uwagę moje osobiste doświadczenia ze społecznościami open source i założenie, że artykuł zawiera całość omawianego algorytmu, wysłanie kodu źródłowego lub powiązanej kompilacji wspomnianego oprogramowania nie przyniosłoby wielu negatywnych skutków.

Pozwoliłoby to recenzentowi zweryfikować wyniki i twierdzenia autora artykułu. Kluczową kwestią, której może poszukiwać recenzent, jest to, że poprawnie zaimplementowałeś algorytm w kodzie źródłowym i nie opierasz się błędnie na funkcji języka programowania, systemu operacyjnego lub sprzętu, aby twierdzić o jego czasie działania lub innych funkcjach.

Na samą myśl chciałbym odnieść, że w przypadkach związanych z I / O łatwo jest pomylić wydajne algorytmy z, na przykład, zdolnością Javascript do uczynienia prawie każdego wywołania funkcji asynchronicznymi. Oczywiście jest to głównie widoczne w operacjach związanych z we / wy, a nie w proliferacyjnych pętlach obliczeniowych. Wtedy zmierzona wydajność nie jest wydajnością algorytmu jako formalnego dowodu, ale; zamiast tego opiera się na funkcji specyficznej dla języka.

Najistotniejsze jest to, że istnieje wiele przypadków, w których formalny algorytm i implementacja mogą odbiegać od wiernego reprezentowania siebie nawzajem, a robiąc to, wniosek, jeśli jest oparty na metrykach empirycznych, takich jak czas działania, może przebiegać w wiele kwestii, w których niewłaściwa implementacja może świadczyć o błędnym wniosku.

Kod źródłowy może zawierać błędy i aby naprawdę skutecznie przejrzeć algorytm, opis samej metody w prozie może być niewystarczający. Dzielenie się czymś poza tekstem jest korzystne; dobry artykuł z rzeczywistym kodem źródłowym (+ przykładowe dane wejściowe) to złoty standard odtwarzalności.

Jedna zabawna uwaga: w zależności od miejsca, w którym znajduje się recenzent, możesz nie być dozwolony aby dać im plik binarny. Np. Część kodu korzysta z prawnie zastrzeżonych bibliotek, które są licencjonowane bezpłatnie w środowisku akademickim, ale ktoś z branży może wymagać oddzielnej licencji, aby nawet używać istniejącego pliku binarnego, a tym bardziej go kompilować. (zdarzyło mi się to raz, ale nie w ramach wzajemnej oceny)

To idiotyczna prośba z jego strony.

1. Mógłby złapać wirusa.
2. Nie ma realistycznego sposobu na sprawdzenie, czy plik wykonywalny implementuje to, co opisano w twoim artykule ergo w żadnym wypadku prośba nie ma jakiejkolwiek wartości naukowej.

Powinien prosić o kod źródłowy i to wszystko, na co powinieneś się zgodzić daj mu.