Jaki jest schemat podpisywania cyfrowego dokumentu przez większą ilość
osób/programów?
Nie można tego znależć w Google.

do góry

W dniu 2013-04-14 10:52, Borneq pisze:
> Jaki jest schemat podpisywania cyfrowego dokumentu przez większą ilość
> osób/programów?

Dlaczego nie wystarczy, aby każdy podpisał swoją
kopię, albo aby wszyscy podpisali po kolei -
wtedy pierwszy podpisuje dukument, drugi podpisuje
dokument z podpisem pierwszego...


pzdr
bartekltg

do góry

W dniu niedziela, 14 kwietnia 2013 11:45:10 UTC+2 użytkownik bartekltg napisał:
> Dlaczego nie wystarczy, aby każdy podpisał swoją
> kopię, albo aby wszyscy podpisali po kolei -
> wtedy pierwszy podpisuje dukument, drugi podpisuje
> dokument z podpisem pierwszego...
Jak ktos kiedys znajdzie szybki algorytm rozkladu na czynniki
pierwsze to bedzie jazda :D
Pozdrawiam

do góry

Użytkownik "M.M." <m...@g...com> napisał:

> Jak ktos kiedys znajdzie szybki algorytm rozkladu na czynniki
> pierwsze to bedzie jazda :D

Uj bedzie :) (npo kilku z FSB czy innego CIA czy Mi6) powiesi sie
na wlasncyh paskach ;)

Przypomnialy mi sie czasy przed algorytmem Cooleya-Tukeya i po.

PS: to tak odniosnie |"przewagi" optymalizacji w assemblerze/C/C++
(vide pojeb kenobi) nad "optymalizacja algorytmiczna" :))

AK

do góry

W dniu 2013-04-14 15:46, AK pisze:

> Przypomnialy mi sie czasy przed algorytmem Cooleya-Tukeya i po.

Czyli... czym jedne od drugich czasów się różniły?

pzdr
bartekltg

do góry

Użytkownik "bartekltg" <b...@g...com> napisał:

> Czyli... czym jedne od drugich czasów się różniły?

Przed Cooleyem-Tukeyem roslo wykladniczo, a potem liniowo.

AK

do góry

Użytkownik "AK" <n...@n...com> napisał:

> Przed Cooleyem-Tukeyem roslo wykladniczo, a potem liniowo.

"Znaczy sie" FT oczywiscie.

bylo => stalo sie
FT => FFT

AK

do góry

W dniu niedziela, 14 kwietnia 2013 15:46:38 UTC+2 użytkownik AK napisał:

> PS: to tak odniosnie |"przewagi" optymalizacji w assemblerze/C/C++
> nad "optymalizacja algorytmiczna" :))

Dobre umiejętności implementacyjne też są ważne. Oczywiście jeśli
danych jest dużo, a algorytm ma mniejszą złożoność, to nawet
najlepsza implementacja gorszego algorytmu niewiele pomoże. Jednak
gdy zostały już użyte dobre algorytmy, albo gdy ilość danych jest
malutka, to nie można zmienić nic poza poprawą implementacji. Szkoda, że
umiejętności implementacyjne szybko się dewaluują, co procesor, co
kompilator, to trzeba kombinować od nowa.

W asemblera mnie się już nie chce bawić, ale zawsze chciałem mieć
wyczucie dobrej implementacji w niskopoziomowym C/C++. Kiedyś pisałem
dużo małych procedur i mierzyłem czasy. Niestety zawsze gdy wchodziły
nowe wersje kompilatorów, to moje wyczucie najczęściej można było o
kant rozbić.

Pozdrawiam

do góry

Dnia Sun, 14 Apr 2013 11:57:34 -0700 po głębokim namyśle M.M. rzekł:

> W dniu niedziela, 14 kwietnia 2013 15:46:38 UTC+2 użytkownik AK napisał:
>
>> PS: to tak odniosnie |"przewagi" optymalizacji w assemblerze/C/C++
>> nad "optymalizacja algorytmiczna" :))
>
> Dobre umiejętności implementacyjne też są ważne. Oczywiście jeśli danych
> jest dużo, a algorytm ma mniejszą złożoność, to nawet najlepsza
> implementacja gorszego algorytmu niewiele pomoże. Jednak gdy zostały już
> użyte dobre algorytmy, albo gdy ilość danych jest malutka, to nie można
> zmienić nic poza poprawą implementacji. Szkoda, że umiejętności
> implementacyjne szybko się dewaluują, co procesor, co kompilator, to
> trzeba kombinować od nowa.

Właśnie nie, dobrze napisany w C++ kod będzie odporny na działanie
czasu. Jedynie trzeba założyć jakiś margines fluktuacji.

Dochodzi też margines opłacalności - programista często kosztuje
więcej niż sprzęt (heh, powiedziałem co wiedziałem ;). Poza HPC i
paroma niszami nikomu nie zależy na +-10% jeżeli jest to kosztem
funkcjonalności. Jeszcze jeden wyjątek: kod działający na
milionach maszyn.

> W asemblera mnie się już nie chce bawić, ale zawsze chciałem mieć
> wyczucie dobrej implementacji w niskopoziomowym C/C++. Kiedyś pisałem
> dużo małych procedur i mierzyłem czasy. Niestety zawsze gdy wchodziły
> nowe wersje kompilatorów, to moje wyczucie najczęściej można było o kant
> rozbić.

To jest sztuka. Nie jest sztuką próbować do skutku aż się znajdzie
optymalny przy tych a nie innych opcjach i wersji, tylko napisać tak,
żeby trzymał się w najlepszych 10%.

--
Edek

do góry

W dniu 2013-04-14 16:27, AK pisze:
> Użytkownik "bartekltg" <b...@g...com> napisał:
>
>> Czyli... czym jedne od drugich czasów się różniły?
>
> Przed Cooleyem-Tukeyem roslo wykladniczo, a potem liniowo.


Ale co rosło wykładniczo? Przecież nie liczenie dyskretnej
transformaty fouriera:) Bo ta zaimplementowana przez pijanego
studenta wprost z definicji DFT jest kwadratowa względem
liczby próbek.


Oczywisćei zgadzam się, że przejście do wersji (prawie)
zawsze prawie liniowej (z kwadratowej) dużo daje.

pzdr
bartekltg

do góry