tas tā notiek jo ir dažādi ievades dati.

palasi vairāk par pulsu. realitātē ir tā, ka to ietekmē simtiem faktoru sākot no gaisa temperatūras, beidzot ar kafiju, nogurumu, kad bijusi pēdējā ēdienreize un kas ēsts. uz visa tā fona 1bpm nesakritība ir praktiski neeksistējoša. varbūt vienkārši atšķiras kā skaitļi tiek apaļoti, viens apaļo visu uz augšu, otrs tikai sākot ar 0.5.

tas tā notiek jo ir dažādi ievades dati.

kam tad ticēt?

Drīzāk viens softs skaita no nulles, bet otrs no 1. 8)

tas darbojas tikai masīvos ar indeksiem, absolūtās vērtības vienmēr tiek attēlotas kā n nevis n-1.
movescount parsē .fit failu, bet pulkstenis apstrādā vērtības no sensoriem, kuras pēc tam glabā .fit failā, tur arī visticamāk ir atšķirība + apaļošana daudz kur ir implementēta dažādi.

jūs te kaut ko pamatīgi putrojat un no gaisa pagrābtas lietas metad vienā katlā.

tātad- pulkstenī iekšā ir softs, kurš saņem datus no sensoriem, reālajā laikā rēķina visādas vidējās vērtības un attēlo tās kopā ar absolūtajām vērtībām uz pulksteņa ekrāna un paralēli glaba datu krātuvē TIKAI absolūtās vērtības ar timestamp. pēc treniņa parāda to ko ir sarēķinājis pulkstenis pats un datu kratuve tiek eksportēta uz mākoni- šajā gadījumā movescount. movescount atkal ņem absolūtās vērtības no datu krātuves un pārrēķina pa savam, kur visticamāk rodas neliela nobīde, jo ievades dati vairs nav pa tiešo no sensoriem, bet gan kaut kas līdzīgs fit failam, un viss tiek pārrēķināts pa jaunam. nelielas atšķirības algoritmos + mazliet atšķirīgu datu izmantošana, dažādu programmēšanas valodu atšķirības (piemēram dažādas valodas dažādi apaļo decimālskaitļus). aiz gara laika esmu ņēmies gan ar suunto aplikāciju veidošanu, gan parsējis gpx/fit failus.

atkarīgs no implementācijas, ir funkcijas, kas nekad neapaļo uz augšu un ņem tikai veselos skaitļus, ir kas apaļo visādos dīvainos veidos, piemēram apaļo pa vienam ciparam sākot no pēdējā tādējādi 0.46 noapaļo uz 1, jo vispirms 0.46 noapaļu uz 0.5 un tad 0.5 uz 1

Kārtējie bugs.
https://ibb.co/jPWpOc