Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości grup
dyskusyjnych:k5pt27$1pe$...@m...internetia.pl...
> On 18.10.2012 11:52, slawek wrote:
>> void very_fast_random(double* a, int n)
>> {
>> for(int i = 1; i < n; i++) a[i] = a[i-1];
>> }
>
> I jakie to ma cechy ciągu losowego?

Przecież miało być szybko kosztem jakości.

Z wyraźnym wskazaniem na całkowite olanie sprawy czy liczby naprawdę są
losowe.

Więc dałem reductio i wyszedł absurd. q.e.d.

do góry

Ponurą porą Thu, 18 Oct 2012 22:13:36 +0000, Baranosiu wyszeptał:

> Dnia 18.10.2012 slawek <h...@s...pl> napisał/a:
>> A Ziemia jest płaska i oparta o cztery forumowe trolle?
>>
>> Jeżeli to jest kula (bila) i jeżeli porusza się w naszym Wszechświecie,
>> ma masę, pęd, moment pędu i ładunek elektryczny (np. równy zero) - to
>> daruj sobie wmawianie, że składowe wektora prędkości muszą być liczbami
>> całkowitymi - a nawet jeżeli przez przypadek są (pamiętaj, Heisenberg),
>> to jeszcze jest czas, który tworzy continuum.
>>
>> Pomnóż sobie całkowitą składową prędkości przez niewymierny czas (np. t
>> = 2 pi) i już jest pozamiatane w sprawie "całkowitych (x,y)".
>
> Ale po co skoro można DOKŁADNIE policzyć to (w przestrzeni
> Newtonowskiej) na liczbach całkowitych? To jest tak, jakby w zadaniu
> było "policz owce widoczne na obrazku" a ty byś powiedział, że na
> liczbach całkowitych się nie da, bo nie dość że owce widoczne są tylko z
> jednej strony, to jeszcze jednej owcy widać tylko 49% a drugiej za to
> 51%, pozatym być może niektóre są wydrukowane w ultrafiolecie i człowiek
> nie widzi, ale pszczoła widzi, więc zadanie nie jest jednoznaczne i nie
> da się go rozwiązać, no i kto widział płaskie (dwuwymiarowe) owce o
> długości 2.5cm (bo tyle zajmują na kartce), czy w ogóle można je za owce
> uznać? A skoro już "pamiętaj, Heisenberg" to z tego samego powodu jest
> prawdopodobieństwo, że do Ciebie dociera inny tekst niż napisał autor
> (prawdopodobieństwo znikome, ale jednak niezerowe :D).

Chyba za dużo używacie stuffu robionego przez Heisenberga, tak moim
skromnym zdaniem. Obaj.

--
Edek

do góry

On 19.10.2012 00:32, slawek wrote:
>
> Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości grup
> dyskusyjnych:k5pt27$1pe$...@m...internetia.pl...
>> On 18.10.2012 11:52, slawek wrote:
>>> void very_fast_random(double* a, int n)
>>> {
>>> for(int i = 1; i < n; i++) a[i] = a[i-1];
>>> }
>>
>> I jakie to ma cechy ciągu losowego?
>
> Przecież miało być szybko kosztem jakości.

Nie, miało być "tak szybko jak się da, ale nie szybciej". Twój algorytm
jest tak bardzo do przodu, że mu z tyłu trolluje.


> Z wyraźnym wskazaniem na całkowite olanie sprawy czy liczby naprawdę są
> losowe.

Liczby naprawdę losowe uzyskasz z generatora sprzętowego. Zazwyczaj
wystarczające są liczby _pseudolosowe_. Na określenie "losowości" są
różne testy, dające jakieś wyobrażenie o "jakości" generatora. rand()
nie ma najlepszych wyników, ale jest wystarczająco dobry dla typowego
przypadku a przy tym jednym z najszybszych generatorów. Twój algorytm
nawet nie stał koło generatora pseudolosowego.

> Więc dałem reductio i wyszedł absurd. q.e.d.

Przedstawiłeś inny problem to i wyszedł absurd.


--
Pozdrawiam
Michoo

do góry

Dnia 18.10.2012 Michoo <m...@v...pl> napisał/a:
> On 17.10.2012 22:28, Baranosiu wrote:
>> Z technicznego punktu widzenia rejestr to taka sama pamięć jak RAM czy
>> cache,
>
> Zwłaszcza, że RAM jest pamięcią dynamiczną a cache i rejestry pamięcią
> statyczną(i to też pamięć RAM tak w sumie) więc technicznie to się dość
> mocno różnią. Logicznie to i to jest pamięcią.

