Panel użytkownika
Nazwa użytkownika:
Hasło:
Nie masz jeszcze konta?

[C++] Liczba narcystyczna - optymalność mojego kodu.

Ostatnio zmodyfikowano 2015-02-22 23:01
Autor Wiadomość
aksen
» 2015-02-21 19:25:59
dla pojedynczej liczby zarówno ten z sortowaniem, jak i bez wykonywały się po kilka tysięcy razy

Nie porównywałbym działania programów dla pojedynczej i konkretnej liczby (bo jest to po prostu jakiś tam szczególny przypadek). Dla jednej liczby obliczenia mogą się kończyć nawet po pojedynczym potęgowaniu, a dla innej po wielu. Najlepszy test na porównanie obu użytych algorytmów to sprawdzenie tysięcy czy milionów kolejnych (różnych) liczb. Wtedy wyjdą ci czasy obliczeń, których porównywanie ma jakiś większy sens.

PS.
Zamiast sortowania bąbelkowego można by użyć tu jakiegoś szybszego sortowania. (http://edu.i-lo.tarnow.pl/inf/alg/003_sort/0025.php)
Sortowanie mogłoby mieć większy sens przy dużych liczbach. Ogólnie nad tematem można spędzić dni czy tygodnie (na teorii, testach
porobić porównania i wykresy, analizować złożoności czasowe algorytmów optymalizować oraz się doktoryzować ;)
P-126990
Toreno96
Temat założony przez niniejszego użytkownika
» 2015-02-21 19:41:51
aksnet, tak też zrobiłem :)
Wprowadziłem kod odpowiedzialny za to, by program na początku losował jakąś dużą liczbę, a następnie sprawdzał pod względem czasu, który z algorytmów zajął się nią szybciej. Sprawdzanie jednej liczby po kilka tysięcy razy na algorytm wprowadziłem dlatego, że w przeciwnym wypadku czasy wykonania algorytmów, jakie otrzymywałem, były za małe, by można je było porównać - program traktował je jako równe sobie.
Wylosowanie liczby -> Start odliczania od 0 -> Pierwszy algorytm -> Koniec odliczania i zapis wyniku do odpowiedniej zmiennej -> Start odliczania od 0 -> Drugi algorytm -> Koniec odliczania i zapis wyniku do zmiennej -> Porównanie zapisanych w zmiennych wyników. I tak kilka tysięcy razy.
P-126992
aksen
» 2015-02-21 19:44:16
Losowanie liczb nie ma sensu bo wtedy porównujesz programy dla różnych danych wejściowych. Dane powinny być takie same.
Zrobiłbym zwykłą pętle i jechał kolejno.
P-126993
Dragonit
» 2015-02-21 19:51:12
Dane powinny być takie same.
Są, po tym co pisze, jedynie końcowe wyniki będą za każdym razem inne, lecz porównanie obu sposobów będzie równoległe.
P-126994
aksen
» 2015-02-21 19:56:26
Jak chcesz pobawić się tematem bardziej życiowym poczytaj o "problemie komiwojażera" (google).
Temat trudny, ale ma praktyczne zastosowania i możesz optymalizować do woli.
(liczby narcystyczne chyba praktycznych zastosowań nie mają ;)
P-126995
Piastlis
» 2015-02-22 01:40:12
Problem jak problem. Powiedzmy że na konkurs. "Napisz program obliczający ilość wszystkich liczb narcystycznych w podanym zakresie w jak najkrótszym czasie".
Taka "formuła 1". Całkowicie niepraktyczne ale dopracowane na maksa.
Jestem pewien że Twoja metoda z sortowaniem nic nie poprawi a wręcz spwolni program.
Aby obliczyć l.n. składającą się z n cyfr trzeba wykonać (n+1)*n działań arytmetycznych.Każde po 1 takcie procesora.Plus n razy po kilka taktów na wywołanie funkcji potega i instrukcji for. A sortowanie ma kosztowność n*n operacji porównania i zamiany a w przypadku pozytywnym jeszcze policzenie .
Lepszym rozwiązaniem byłoby stablicowanie potęg czyli skorzystanie z gotowca.Liczba może mieć max 18 cyferek:

1   0 1 2  3   4    5 ...     9
2   0 1 4  9  16  25 ...    81
3   0 1 8 21 64 125 ...  729
.
.
18
 
Do policzenia l.n. wystarczy tylo n dodawań.:)
Można zastanowić się nad zastosowaniem prostszego algorytmu :
dla liczby 2 cyfrowej można zrezygnować z obliczeń np gdy kończy się na 5 a jest mniejsza równa 25 lub jak na 9 to mniejsza równa niż 81.Powinno to zdyskwalifikować  25% liczb ale dodaje się dodatkową instrukcję if. Dla liczb 3 cyfrowych z szacowania  18% a dla 18 cyferek to 5% .Wszystko zależy od tego czy l.n. jest wystarczająco dużo w zakresie.W najlepszym przypadku zysk to pojedyńcze procenty ale to tylko jedna instrukcja.

Możesz popracować nad sortowaniem. Może być 4 razy szybsze.

P.s.
Pomysł z ograniczaniem zakresu okazał się kiepski.Dla zakresu 1-1E7 czasy identyczne 0.48s a dla 1-1E9 spowolnienie z 77s na 80s.Mam zegar 2.4G więc wychodzi średnio ok. 3.5 takty na cyferkę. 1 na pobranie z tablicy i dodanie i 2.5 na obsługę :)
P-127048
pekfos
» 2015-02-22 10:58:47
Rozwiązania w tym temacie zaczynają się powtarzać.. ;)

Mam zegar 2.4G więc wychodzi średnio ok. 3.5 takty na cyferkę. 1 na pobranie z tablicy i dodanie i 2.5 na obsługę :)
Nie pisz głupot.
P-127052
Piastlis
» 2015-02-22 21:04:53
Nie rozumiem.Miliard liczb komp mi sprawdził w 77 sekund.Według Ciebie ile cykli procesora  przypada na liczbę i na cyfrę.
P-127166
1 « 2 » 3
Poprzednia strona Strona 2 z 3 Następna strona