Potrzebuję zmierzyć w programie czasy reakcji użytkownika i czas operacji. Dokładność ma być maksymalna, interesują mnie milisekundy. Oczywiście najczęściej procesor "odzywa się" co jakieś 55 milisekund, ale o to akurat mniejsza. Bo problem leży w odejmowaniu.
Dokonując pomiaru czasu w większości języków programowania otrzymuje się cztery zmienne - odpowiadają one za godzinę, minutę, sekundę i sekundę setną zegara. Oczywiście każdy, kto chciałby obliczyć ile czasu trwa operacja postąpi wg. algorytmu:
Pomiar_czasu1
Operacja
Pomiar_czasu2
Porównanie_pomiarów.
W teorii po prostu wystarczy odjąć od czasu2 czas1, prawda? Schody zaczynają się, kiedy łapiemy, że nie otrzymujemy 1 danej dla pomiaru czasu, tylko cztery. Odejmowanie przebiega więc etapowo. Można pomijając jakość algorytmu np. sprowadzić cztery zmienne do jednej - czyli do wartości setnych sekund. Godzina to 60 minut, czyli 60*60=3600 sekund, czyli 60*60*100=360000 milisekund. Mnożymy poszczególne dane, sumujemy i mamy:
GG:MM:SS:S100
11:35:56:81 = 11*360000+35*6000+56*100+81
To przynajmniej proponują widoczne w sieci algorytmy. Po sprowadzeniu obu pomiarów do takich danych mamy dwie liczby całkowite, które odejmujemy od siebie i powinniśmy dostać w milisekundach ile czasu upłynęło między pomiarami...
NIC bardziej MYLNEGO!
Ten algorytm nie ma prawa działać, bo działa do momentu w którym każda z liczb pomiarowych1 jest większa od liczb pomiarowych2:
GG1<GG2
MM1<MM2
SS1<SS2
S1001<S1002
W przeciwnym razie dostaje się dane błędne
Weźmy na przykład dwa takie czasy:
czas1 - 23:59:00:02
czas2 - 00:00:01:07
Jak widać minęło między nimi 1 sekunda i 55 milisekund.
Powyższy algorytm zaś przedstawi:
czas2 - czas1 =
GG1*360000+MM1*6000+S1*100+S1001
- GG2*360000+MM2*6000+S2*100+S1002
107 - 83154002 = -83153895 milisekund, co jest wynikiem absurdalnym. Można by znaleźć więcej problemów, ale chodzi o zwrócenie uwagi na coś. Taki algorytm w najlepszym wypadku liczy arbitralną odległość w milisekundach od północy. Nie tyle problem tkwi w tym, że licznik czasu "przeskoczył" o północy i dlatego algorytm się wysypuje, tylko o odwieczną sprawę związaną z odejmowaniem pisemnym: "pożyczkę". Jeśli odejmuję czasy s1002-s1001 = 2-7 = -5, otrzymuję liczbę ujemną. Warto było by odliczyć to z sekund, jak przy odejmowaniu pisemnym odlicza się z pożyczki. Hmm... Tu zauważyłem, że trudno mi to opisać, ale wiadomo o co chodzi?
W ogóle format czasu nie sprzyja takim prostym operacjom jak odejmowanie. Odejmowanie pisemne i jego algorytmy działają dobrze dla liczb które mają zakres 0-9 w każdym z pól. W takim czasie mamy cztery pola, gdzie jedno ma zakres 0-99, dwa 0-59, a jedno 0-23.
Czy ktoś z Was ma pomysł, jak napisać algorytm odejmowania od siebie czasów pomiaru? Może być schemat. Preferuję Pascala, C, Assemblera. Ale chodzi o rozważenie problemu. Proszę o pomoc, bo muszę skończyć szybko badania;). Kto się zmierzy?
Dokonując pomiaru czasu w większości języków programowania otrzymuje się cztery zmienne - odpowiadają one za godzinę, minutę, sekundę i sekundę setną zegara. Oczywiście każdy, kto chciałby obliczyć ile czasu trwa operacja postąpi wg. algorytmu:
Pomiar_czasu1
Operacja
Pomiar_czasu2
Porównanie_pomiarów.
W teorii po prostu wystarczy odjąć od czasu2 czas1, prawda? Schody zaczynają się, kiedy łapiemy, że nie otrzymujemy 1 danej dla pomiaru czasu, tylko cztery. Odejmowanie przebiega więc etapowo. Można pomijając jakość algorytmu np. sprowadzić cztery zmienne do jednej - czyli do wartości setnych sekund. Godzina to 60 minut, czyli 60*60=3600 sekund, czyli 60*60*100=360000 milisekund. Mnożymy poszczególne dane, sumujemy i mamy:
GG:MM:SS:S100
11:35:56:81 = 11*360000+35*6000+56*100+81
To przynajmniej proponują widoczne w sieci algorytmy. Po sprowadzeniu obu pomiarów do takich danych mamy dwie liczby całkowite, które odejmujemy od siebie i powinniśmy dostać w milisekundach ile czasu upłynęło między pomiarami...
NIC bardziej MYLNEGO!
Ten algorytm nie ma prawa działać, bo działa do momentu w którym każda z liczb pomiarowych1 jest większa od liczb pomiarowych2:
GG1<GG2
MM1<MM2
SS1<SS2
S1001<S1002
W przeciwnym razie dostaje się dane błędne
Weźmy na przykład dwa takie czasy:
czas1 - 23:59:00:02
czas2 - 00:00:01:07
Jak widać minęło między nimi 1 sekunda i 55 milisekund.
Powyższy algorytm zaś przedstawi:
czas2 - czas1 =
GG1*360000+MM1*6000+S1*100+S1001
- GG2*360000+MM2*6000+S2*100+S1002
107 - 83154002 = -83153895 milisekund, co jest wynikiem absurdalnym. Można by znaleźć więcej problemów, ale chodzi o zwrócenie uwagi na coś. Taki algorytm w najlepszym wypadku liczy arbitralną odległość w milisekundach od północy. Nie tyle problem tkwi w tym, że licznik czasu "przeskoczył" o północy i dlatego algorytm się wysypuje, tylko o odwieczną sprawę związaną z odejmowaniem pisemnym: "pożyczkę". Jeśli odejmuję czasy s1002-s1001 = 2-7 = -5, otrzymuję liczbę ujemną. Warto było by odliczyć to z sekund, jak przy odejmowaniu pisemnym odlicza się z pożyczki. Hmm... Tu zauważyłem, że trudno mi to opisać, ale wiadomo o co chodzi?
W ogóle format czasu nie sprzyja takim prostym operacjom jak odejmowanie. Odejmowanie pisemne i jego algorytmy działają dobrze dla liczb które mają zakres 0-9 w każdym z pól. W takim czasie mamy cztery pola, gdzie jedno ma zakres 0-99, dwa 0-59, a jedno 0-23.
Czy ktoś z Was ma pomysł, jak napisać algorytm odejmowania od siebie czasów pomiaru? Może być schemat. Preferuję Pascala, C, Assemblera. Ale chodzi o rozważenie problemu. Proszę o pomoc, bo muszę skończyć szybko badania;). Kto się zmierzy?