Pamięci cache czy RAM są realizowane w różnych technologiach (tak samo
zresztą jak rejestry) ale wszystkie są pamięciami (z punktu widzenia
funkcjonalności, a czy fizycznie to jest kondensator, którego trzeba
"odświeżać" czy zatrzask na tranzystorze, to już tylko kwestia kosztu
produkcji i poboru mocy :D).


>
>> a że nie jest podpięty do szyny adresowej
>
> Której szyny adresowej? Jest ich w komputerze kilka a jak sam zauważyłeś
> rejestry są kawałkiem pamięci - jakoś zaadresować je trzeba.

Miałem na myśli to, że nie mają wspólnej przestrzeni adresowej z RAM-em.

>> ale już na przykład w
>> niektórych procesorach RISC (choćby takie małe Atmegi z rdzeniem AVR)
>> rejestry są jak najbardziej adresowalne.
>
> Bo skoro na pokładzie jest tylko kilka kilo SRAM to umieszczanie tam
> rejestrów jest naturalne. W x86 L1 jest zazwyczaj kilka razy większe a
> pamięć rejestrów niewiele mniejsza od całej pamięci w małym uC.

Chodziło też między innymi o dwie dodatkowe funkcjonalności:
1) DMA może wrzucać dane bezpośrednio do rejestrów procesora.
2) Funkcje biblioteczne mogą działać zarówno na danych w SRAM jak i na
danych w rejestrach (ten sam kod, kwestia podania innego wskaźnika do
danych).

Podałem przykład AVR-a, bo taki mi przyszedł do głowy (akurat pisałem
program na taki mikrokontroler :D), ale wiele procesorów ma tego typu
wynalazki jak "zerowe strony pamięci" czy "adresowalne cache", choć
nie zawsze te obszary mają w 100% identyczną funkcjonalność jak
rejestry, no ale z drugiej strony nawet w x86 nie wszystkich rejestrów
można użyć do wszystkiego (pomijam rejestry tupu program counter czy
stack pointer, bo ich specjalne przeznaczenie jest oczywiste).

>> Takie pierdoły jak "register
>> rename" wynikają z prostego faktu, że nawet tanie mikrokontrolery za
>> 20zł mają 32 ortogonalne rejestry (nawet Amiga 30 lat temu miała
>> 16 rejestrów 32-bitowych, choć nie w pełni ortogonalnych) a Intel robi
>> "wielką rewolucję" że w 64-bitowej maszynie raptem dodaje 8
>> dodatkowych rejestrów do 4 już istniejących (reszta to indeksowe i
>> segmentowe) i tylko dlatego, że AMD to zrobiło wcześniej, więc trzeba
>> było "dogonić" konkurencję :D
>
> Ale zauważyłeś że nowe x86 mają takie ciekawostki jak np. prefetch,
> których w RISC nie ma?

Prefetch to miał nawet MOS6502 (z 1975 roku!) w Commodore C64 (inna
rzecz, że tylko jednego bajtu :D) a co dopiero współczesne RISC!
Chociażby wspomniane procesory Sparc z serii V9 (przykładem jest
SparcUltra) już w 1995 roku miały wszystko o czym wspomniałeś, łącznie
z 9-poziomowym pipeline, prefetchem, przełączanymi ramkami rejestrów i
różnymi innymi "bajerami". Piszę o Sparcach, bo akurat w tamtych
czasach dużo miałem z nimi do czynienia i dużo na nie programowałem
ale tego typu rozwiązania były (i są nadal) w RISC-ach
powszechne. Poczytaj na przykład o najnowszych ARM-ach (czy o
Intelowych XScale - to są praktycznie klony ARM :D) i się zdziwisz ile
fajnych rzeczy może mieć procesor, na przykład wykonanie się każdej
instrukcji może zależeć od ustawienia flag procesora (przykład
algorytmu Euklidesa dla procesora ARM bez użycia odgałęzień i tylko
przy użyciu 4 instrukcji maszynowych możesz znaleźć na Wikipedii razem
z wyjaśnieniem, więc nie będę się szczegółowo rozpisywał :D).
Wiem że Intel ma genialny marketing i potrafi przekonać
niezorientowanych w temacie, że jest pionierem i wszystko ma najlepsze
:D

>>
>> Pipeline? W 1996 roku na studiach programowałem procesor
>> SparcUltra, który (pomijając że w pełni 64-bitowy) wykonywał dwie
>> instrukcje w jednym cyklu zegara i trzeba było uważać jak się pisało
>> programy w assemblerze, bo jak się po CALL _adres nie dało instrukcji
>> NOP, to drugi potok mógł zdążyć wykonać instrukcję za "CALL" zanim się
>> skok wykonał :D
>
> Jeżeli to skutkowało błędami to był to kiepski procesor. W momencie gdy
> pierwszy dekoder rozkazów trafił na instrukcję skoku (ret, jmp, etc.)
> pipeline powinien być blokowany (tzn w niepopsutych rozwiązaniach to
> działa tak, że część drugiej instrukcji się wykona, tak gdzieś do zapisu
> wyniku).

Oj i tu się nie zgodzę, bo to jest błąd programisty a nie procesora,
załóżmy że mamy tego typu program (R1 i R2 to rejestry, znaczenie
instrukcji chyba oczywiste, składnia tzw. AT&T czyli nazwy rejestrów w
programie poprzedzone znakiem %):

call _przykladowa_funkcja
inc %R1
[kolejne instrukcje]

_przykladowa_funkcja:
adc %R2,%R3
ret

I teraz... dlaczego inkrementacja R1 miałaby zostać zmarnowana, skoro
wewnątrz _przykladowa_funkcja rejestr R1 nie jest wykorzystany? Po
powrocie z tej funkcji jesteśmy o jedną instrukcję "do przodu" :D Jak
ktoś nie chce takiego zachowania, to może po call wstawić nop i nie ma
problemu (można też zlecić assemblerowi automatyczne wstawienie nopów
po rozgałęzieniach bądź wyświetlanie ostrzeżeń że tego typu sytuacja może
wystąpić). Projektanci procesora zamiast wstawiać sprzętowe
zatrzymywanie potoku stwierdzili, że wybór czy blokować potok czy nie
można zostawić programiście, bo czasem niezablokowanie potoku może dać
zysk - czy to dobrze czy źle, to już kwestia gustu :D W sumie jeśli już,
to w assemblerze pisze się bardzo małe fragmenty programu (w większości
przypadków nie używa się go w ogóle), a kompilatory języków wyższego
poziomu wygenerują kod assemblerowy, który robi co trzeba :D

>> "Nikt nie widział eax" bo pewnie nikt do środka nie zaglądał :D A tak
>> na serio, to Intele nie są procesorami tzw. hardwired (takie są na
>> przykład ARM-y, AVR-y itd.) tylko mają prosty rdzeń i mikrokodem
>> załatwiają resztę :D W sumie mogliby udostępnić możliwość ładowania
>> własnego mikrokodu, wtedy każdy mógłby stworzyć swój assembler (choć
>> od takich rzeczy, to akurat układy FPGA są lepsze :D).
>
> Jesteś pewien, ze ten mikrokod nie jest przynajmniej częściowo wsadem
> konfiguracyjnym dla bloków FPGA-like wewnątrz procesora? Przy 3GHz
> klasyczny RISC musiałby pracować chyba szybciej niż podłoże krzemowe na
> to pozwala...

No tak się składa, że 4GHz RISC z 32 jednostkami APU powstał w 2005
roku i jest używany w dużych maszynach IBM, a jego okrojona wersja
(3.2GHz i 8APU) znalazła w 2006 roku swoje miejsce w konsolach
PlayStation3 :D Owszem, podłoże krzemowe na to nie pozwala, ale
podłoże z arsenku galu już jak najbardziej (teoretycznie na arsenku
galu można osiągnąć prędkości rzędu setek gigaherców, ale problemem
staje się odprowadzanie ciepła i czas reakcji układów peryferyjnych, w
ciągu jednego cyklu zegara światło zdążyłoby pokonać drogę niecałego
metra :D).

Co do mikrokodu: owszem, można zaktualizować mikrokod w procesorach
Intela, ale takiej aktualizacji nie może sobie napisać każdy (jedna
rzecz to brak dostępnej specyfikacji, a druga, to konieczność
cyfrowego podpisania takiego "wsadu" certyfikatem Intela, bo inaczej
procesor go nie przyjmie - to jest zabezpieczenie aby wirusy nie mogły
uwalić procesora :D).

do góry

Dnia 18.10.2012 Michoo <m...@v...pl> napisał/a:
> On 17.10.2012 22:28, Baranosiu wrote:
>> Z technicznego punktu widzenia rejestr to taka sama pamięć jak RAM czy
>> cache,
>
> Zwłaszcza, że RAM jest pamięcią dynamiczną a cache i rejestry pamięcią
> statyczną(i to też pamięć RAM tak w sumie) więc technicznie to się dość
> mocno różnią. Logicznie to i to jest pamięcią.

Pamięci cache czy RAM są realizowane w różnych technologiach (tak samo
zresztą jak rejestry) ale wszystkie są pamięciami (z punktu widzenia
funkcjonalności, a czy fizycznie to jest kondensator, którego trzeba
"odświeżać" czy zatrzask na tranzystorze, to już tylko kwestia kosztu
produkcji i poboru mocy :D).


>
>> a że nie jest podpięty do szyny adresowej
>
> Której szyny adresowej? Jest ich w komputerze kilka a jak sam zauważyłeś
> rejestry są kawałkiem pamięci - jakoś zaadresować je trzeba.

Miałem na myśli to, że nie mają wspólnej przestrzeni adresowej z RAM-em.

>> ale już na przykład w
>> niektórych procesorach RISC (choćby takie małe Atmegi z rdzeniem AVR)
>> rejestry są jak najbardziej adresowalne.
>
> Bo skoro na pokładzie jest tylko kilka kilo SRAM to umieszczanie tam
> rejestrów jest naturalne. W x86 L1 jest zazwyczaj kilka razy większe a
> pamięć rejestrów niewiele mniejsza od całej pamięci w małym uC.

Chodziło też między innymi o dwie dodatkowe funkcjonalności:
1) DMA może wrzucać dane bezpośrednio do rejestrów procesora.
2) Funkcje biblioteczne mogą działać zarówno na danych w SRAM jak i na
danych w rejestrach (ten sam kod, kwestia podania innego wskaźnika do
danych).

Podałem przykład AVR-a, bo taki mi przyszedł do głowy (akurat pisałem
program na taki mikrokontroler :D), ale wiele procesorów ma tego typu
wynalazki jak "zerowe strony pamięci" czy "adresowalne cache", choć
nie zawsze te obszary mają w 100% identyczną funkcjonalność jak
rejestry, no ale z drugiej strony nawet w x86 nie wszystkich rejestrów
można użyć do wszystkiego (pomijam rejestry tupu program counter czy
stack pointer, bo ich specjalne przeznaczenie jest oczywiste).

>> Takie pierdoły jak "register
>> rename" wynikają z prostego faktu, że nawet tanie mikrokontrolery za
>> 20zł mają 32 ortogonalne rejestry (nawet Amiga 30 lat temu miała
>> 16 rejestrów 32-bitowych, choć nie w pełni ortogonalnych) a Intel robi
>> "wielką rewolucję" że w 64-bitowej maszynie raptem dodaje 8
>> dodatkowych rejestrów do 4 już istniejących (reszta to indeksowe i
>> segmentowe) i tylko dlatego, że AMD to zrobiło wcześniej, więc trzeba
>> było "dogonić" konkurencję :D
>
> Ale zauważyłeś że nowe x86 mają takie ciekawostki jak np. prefetch,
> których w RISC nie ma?

Prefetch to miał nawet MOS6502 (z 1975 roku!) w Commodore C64 (inna
rzecz, że tylko jednego bajtu :D) a co dopiero współczesne RISC!
Chociażby wspomniane procesory Sparc z serii V9 (przykładem jest
SparcUltra) już w 1995 roku miały wszystko o czym wspomniałeś, łącznie
z 9-poziomowym pipeline, prefetchem, przełączanymi ramkami rejestrów i
różnymi innymi "bajerami". Piszę o Sparcach, bo akurat w tamtych
czasach dużo miałem z nimi do czynienia i dużo na nie programowałem
ale tego typu rozwiązania były (i są nadal) w RISC-ach
powszechne. Poczytaj na przykład o najnowszych ARM-ach (czy o
Intelowych XScale - to są praktycznie klony ARM :D) i się zdziwisz ile
fajnych rzeczy może mieć procesor, na przykład wykonanie się każdej
instrukcji może zależeć od ustawienia flag procesora (przykład
algorytmu Euklidesa dla procesora ARM bez użycia odgałęzień i tylko
przy użyciu 4 instrukcji maszynowych możesz znaleźć na Wikipedii razem
z wyjaśnieniem, więc nie będę się szczegółowo rozpisywał :D).
Wiem że Intel ma genialny marketing i potrafi przekonać
niezorientowanych w temacie, że jest pionierem i wszystko ma najlepsze
:D

>>
>> Pipeline? W 1996 roku na studiach programowałem procesor
>> SparcUltra, który (pomijając że w pełni 64-bitowy) wykonywał dwie
>> instrukcje w jednym cyklu zegara i trzeba było uważać jak się pisało
>> programy w assemblerze, bo jak się po CALL _adres nie dało instrukcji
>> NOP, to drugi potok mógł zdążyć wykonać instrukcję za "CALL" zanim się
>> skok wykonał :D
>
> Jeżeli to skutkowało błędami to był to kiepski procesor. W momencie gdy
> pierwszy dekoder rozkazów trafił na instrukcję skoku (ret, jmp, etc.)
> pipeline powinien być blokowany (tzn w niepopsutych rozwiązaniach to
> działa tak, że część drugiej instrukcji się wykona, tak gdzieś do zapisu
> wyniku).

Oj i tu się nie zgodzę, bo to jest błąd programisty a nie procesora,
załóżmy że mamy tego typu program (R1 i R2 to rejestry, znaczenie
instrukcji chyba oczywiste, składnia tzw. AT&T czyli nazwy rejestrów w
programie poprzedzone znakiem %):

call _przykladowa_funkcja
inc %R1
[kolejne instrukcje]

_przykladowa_funkcja:
adc %R2,%R3
ret

I teraz... dlaczego inkrementacja R1 miałaby zostać zmarnowana, skoro
wewnątrz _przykladowa_funkcja rejestr R1 nie jest wykorzystany? Po
powrocie z tej funkcji jesteśmy o jedną instrukcję "do przodu" :D Jak
ktoś nie chce takiego zachowania, to może po call wstawić nop i nie ma
problemu (można też zlecić assemblerowi automatyczne wstawienie nopów
po rozgałęzieniach bądź wyświetlanie ostrzeżeń że tego typu sytuacja może
wystąpić). Projektanci procesora zamiast wstawiać sprzętowe
zatrzymywanie potoku stwierdzili, że wybór czy blokować potok czy nie
można zostawić programiście, bo czasem niezablokowanie potoku może dać
zysk - czy to dobrze czy źle, to już kwestia gustu :D W sumie jeśli już,
to w assemblerze pisze się bardzo małe fragmenty programu (w większości
przypadków nie używa się go w ogóle), a kompilatory języków wyższego
poziomu wygenerują kod assemblerowy, który robi co trzeba :D

>> "Nikt nie widział eax" bo pewnie nikt do środka nie zaglądał :D A tak
>> na serio, to Intele nie są procesorami tzw. hardwired (takie są na
>> przykład ARM-y, AVR-y itd.) tylko mają prosty rdzeń i mikrokodem
>> załatwiają resztę :D W sumie mogliby udostępnić możliwość ładowania
>> własnego mikrokodu, wtedy każdy mógłby stworzyć swój assembler (choć
>> od takich rzeczy, to akurat układy FPGA są lepsze :D).
>
> Jesteś pewien, ze ten mikrokod nie jest przynajmniej częściowo wsadem
> konfiguracyjnym dla bloków FPGA-like wewnątrz procesora? Przy 3GHz
> klasyczny RISC musiałby pracować chyba szybciej niż podłoże krzemowe na
> to pozwala...

No tak się składa, że 4GHz RISC z 32 jednostkami APU powstał w 2005
roku i jest używany w dużych maszynach IBM, a jego okrojona wersja
(3.2GHz i 8APU) znalazła w 2006 roku swoje miejsce w konsolach
PlayStation3 :D Owszem, podłoże krzemowe na to nie pozwala, ale
podłoże z arsenku galu już jak najbardziej (teoretycznie na arsenku
galu można osiągnąć prędkości rzędu setek gigaherców, ale problemem
staje się odprowadzanie ciepła i czas reakcji układów peryferyjnych, w
ciągu jednego cyklu zegara światło zdążyłoby pokonać drogę niecałego
centymetra :D).

Co do mikrokodu: owszem, można zaktualizować mikrokod w procesorach
Intela, ale takiej aktualizacji nie może sobie napisać każdy (jedna
rzecz to brak dostępnej specyfikacji, a druga, to konieczność
cyfrowego podpisania takiego "wsadu" certyfikatem Intela, bo inaczej
procesor go nie przyjmie - to jest zabezpieczenie aby wirusy nie mogły
uwalić procesora :D).

do góry

W dniu 2012-10-19 00:37, Edek Pienkowski pisze:
> Ponurą porą Thu, 18 Oct 2012 22:13:36 +0000, Baranosiu wyszeptał:
>
>> Dnia 18.10.2012 slawek <h...@s...pl> napisał/a:
>>> A Ziemia jest płaska i oparta o cztery forumowe trolle?
>>>
>>> Jeżeli to jest kula (bila) i jeżeli porusza się w naszym Wszechświecie,
>>> ma masę, pęd, moment pędu i ładunek elektryczny (np. równy zero) - to
>>> daruj sobie wmawianie, że składowe wektora prędkości muszą być liczbami
>>> całkowitymi - a nawet jeżeli przez przypadek są (pamiętaj, Heisenberg),
>>> to jeszcze jest czas, który tworzy continuum.
>>>
>>> Pomnóż sobie całkowitą składową prędkości przez niewymierny czas (np. t
>>> = 2 pi) i już jest pozamiatane w sprawie "całkowitych (x,y)".
>>
>> Ale po co skoro można DOKŁADNIE policzyć to (w przestrzeni
>> Newtonowskiej) na liczbach całkowitych? To jest tak, jakby w zadaniu
>> było "policz owce widoczne na obrazku" a ty byś powiedział, że na
>> liczbach całkowitych się nie da, bo nie dość że owce widoczne są tylko z
>> jednej strony, to jeszcze jednej owcy widać tylko 49% a drugiej za to
>> 51%, pozatym być może niektóre są wydrukowane w ultrafiolecie i człowiek
>> nie widzi, ale pszczoła widzi, więc zadanie nie jest jednoznaczne i nie
>> da się go rozwiązać, no i kto widział płaskie (dwuwymiarowe) owce o
>> długości 2.5cm (bo tyle zajmują na kartce), czy w ogóle można je za owce
>> uznać? A skoro już "pamiętaj, Heisenberg" to z tego samego powodu jest
>> prawdopodobieństwo, że do Ciebie dociera inny tekst niż napisał autor
>> (prawdopodobieństwo znikome, ale jednak niezerowe :D).
>
> Chyba za dużo używacie stuffu robionego przez Heisenberga, tak moim
> skromnym zdaniem. Obaj.

Właśnie jestem w połowie 4 sezonu i to chyba niezłe porownanie:)
Ale raczej do pierwszego, Baranosiu się słusznie(tak samo uważam)
nabija.

pzdr
bartekltg

do góry

W dniu 2012-10-18 21:08, Edek Pienkowski pisze:
> Ponurą porą Thu, 18 Oct 2012 15:46:20 +0200, bartekltg wyszeptał:
>
>> W dniu 2012-10-18 13:09, Edek Pienkowski pisze:
>>
>>> Moim zdaniem jednak problem istnieje.
>>>
>>> Nie ma dla mnie znaczenia, czy rozwiązanie było ok czy nie w tym
>>> kontekście. Problem polega na tym, że konkurs jest bardzo zamknięty w
>>> grupie, która lubi takie same zadania i które mają takie same
>>> rozwiązania. A to nigdy nie jest dobre.
>>>
>>>
>> I w ramach tego na finale olimpiady fizycznej dzieciaki będą piec
>> ciasto:-)
>
> Lepiej p..ąć nie mogłeś, zapewniam.
>

Tylko rozwijam Twoją myśl. Po co robic konkurs zamkniety do fizykow;)
pzdr
bartekltg

do góry

Ponurą porą Fri, 19 Oct 2012 03:30:49 +0200, bartekltg wyszeptał:

> Tylko rozwijam Twoją myśl. Po co robic konkurs zamkniety do fizykow

W fizyce wiele rzeczy się robi na właśnie różne sposoby, a nie
wszyscy tą samą bibliotekę czy to samo uproszczenie. Bujającą
się plastikową małpkę da się sprowadzić do bryły sztywnej
lub punktowej masy w pępku...

--
Edek

do góry

Użytkownik "Michoo" napisał w wiadomości grup
dyskusyjnych:k5q2oo$tk0$...@m...internetia.pl...

>Nie, miało być "tak szybko jak się da, ale nie szybciej". Twój algorytm
>jest tak bardzo do przodu, że mu z tyłu trolluje.

I jest. Bo przecież jeżeli wyjdzie ci 1000 razy pod rząd reszka - to /może/
być zupełnie normalne, prawdopodobieństwo tego jest małe (2^-1000), ale
większe od zera.

Jeżeli chcesz, aby generator miał zagwarantowane, że dwie kolejne liczby
muszą być różne... to już nie będzie to losowe, tylko według twojego uznania
(że tak powinno być).

A skoro /nie/ /można/ /wykluczyć/ iż kolejne liczby losowe będą takie jak
pierwsza liczba - to generator jest ok.

Podobnie - jeżeli weźmiesz niezainicjalizowany blok pamięci - coś w nim
będzie - ale co? Gdy zwisa ci jakość generatora - możesz uznać że tam są
liczby losowe. (Ale ja tak nie zakładam.)

Aby się paszczać, że nie mam racji - musiałbyś założyć jakieś kryteria
jakościowe. A tych w ogóle nie masz, uznajesz tylko pogoń za czasem
wykonania. Więc, jak w dowcipie o transatlantyku, wychodzi że możesz wsadzić
sobie jako losowe dowolne liczby (śmieci z pamięci, same zera lub same
13-ki) - i będzie git.

>Liczby naprawdę losowe uzyskasz z generatora sprzętowego. Zazwyczaj

Niestety nie. Ale aby to zrozumieć musiałbyś naprawdę trochę więcej poczytać
i pomyśleć. Między innymi musiałbyś wiedzieć, jak i po co kalibruje się
generatory hardwareowe.

Problem jest głównie ze słowem "naprawdę": zaczynając od definicji "czym
jest prawda" (nie ma zgody na to wśród filozofów), a kwestią istnienia
bogini/boga/bogów omnipotencjalnych (czyli znających wszystkie ciągi losowe
zanim cokolwiek).

A najprostsze, co jest jeszcze w zasięgu twojego IQ, to fakt że generator
liczb losowych może być zepsuty. Wtedy nie daje liczb losowych. A jak
odgadnąć że nie jest zepsuty? Nie da się!

do góry

Użytkownik "Baranosiu" napisał w wiadomości grup
dyskusyjnych:k5puuf$uhl$...@n...task.gda.pl...

>Ale po co skoro można DOKŁADNIE policzyć to (w przestrzeni
>Newtonowskiej) na liczbach całkowitych? To jest tak, jakby w zadaniu

Znasz choćby II zasadę dynamiki? Tam są liczby całkowite, prawda? Pochodna
pędu po czasie to liczy się przez dzielenie dwóch liczb całkowitych... czy
jednak trochę inaczej?

Nie trzeba być super kumatym, aby wiedzieć że real world wymaga real numbers
do opisu niemal każdej zmiennej... z wyjątkiem tych przypadków, gdy są to
liczby zespolone.

>było "policz owce widoczne na obrazku" a ty byś powiedział, że na
>liczbach całkowitych się nie da, bo nie dość że owce widoczne są tylko

Jeżeli coś kwacze, ma skrzydła i ogólnie zachowuje się jak kaczka - to
dlaczego mam to nazywać koniem?

Jeżeli w treści zadania jest bila, jej ruch, lasery (czyli zupełnie
konkretne urządzenia) - to dlaczego mam udawać, że tego tam nie ma?

>sobie brać pod uwagę nieoznaczoność Heisenberga i transformacje
>Lorenza, to oczywiście możesz, ale dopóki zadanie tego nie wymaga
>wprost, to nie musisz i możesz myśleć po Newtonowsku :D

Stała Diraca to jakieś 10^-34. Pierwiastek z niej to 10^17. Dla double
maszynowy epsilon to jakieś 10^-16. Dla double double byłoby odpowiednio
mniej.

Czyli przy porównaniach współrzędnych (a < x && x < b) na doublach ogranicza
epsilon, a na quarduplach będzie to już Heisenberg. Ciekawe samo w sobie.

I masz ciągle problem jak bardzo kula musi musnąć promień: wystarczy 1%
szerokości wiązki? A jak to będzie 10^-18 tej szerokości? To w
patologicznych przypadkach może dawać różne wyniki zliczania przecięć.

do góry