BOINC@Poland

Ahoj Kamraci!

Razem z Goofyx'em udało nam się postawić nową platformę BOINC.
Całość dostępna na stronie http://cpu.goofyxgridathome.net/

Goofyx dba o serwer itp., a ja zajmuję się "deweloperką" aplikacji.
Także nie ma obaw, że coś pierdnie jak to bywało niestety w historii.

Aplikacja testowa dodana.
Aplikacja z dziedziny informatyki/matematyki - najogólniej rzecz ujmując chodzi o złożoność obliczeniową.
Według informacji jakie posiadam za chwilkę powinny pojawić się jakieś zadania testowe.
Dzisiaj wieczorem będzie także drobny update aplikacji do 1.0.5 (obecne zadania mają charakter testowy - będą bardzo krótkie).
Na chwilę obecną jest dodana jedynie aplikacja dla Linux 64-bit - z czasem będą inne platformy.

Więcej informacji o projekcie/aplikacji itp. będzie na stronie cpu.goofyxgridathome.net (pracujemy nad tym).

Zapraszamy do testów  :parrrty: :parrrty:

Mam problem.
Nie programowałem nigdy za dużo w Pythonie i to co umiałem zawsze wystarczało.
Ostatnio dłubię trochę więcej w nim.

Pytanie następujące:
Jak skompilować kod Pythona do wersji wykonywalnej?
Dodatkowa uwaga jest taka, że musi działać skompilowany program także po przeniesieniu na inny system.
Programy konsolowe więc powinno to być proste.
Mogę też na moment ograniczyć się do tylko do Linux'a.

Szukałem w necie.

Cytatimport py_compile
py_compile.compile('YourFileName.py')

Kompiluje mi do pliku PYC ale nie wiem za bradzo co z tego pliku zrobić...

Natomiast:

Cytatpython -m py_compile File1.py File2.py File3.py ...

także coś nie za bardzo daje mi co trzeba...

Jakieś koncepcje?
Czy nie obejdzie się bez przepisania do C? (i tak będę musiał to zrobić ale nie wiem czy na chwilę obecną jest sens)

Ahoj Kamraci!

Poszukuję praktycznie jakiegokolwiek telefonu komórkowego - jednak z ładowarką.

Nie musi mieć oczywiście systemu ani dotykowego wyświetlacza. Być może nawet da radę czarno biały wyświetlacz ;D Jednak jakiś kolor może byłby lepszy ale to do dogadania  :attack:

Najlepiej jednak aby nie służył dodatkowo do samoobrony i bateria trochę trzymała.
Oczywiście przydałoby się aby był sprawny i najlepiej nie miał simlocka (chociaż te drugie to nie taki wielki wymóg - do przemyślenia).

Pokryję koszt wysyłki.
Jeśli ktoś coś posiada proszę o kontakt PM.

Ahoj Kamraci!

Mam pytanie. Będę potrzebował w Orange Pi możliwie precyzyjnej synchronizacji czasu systemowego.

Początkowo chciałem zastosować moduł GPS po USB ale doszedłem do wniosku, że wyniki nie będą wystarczające.

Znalazłem w sieci taki artykuł: https://www.blackmagicboxes.com/?p=581.

Ja nie będę miał co prawda Orange Pi Plus, a Orange Pi PC ale jedno i drugie ma (chyba) takie same GPIO.

Aby GPS nadał się do dobrej synchronizacji czasu musi mieć chyba PPS.

Znalazłem od Chińczyka taki GPS: https://pl.aliexpress.com/item/Free-Shipping-MT-285-MTK-GPS-Module-1-PPS-timing-Second-pulse-compatible-M-87/1985695529.html.

Czy taki GPS będzie dobrze działał na Orange Pi po instalacji według poradnika (pierwszy link)?
Czy wszystko zagra?
Ewentualnie jaki inny GPS z PPS zakupić do Orange Pi (tani)?

Ahoj Kamraci!

Od jakiegoś czasu kombinuję nad czymś w stylu tego wątku: http://www.boincatpoland.org/smf/ciekawostki/a-moze-by-z-tego-zrobic-projekt-boinc-frb.

Sprzęt jaki miałby być wykorzystywany jako tako znam. Problemem jednak jest antena/anteny. Tradycyjne anteny raczej w większości odpadają. Mi potrzebna byłaby bazowa antena pracująca na częstotliwości 1420 MHz + ewentualnie antena dodatkowa pracująca na innej częstotliwości. Antena/anteny kierunkowe.

Rozmawiałem przez chwilę o tym z RK i dostałem podpowiedź, że taką antenę można zbudować samodzielnie (Helix).

W tym temacie chciałbym spytać czy może ktoś z Kamratów zna się na tego typu sprawach?

Chodzi o coś takiego:







Oczywiście proszę się nie przerazić, ponieważ zapewne to co planuję powinno być mniejsze.
Chciałbym aby w najdłuższym wymiarze antena miała mniej niż 1,5 metra.

Jakieś informacje są tutaj: http://www.setileague.org/articles/helix.htm i tutaj: https://en.wikipedia.org/wiki/Helical_antenna lub trochę po polsku tutaj: https://pl.wikipedia.org/wiki/Antena_%C5%9Brubowa.

Można oczywiście coś kupić np. tutaj: http://www.radioastronomysupplies.com/store/p29/1420_MHz._HELICAL_ANTENNA.html - cena jednak dość spora.

RK wspomniał mi, że da się to zrobić ale precyzja wykonania dość istotna.

Jakieś podpowiedzi jak można to dość prosto i solidnie zrobić (oraz tanio)?

Z góry dzięki za pomoc.

PS. Wiem, że jest oprogramowanie umożliwiające teoretyczne sprawdzenie efektywności zaprojektowanych anten? Ktoś może coś wie więcej na ten temat?

Czy GoofyxGrid@Home jest otwarte na możliwość wpięcia jako sub-projekt innej autorskiej aplikacji?
Czy jest to możliwe?

Ahoj Kamraci!

Mam problem z czujką na Linux. Na Windows śmiga ale na Pingwinie nie chce za nic...

lsusb zwraca m.in:

CytatBus 002 Device 013: ID 16c0:05df Van Ooijen Technische Informatica HID device except mice, keyboards, and joysticks

Z tego co wydedukowałem to jest właśnie czujka.

sensors.xml to:

Cytat<sensors>
  <sensor>
    <hardware_id>16c0:05df</hardware_id>
    <revision>257</revision>
    <revision_bcd>1.01</revision_bcd>
    <vendor>obdev.at</vendor>
    <product>DataStore</product>
    <usb_protocol>1</usb_protocol>
    <options>
      <switch_gmsupply>1</switch_gmsupply>
      <txt_line1>1</txt_line1>
      <txt_line2>1</txt_line2>
      <reset_counters>1</reset_counters>
      <switch_buzzer>1</switch_buzzer>
      <switch_backlight>1</switch_backlight>
    </options>
  </sensor>
  <sensor>
    <hardware_id>16c0:05df</hardware_id>
    <revision>513</revision>
    <revision_bcd>2.01</revision_bcd>
    <vendor>obdev.at</vendor>
    <product>radioactiveathome.org GRS</product>
    <usb_protocol>1</usb_protocol>
    <options>
      <switch_gmsupply>1</switch_gmsupply>
      <reset_counters>1</reset_counters>
      <switch_buzzer>1</switch_buzzer>
      <switch_backlight>1</switch_backlight>
    </options>
  </sensor>
  <sensor>
    <hardware_id>16c0:05df</hardware_id>
    <revision>593</revision>
    <revision_bcd>2.51</revision_bcd>
    <vendor>obdev.at</vendor>
    <product>radioactiveathome.org GRS</product>
    <usb_protocol>1</usb_protocol>
    <options>
      <reset_counters>1</reset_counters>
      <switch_buzzer>1</switch_buzzer>
      <switch_backlight>1</switch_backlight>
    </options>
  </sensor>
  <sensor>
    <hardware_id>16c0:05df</hardware_id>
    <revision>594</revision>
    <revision_bcd>2.52</revision_bcd>
    <vendor>obdev.at</vendor>
    <product>radioactiveathome.org GRS</product>
    <usb_protocol>1</usb_protocol>
    <options>
      <reset_counters>1</reset_counters>
      <switch_buzzer>1</switch_buzzer>
      <switch_backlight>1</switch_backlight>
      <buzzer_alert>1</buzzer_alert>
      <lcd_avg_opts>1</lcd_avg_opts>
    </options>
  </sensor>
  <sensor>
    <hardware_id>16c0:05df</hardware_id>
    <revision>595</revision>
    <revision_bcd>2.53</revision_bcd>
    <vendor>obdev.at</vendor>
    <product>radioactiveathome.org GRS</product>
    <usb_protocol>1</usb_protocol>
    <options>
      <reset_counters>1</reset_counters>
      <switch_buzzer>1</switch_buzzer>
      <switch_backlight>1</switch_backlight>
      <buzzer_alert>1</buzzer_alert>
    </options>
  </sensor>
  <sensor>
    <comment>3.01</comment>
    <hardware_id>04d8:f6fe</hardware_id>
    <revision>769</revision>
    <revision_bcd>3.01</revision_bcd>
    <vendor>microchip</vendor>
    <product>radioactiveathome.org GRS</product>
    <usb_protocol>1</usb_protocol>
    <options>
      <switch_gmsupply>1</switch_gmsupply>
      <reset_counters>1</reset_counters>
      <switch_buzzer>1</switch_buzzer>
      <switch_backlight>1</switch_backlight>
    </options>
  </sensor>
  <sensor>
    <comment>2.60</comment>
    <hardware_id>16c0:05df</hardware_id>
    <revision>608</revision>
    <revision_bcd>2.60</revision_bcd>
    <vendor>radioactiveathome.org</vendor>
    <product>Radiation Detector KIT</product>
    <usb_protocol>1</usb_protocol>
    <options>
      <switch_gmsupply>1</switch_gmsupply>
      <reset_counters>1</reset_counters>
      <switch_buzzer>1</switch_buzzer>
      <switch_backlight>1</switch_backlight>
    </options>
  </sensor>
</sensors>

W stderr mam natomiast:

CytatRadac $Rev: 585 $ starting...
Warning: cannot query manufacturer for device: error sending control message: Operation not permitted
Warning: cannot query manufacturer for device: error sending control message: Operation not permitted
Warning: cannot query manufacturer for device: error sending control message: Operation not permitted
Warning: cannot query manufacturer for device: error sending control message: Operation not permitted
Warning: cannot query manufacturer for device: error sending control message: Operation not permitted
Warning: cannot query manufacturer for device: error sending control message: Operation not permitted
Could not find any of the devices listed in sensors.xml: Device communication error
Warning: cannot query manufacturer for device: error sending control message: Operation not permitted
Warning: cannot query manufacturer for device: error sending control message: Operation not permitted
Warning: cannot query manufacturer for device: error sending control message: Operation not permitted
Warning: cannot query manufacturer for device: error sending control message: Operation not permitted
Warning: cannot query manufacturer for device: error sending control message: Operation not permitted
Warning: cannot query manufacturer for device: error sending control message: Operation not permitted

Kombinowałem (odpalałem z uprawnieniami sudo i normalnie) ale nic z tego nie wyszło.
Co może być nie tak?

Mam na zbyciu teoretycznie dwie czujki Radioactive@Home. Tej samej generacji co sprzedawał Cyfron -> http://www.boincatpoland.org/smf/gielda/%28sprzedam%29-czujka-do-radioactivehome/.

Nudzą się a mogłyby coś "pomielić" na poczet teamu  :attack:

Jedna z nich nie działa z tego co pamiętam na Linux'ie, ponieważ to jakaś bardzo wczesna wersja była i soft pod Linuxa nie jest dostosowany.
Druga powinna działać na Linux OK.

W każdym bądź razie na obydwu po podłączaniu wyświetlają się prawidłowe wartości pomiarów.

Obie nie mają obudowy. Do jednej dokładam kabel (dość długi, nie stockowy) - chyba był kiedyś od skanera, ale oczywiście pod USB i działa. Może uda mi się znaleźć drugi ale tego nie gwarantuję.

Co do ceny to myślę jest do dogadania. Możliwa opcja częściowego/całkowitego barteru za jakieś pamiątki DDR3 (ale tylko jedną kość - jeśli ktoś ma na zbyciu) i/lub coś innego.

Najchętniej obie bym wysłał do jednej osoby ale to jest też do dogadania.

Gdyby ktoś był chętny to myślę najlepiej pisać na PW.

Mam problem z (być może) kartą graficzną. Nie jest to jakiś stockowy problem bo czasem potrafię 5 godzin przegrać bez przerwy i nie pojawi się ani jeden błąd, a czasem błędy witają mnie od razu po odpaleniu gry.

Błędy wyglądają następująco:





Tutaj szczególnie widoczne:





Screen bez błędów:



Należy podkreślić, że zawsze błędy nie występują cały czas (raczej sporadycznie). Wystarczy, że np. spojrzę na obiekt z minimalnie innej perspektywy i już wszystko jest ok.

Czy to wina sprzętu? Padł mi wcześniej 9800GX2 ale w jego przypadku pionowe pasy miałem zawsze - nawet w BIOS'ie.
Tutaj natomiast jakaś zgwostka jest to dla mnie...

Mam problem.

Posiadam kartę graficzną Radeon HD 6950. Wspiera ona Eyefinity.

Problem polega na tym, że chcę podłączyć trzy monitory przez D-Sub.

Karta ma: 1x DVI-I, 1x DVI-D, 1x HDMI, 1x DisplayPort.

Aktualnie mam jeden monitor podłączony przejściówką na D-Sub z DVI-I. Cały problem kryje się w tym jak najtaniej i najlepiej podłączyć pozostałe dwa monitory D-Sub?

Wszędzie w Internecie znalazłem, że do Eyefinity poleca się podłączyć za pomocą 2x DVI + DisplayPort. Mógłbym tak zrobić ale moja karta drugi port DVI ma w wersji DVI-D, a niestety nie znalazłem w necie przejściówki DVI-D -> D-Sub.

Pytanie jest więc takie: Czy mogę podłączyć trzy monitory w Eyefinity za pomocą: DVI-I + HDMI + DisplayPort? (oczywiście wykorzystując wszędzie odpowiednie przejściówki na D-Sub)

Kamraci!  :attack:

Czy któryś z Kamratów zna i ma dobre układy z jakimś astrofizykiem, astronomem lub ewentualnie fizykiem. Fizyk w ostateczności, bo sam znam kilku jednak za wiele nie mogli mi pomóc :wth:

Mam drobne pytanie. W zasadzie to ktoś już mi udzielił odpowiedzi ale zbyt wiele z niej nie rozumiem i potrzebuję wyjaśnienia  :attack:

Będę wdzięczny za pomoc  :attack:

Ahoj Kamraci!

Mam problem. Otrzymałem od Szoplera kartę graficzną GeForce 210 (dzięki!).
Niestety stara grafika mi praktycznie padła - był to GeForce 9800GX2.

Gram w AION'a i mam problem na tym GeForce 210.

Wcześniej na GeForce 9800GX2 miałem powalającą grafikę i płynność na Ultra detalach. Później na zintegrowanej na płycie (sprawdzałem zanim otrzymałem GeForce 210) miałem na standardowych ustawieniach 8-12 FPS.

Teraz na tym GeForce jest co prawda znacznie lepiej niż na grafice zintegrowanej na płycie. Osiągam aktualnie do nawet 36 FPS ale niestety są spadki czasem do ponad 10 FPS.

Nie to (wydajność) jest jednak głównym problemem wątku.

Problem w tym, że system nie daje rady czasem odpowiednio szybko nakładać mi tekstur na obiekty! Muszę jakiś czas odczekać zanim pojawią się na obiekcie tekstury i do tego czasu są one jednolicie szare lub co gorsze obiektów nie widać wcale. Czasem może to trwać nawet i kilka sekund...

Domyślam się, że może być to spowodowane technologią TurboCache.

W sieci wyczytałem, że TurboCache to technologia umożliwiające rozszerzenie pamięci karty graficznej o pewne zasoby pamięci RAM. Według Wikipedii, karta graficzna posiada wbudowaną jakąś minimalną ilość pamięci, a resztę wykorzystuje z RAM'u. Myślałem, że TurboCache wykorzystuje całość z RAM'u ale widać się myliłem  :attack:

Pytanie jest takie: Ile pamięci wbudowanej ma faktycznie standardowo GeForce 210? Na karcie nie ma żadnych informacji... W nazwie o ile dobrze pamiętam obok liczby 512 (tyle pamięci przez TurboCache może zaalokować) widnieje liczba 32. Więc może ona ma 32 MB wbudowanej pamięci?

Kolejne pytanie tyczy się samej istoty wydajności działania TurboCache. Aktualnie nie planuję nowej karty graficznej (brak kasy - niestety). Czy dodając do swojej konfiguracji kolejne 4 GB pamięci DDR3 dzięki czemu pamięć RAM będzie działała już dwukanałowo, karta graficzna z TurboCache (ten GeForce 210) będzie także korzystała dwukanałowo z tej pamięci RAM?

Może pamięci mógłbym jeszcze dołożyć. Pytanie tylko czy w jakimś stopniu wyeliminuje mi to problem czasem wolno ładujących się tekstur?

Przyjmę jakąś kartę graficzną. Niekoniecznie nawet musi mieć wsparcia dla DX10 ani CUDA/OpenCL.
Koniecznie jednak PCI-E.
Coś albo od AMD/ATI albo od nVidii (aby nie było problemów z kompatybilnością).

Gdyby u któregoś z Kamratów coś takiego kurzyło  się w szafce to byłbym wdzięczny.
Ewentualnie kontakt na PW.

Pozdrawiam

Witam serdecznie,

Przyjmę praktycznie jakikolwiek (tylko działający) telefon z Java MIDP 2.0. Dobrze byłoby gdyby telefon nie miał SIM-locka lub miał tylko na Orange.

Proszę o kontakt za pomocą PW.

PS. Do telefonu przydałaby się pewnie też ładowarka.

Mam pewien nietypowy problem.

Posiadam w formacie MS Excela dokument. Jest to arkusz, w którym są makra generujące plik tekstowy w formacie jakim mi łyka program w C.

Cały zonk polega na tym, że to generowanie nie działa mi na Libre Office, a tylko taki posiadam (Linux).

Może ktoś posiada MS Excel i mógłby mi wygenerować ten pliczek?

Kolejna prośba jest następująca: W arkuszu tym makra działają mi na 256 kolumnach i 256 wierszach - tyle też pól (256x256) mam uzupełnionych (pola te reprezentują wagi w grafie). Przydałoby się zwiększyć ilość wykorzystywanych pól np. do 2048x2048 lub nawet 4096x4096 i z tego wygenerować plik tekstowy. Nie wiem czy w pliku trzeba coś zmieniać (w makrach) czy wystarczy zwyczajnie "przeciągnąć" i dodać więcej pól.

Podobno już przy 256x256 potrafi przy generowaniu przyciąć więc nie wiem jak by to działało dla 4096x4096 i czy to do wykonania w Excelu.

Jest moźe ktoś posiadający w najbliższym czasie chwilę z odpowiednim oprogramowaniem?

Tak jak w temacie poszukuję komputerów z procesorem Intel Ivy Bridge lub Haswell działających pod kontrolą systemu operacyjnego Linux.

Nie chodzi nawet o dostęp zdalny. Wystarczy za pomocą GCC skompilować odpalić kilka programików (myślę, że będą 2).

Programy mają:
1. Wygenerować ciągi liczb losowych za pomocą odpowiednich funkcji wbudowanych w dany typ procesora (dlatego wymagane włącznie z Ivy Bridge w górę) wykorzystujących zjawisko szumu termicznego.
2. Sprawdzić wydajność generowania liczb losowych (także wielowątkowo).

Wygenerowany plik (myślę jakieś 1 GB) trzeba będzie mi przesłać.

Potrzebuję możliwie bogatej gamy procesorów więc jeżeli ktoś chce to może się zgłosić i pomóc  :attack:

Programów jeszcze nie napisałem więc nie ma napinki czasowej. Myślę, że nawet jeżeli ktoś planuje w najbliższych miesiącach wymianę procesora/komputera to się załapie bo jest sporo czasu.

Mam problem z kompilacją wstawki asemblerowej w kodzie C.

Wziąłem program ze strony: http://users.tmok.com/~pla/Lychrel/196xampl_vs.zip

Oczywiście nie chciał chodzić na Linuxie z kilku względów.

Musiałem zmienić składnię asemblera z Intelowskiej na AT&T (przepisałem tych 300 linijek).

Mam jednak coś takiego:

int faa8x64a(void *dat1, void *dat2, int leng)
{
    const unsigned long long int C0x0000000000000001 = 0x0000000000000001;
    const unsigned long long int C0x0000000100000000 = 0x0000000100000000;
    const unsigned long long int C0x0606060606060606 = 0x0606060606060606;
    const unsigned long long int C0x0F0F0F0F0F0F0F0F = 0x0F0F0F0F0F0F0F0F;
    const unsigned long long int C0x76F6F6F676F6F6F6 = 0x76F6F6F676F6F6F6;
    const unsigned long long int C0x7FFFFFFF7FFFFFFF = 0x7FFFFFFF7FFFFFFF;
    unsigned long long int flag = 0xFFFFFFFFFFFFFFFF;

    asm("mov    $leng,  %edx");
    asm("mov    ($dat1),  %edi");
    asm("mov    %edx,     %esi");
    asm("add    %edi,     %edx");
    asm("add    %edi,     %esi");
    asm("sub    $32,      %edx");
    asm("mov    ($dat2),  %ebx");
    asm("mov    $0,       %eax");
    asm("pxor   %mm7,     %mm7");
    asm("nop");
    asm("nop");
    asm("nop");

// start outer loop
asm("faa0:");
            // try to pre-cache the data for the next loop iteration
        asm("mov    -48(%edx), %eax");
        asm("mov    48(%edi),  %eax");

            // load next reversed section
        asm("mov    24(%edx), %eax");
        asm("mov    28(%edx), %ecx");
        asm("bswap  %eax");
        asm("bswap  %ecx");
        asm("movd   %eax,   %mm1");
        asm("movd   %ecx,   %mm0");
        asm("mov    16(%edx), %eax");
        asm("mov    20(%edx), %ecx");
        asm("bswap  %eax");
...


Całość wywala się na linkowaniu... System zwraca mi błędy:

Cytat/tmp/cckXS6V6.o: In function `faa8x64a(void*, void*, int)':
engine6.cpp:(.text+0x69): undefined reference to `leng'
engine6.cpp:(.text+0x6f): undefined reference to `$dat1'
engine6.cpp:(.text+0x7e): undefined reference to `$dat2'
...

Jak prawidłowo odnosić się do zmiennych z C w tym Asemblerze?

Próbowałem na różne sposoby np. tak:

asm("mov    $leng,  %edx");

asm("mov    leng,  %edx");

asm("mov    ($leng),  %edx");

asm("mov    (leng),  %edx");

i zawsze mam ten sam błąd z linkowaniem. Jak zrobić to prawidłowo?

Piszę aplikację na socketach w C.

Czy jako klient mogę się jakoś podszyć i zmienić swoje IP tak ze serwer wykryje (i w zapisywanych logach) będzie miał inne IP niż to faktyczne?

Chodzi mi o to czy to wystarczające zabezpieczenie sprawdzać czy ktoś łączy się z odpowiedniego adresu IP i wtedy autoryzować takie połączenie, czy jednak istnieje możliwość aby to obejść.

Propozycja harmonogramu notowań jednolitych na BOINC Stock Exchange:

Cytat0:00 - 1:00 - faza przed otwarciem (przyjmowanie zleceń na otwarcie)

1:00 - otwarcie (określenie kursu jednolitego)
1:00 - 1:30 - dogrywka
1:30 - 7:00 - faza przed otwarciem (przyjmowanie zleceń na otwarcie)

7:00 - otwarcie (określenie kursu jednolitego)
7:00 - 7:30 - dogrywka
7:30 - 12:00 - faza przed otwarciem (przyjmowanie zleceń na otwarcie)

12:00 - otwarcie (określenie kursu jednolitego)
12:00 - 12:30 - dogrywka
12:30 - 16:00 - faza przed otwarciem (przyjmowanie zleceń na otwarcie)

16:00 - otwarcie (określenie kursu jednolitego)
16:00 - 16:30 - dogrywka
16:30 - 21:00 - faza przed otwarciem (przyjmowanie zleceń na otwarcie)

21:00 - otwarcie (określenie kursu jednolitego)
21:00 - 21:30 - dogrywka
21:30 - 24:00 - faza przed otwarciem (przyjmowanie zleceń na otwarcie następnej sesji)

Wszystkie godziny podane w strefie czasowej UTC.

Faza - przed otwarciem
Przyjmowanie zleceń od inwestorów i wprowadzanie bezpośrednio do systemu giełdowego (Centralny arkusz zleceń). Transakcje nie są zawierane. Wraz z wprowadzeniem każdego nowego zlecenia kalkulowany jest teoretyczny kurs otwarcia podawany do publicznej wiadomości.
Można składać zlecenia: PCRO, PKC, LIMIT.

Wyznaczenie kursu jednolitego (pierwszy fixing) - godz. 1:00
W oparciu o przyjęte wcześniej zlecenia zostaje wyznaczony kurs po jakim dojdzie do zawarcia transakcji. Kursem tym jest ostatni znany teoretyczny kurs otwarcia z fazy przed otwarciem. Dla każdego papieru wartościowego i instrumentu finansowego wyznaczany jest osobny kurs.

Faza - dogrywka
Wszyscy mogą składać zlecenia po wyznaczonym na fixingu kursie (LIMIT). Transakcje zawierane są na bieżąco, ale po jednakowej cenie (kursie).


-----------------------------------
W tekście przewinęły się typy zleceń PCRO, PKC:

Zlecenie PKC – zlecenie po każdej cenie, jest to zlecenie do natychmiastowego wykonania.

Zlecenie PKC jest szczególnym rodzajem zleceń na GPW, ma ono pierwszeństwo przed innymi zleceniami, zostaje zrealizowane w całości, natychmiast po wprowadzeniu do systemu. Inwestor składający tego typu zlecenie godzi się na każdy kurs po jakim może być ono zawarte, ważna jest dla niego jedynie całkowita realizacja zlecenia.

Zlecenia PKC mogą być składane podczas każdej fazy sesji giełdowej, poza dogrywką.

Zlecenie PCR – zlecenie giełdowe ,,po cenie rynkowej". Jest to jeden z rodzajów zleceń używanych na Giełdzie Papierów Wartościowych.



-----------------------------------
Teraz o tym jak jest wyznaczany kurs.

W idealnym przypadku centralny arkusz zleceń może wyglądać następująco:

CytatLiczba akcji
Cena  Kupno  Zgłoszona  Skumulowana  Sprzedaż  Zgłoszona  Skumulowana
PKC                1000          1000                                                                         
110                1500           2500                           2500           6000               
105                1000           3500                           2000           3500               
100                500             4000                           1000           1500               
PKC                                                                    500             500     

W przedstawionym przypadku spełnienie warunków maksymalizacji obrotu i maksymalizacji zrealizowanych zleceń, a także zachowania stabilności kursu będzie możliwe, jeżeli kurs ustali się na poziomie 105 PLN. Właściciela zmieni wówczas 3500 akcji (1000 + 1500 + 1000 po stronie popytu i 500 + 1000 + 2000 po stronie podaży), a osiągnięte obroty wyniosą 7000 x 105 PLN = 735000 PLN. Wartość 7000 to 3500 zrealizowanych zleceń kupna i 3500 zrealizowanych zleceń sprzedaży, natomiast 105 to ustalony podczas sesji kurs akcji.

W powyższym przykładzie zaistniała sytuacja idealna, w której nie wystąpiła różnica pomiędzy zrealizowanymi zleceniami kupna i sprzedaży.

Weźmy jednak nieco mniej komfortowy przykład:

Giełda jest rynkiem, na którym sytuacja nierównowagi rynkowej jest czymś prawie naturalnym. Do nadwyżek popytu lup podaży dochodzi na niej zdecydowanie częściej niż na innych rynkach. Jest to szczególnie widoczne w systemie notowań ciągłych, gdzie ceny ulegają niejednokrotnie znacznym wahaniom nawet w trakcie jednej sesji.

W systemie kursu jednolitego na GPW przyjęte zostało rozwiązanie polegające na redukcji zleceń w stopniu pozwalającym na zachowanie skoku kursu akcji w granicach określonych przez wyznaczone widełki cenowe. Ustalanie kursu w tym przypadku rozpoczyna się tak samo jak na rynku zrównoważonym, jednak zlecenia sprzed sesji oraz napływające w trakcie sesji mogą spowodować brak równowagi na rynku.
Poniżej znajduje się przykład rynku niezrównoważonego akcji z kursem odniesienia 100 PLN.

CytatLiczba akcji
Cena     Kupno     Zgłoszona    Skumulowana             Sprzedaż    Zgłoszona    Skumulowana
PKC                       3000             3000                                                                             
115                       2500             5500                                       500                  4500
110                       1500             7000                                       1000                 4000
105                       1000             8000                                       1500                 3000
100                                                                                        1000                 1500
PKC                                                                                        500                   500 

Kurs w tym przypadku ustalony zostanie na poziomie 110 PLN, czyli górnej granicy widełek, chociaż maksymalny obrót i realizacja zleceń byłyby osiągnięte po kursie 115 PLN (kurs wymagałby jednak oprócz redukcji zleceń z limitem, także redukcji zleceń PKC).

Na poziomie 110 PLN zgłoszone zapotrzebowanie na akcje wynosi 7000, natomiast podaż akcji to 4000. Występuje więc nadwyżka popytu w ilości 3000 akcji. Stopa satysfakcji wyniesie więc

(4000 / 7000) x 100% = 57%,

ponieważ taką część zleceń kupna można zrealizować.

W przypadku bardzo dużej nierównowagi, przekraczającej relację 5:1 (czyli przy stopie satysfakcji poniżej 20%) obrót walorami zostaje zawieszony do następnej sesji, a do czasu jej rozpoczęcia ustalony zostaje na podstawie dotychczasowych zleceń kurs nietransakcyjny na granicy widełek, który będzie kursem odniesienia dla następnej sesji. Poniższy przykład oparty na walorze z kursem odniesienia 100 PLN ma na celu ukazanie sytuacji, w której dochodzi do zawieszenia transakcji.

CytatLiczba akcji
Cena        Kupno       Zgłoszona        Skumulowana       Sprzedaż       Zgłoszona        Skumulowana
PKC                           30000               30000                                                                             
110                            25000               55000                                    500                   4500
105                            15000               70000                                    1000                 4000
100                            10000               80000                                    1500                 3000
95                                                                                                 1000                 1500
PKC                                                                                               500                   500 

W powyższym przykładzie maksymalny wolumen obrotu osiągnięty zostanie na poziomie 110 PLN, czyli górnej granicy widełek (możliwa jest wtedy realizacja zleceń na kupno i sprzedaż 4500 akcji). Stopa satysfakcji wyniesie jednak

(4500 / 55000) x 100% = 8%.

Z uwagi na stopę satysfakcji niższą niż 20% nie dojdzie do transakcji, a kurs 110 PLN będzie kursem odniesienia dla następnej sesji.

Opracowanie na podstawie stron:
http://bossa.pl/edukacja/rynek/kurs/fazy/
http://eekonomia.blox.pl/2008/06/Sciaga-Algorytm-ustalania-kursu-jednolitego-na-1.html
http://pl.wikipedia.org/wiki/Gie%C5%82da_Papier%C3%B3w_Warto%C5%9Bciowych_w_Warszawie


Teraz moje pytanie: Co ma na celu wprowadzenie obliczania i uwzględniania przy opcji zawieszania sesji stopy satysfakcji? Przecież z tego co rozumiem może to zawiesić wszystkie transakcje w sesji... i do tego może dziać się tak wielokrotnie sesja po sesji...

Dodatkowo jeden użytkownik może zachwiać notowaniami danego projektu jeżeli nie wprowadzi się jakichś odgórnych limitów na maksymalną wielkość zleceń i ich ilość dla jednej sesji.

Kolejnym problemem na jaki wpadłem odnośnie BOINC Stock Exchange jest czas (godziny) w jakim ta giełda powinna być otwarta.

Sesje mogą być ustalone na czas Europejski ale wtedy nie będzie pasować Amerykanom, albo w na czas Amerykański ale wtedy nie będzie pasować Europejczykom. Co z tym zrobić?

Cały czas skłaniam się ku notowaniom jednolitym, które są stosowane dla instrumentów o niskiej i średniej płynności. W tych notowaniach mamy ustalone o określonej godzinie sesje podczas których po jakimś kursie są zawierane transakcje. Tylko właśnie problem w ustaleniu tych godzin... Skoro system ma być międzynarodowy to może co np. 6 godzin - 4 sesje w dzień (0, 6, 12, 18, 24) ? Ale czy takie podejście (24/24) nie obniży atrakcyjności giełdy - mogą pojawić się ludzie, którzy będą chcieli obserwować giełdę podczas całego czasu jej działania, a to im takie obserwowanie uniemożliwi.

Ponieważ pomimo wszędobylskiej krytyki postanowiłem przejść do realizacji giełdy BOINC chciałbym Was spytać jaką domenę polecilibyście dla BOINC Stock Exchange?

Czy może:

http://boinc-stock.com

Czy może ma ktoś jakieś inne pomysły?

Niestety bse.com zajęte. Wymagane jest raczej aby to była domena com.

Beal@Home

http://www.bealathome.com/

Czy mamy Kamratów gotowych do testów nowego polskiego projektu BOINC?

Są tutaj takowi?

Wymagany system operacyjny Linux x86_64.

Witam serdecznie;

Czy ktoś mógłby pomóc w instalacji certyfikatu SSL na serwerze Apache na Linuxie?

Certyfikat SSL wykupię.

Dostałem informację, że OProject@Home może zostać zaprezentowany na Mobile World Congress ale wymogiem jest posiadanie SSL.

Sam mam aktualnie urwanie głowy i byłbym wdzięczny gdyby ktoś mógł udzielić mi wsparcia.

Pozdrawiam

Witam serdecznie;

Mam problem. Pod adresem : http://static.springer.com/sgw/documents/1124637/application/zip/CSProceedings_AuthorTools_Word_2003.zip znajduje się archiwum. Jest w nim spakowany plik svlnproc1104.dot.

Ja u siebie posiadam Office Starter 2010 i OpenOffice i nie mogę otworzyć tego pliku. Czy mógłby ktoś przekonwertować mi jego do jakiegoś *.doc lub *.odt?

Z góry dzięki za pomoc.

Witam serdecznie;

Czy mamy na pokładzie jakiegoś kamrata, który mógłby pomóc z tłumaczeniem na język angielski?  :attack:

Jeżeli ktoś ma taką możliwość to proszę o przetestowanie programu, który można znaleźć pod adresem:

http://atom.oproject.info/noaa/shark_engine

Jest on skompilowany pod Linux 64-bit.

Dodatkowo w katalogu gdzie będzie odpalany program należy umieścić plik input.bin.

http://atom.oproject.info/noaa/input.bin

Proszę o zwrócenie czasu wykonywania (wartości zwrócone przez "time") oraz napisanie na jakim procesorze było testowane.

PS. Program na Atomie wykonuje się ok. 30 minut więc nie będzie to jakoś strasznie długo.

Drodzy liczydłowi!

Chciałbym publicznie poruszyć temat możliwości otwarcia Giełdy kredytów BOINC (BOINC Stock Exchange). Z powodu chęci zapoczątkowania publicznej debaty na ten temat postanowiłem stworzyć wątek na tym forum. Giełda kredytów BOINC działałaby na tej samej zasadzie co zwykła giełda z tą różnicą, że obracałoby się tam kredytami BOINC. Każdy więc mógłby sprzedać lub kupić kredyty wybranego projektu po ustalonym przez prawa giełdy kursie.

Temat jest dość kontrowersyjny jednak liczę owocną wymianę poglądów.

Temat koncepcji Giełdy BOINC jest bardzo szeroki i nie sposób zmieścić jego w jedynym poście. Mam jednak nadzieję, że szesnaście poniższych pytań oraz odpowiedzi na nie mogą nieco przybliżyć pomysł. Punkty te zawierają wiele koncepcji (czasem wzajemnie się wykluczających). Nie należy rozumieć ich jako jedną spójną wizję Giełdy BOINC - stanowią raczej różne przykłady problemów i możliwe próby ich rozwiązania.



1. Czy to nie zabija idei BOINC?

Na początku można pomyśleć, że tak. Jednak może okazać się, że dużo nowych osób mogłoby zacząć liczyć co byłoby plusem dla projektów i całego BOINC. To, że wyniki swojej pracy użytkownicy będą mogli sprzedać nie jest chyba niczym złym. Mało tego ci co teraz liczą np.: 8h/dobę będą chętniej liczyć całą dobę bo dzięki sprzedaży punktów będą mieli na rachunki.

Moc obliczeniowa BOINC mogłaby drastycznie podskoczyć.

Wystarczy spojrzeć na Bitcoin. Ludzie liczą jakieś "puste" hashowania. Giełda BOINC oferowałaby nam znacznie więcej. Co najważniejsze mielibyśmy do wyboru wsparcie projektu o wartości naukowej. Nie powinno być problemu z zaakceptowaniem nierówności: Bitcoin < Giełda BOINC.



2. Skąd biorą się tutaj realne pieniądze?

Otóż możemy sobie wyobrazić, że pewnego pięknego kwietniowego dnia sprzedaliśmy 10 milionów kredytów w Enigma@Home za 1 000 dolarów (taki był aktualny kurs). Tego samego dnia kupujemy za to 20 milionów kredytów SETI@Home (SETI miało bardzo słaby kurs tego dnia i myśląc, że nadejdzie hossa kupujemy kredyty tego projektu). Następnego dnia Anderson pisze, że w ciągu tygodnia mają zabrać im dostęp do teleskopu z którego pochodzą dane do projektu dlatego najprawdopodobniej w najbliższym czasie zostanie on zamknięty. Coraz więcej osób chce zebrać jak największą ilość kredytów przed zamknięciem projektu dlatego przestawiają swoje CPU/GPU na SETI@Home aby wyciągnąć ile tylko się da. Kurs kredytów w SETI@Home gwałtownie zmienia się (zmienia się ilość chętnych do kupna/sprzedaży kredytów SETI) i przyjmijmy, że wzrasta x2 w porównaniu do kursu gdy kupiliśmy w tym projekcie kredyty. Wtedy sprzedajemy je i otrzymujemy za nie 2 000 dolarów (2x więcej niż 1 000 dolarów za które kupiliśmy kredyty). Teraz kupujemy 10 milion kredytów w projekcie Enigma@Home za 1 000 dolarów (ponieważ kurs w tym projekcie nie zmienił się) i pozostaje nam 1 000 dolarów zarobione na czysto.



3. Kto mógłby na Giełdzie BOINC zarobić?

Na Giełdzie BOINC mógłby zarobić każdy. Należy jednak pamiętać, że każdy też mógłby stracić pieniądze. Z prowizji jakie pobierałaby platforma można byłoby wspierać projekty i różne inicjatywy BOINC na całym świecie.

Przykładowo można zaproponować, że pewien procent z obrotu kredytami danego projektu będzie trafiał do administratorów tego projektu na jego rozwój itp.



4. Jak wyglądałyby wpłaty/wypłaty pieniędzy do Giełdy BOINC?

Wpłaty/wypłaty można zrobić to tak jak np. w kasynach online. Użytkownik wpłaca depozyt, którego wartość jest dostępna w systemie. Potem na tych przelanych pieniądzach użytkownik może wykonywać operacje (kupować za nie akcje wybranych projektów). Jeżeli np. sprzeda określone akcje i jego depozyt się zwiększy to może wypłacić pieniądze.



5. Czy do giełdy będą mogły dołączyć wszystkie projekty?

Nie. Do giełdy mogłyby dołączyć jedynie najlepsze projekty, które posiadają odpowiedni support, istnieją odpowiednio długo i posiadają określoną inflację.

Może wydawać się, że to pewna dyskryminacja ale jest to raczej zabezpieczeniem. Do giełdy nie mógłby przystąpić każdy nowo utworzony projekt BOINC (przecież każdy może projekt założyć). Podstawą w tym przypadku jest zaufanie - w grę przecież wchodziłyby już nie tylko kredyty ale także pieniądze.



6. Czy giełda byłaby czynna 24h na dobę i czy każdego dnia mógłbym zakupić lub sprzedać kredyty?

Nie. Giełda BOINC tak jak prawdziwa giełda działałaby w ustalonych godzinach i w dni robocze. Regularne przerwy w działaniu umożliwiłyby bezproblemową m. in. konserwację i modernizację platformy.



7. Co z wyścigami BOINC? Przecież nie można z nich zrezygnować!

Ruch kredytów między użytkownikami na Giełdzie BOINC uniemożliwiałby rywalizację za pomocą wyścigów. Przecież użytkownik X mógłby w czasie trwania wyścigu kupić określoną ilość kredytów i wyprzedzić innego użytkownika Y, który kredyty liczyłby samodzielnie. Nie taka jest jednak idea wyścigów - w wyścigu największe emocje budzi ciągłe dokładanie do "pieca" i rywalizacja na aktualne moce obliczeniowe.

Wyścigi za to mogłyby funkcjonować całkowicie normalnie w okresie gdy Giełda byłaby zamknięta (soboty, niedziele, święta).


8. Co z inflacją i sprawiedliwością naliczania kredytów?

Tak jak już wcześniej zaznaczono nie ma co ukrywać ale nie wszystkie projekty będą mogły dołączyć do takiej giełdy BOINC. Projekt aby wejść na giełdę musiałby spełniać określone wymagania co do inflacji.

Łatwo można policzyć inflację roczną projektów dysponując danymi z BOINCStats (total creditem i ilością kredytów wyrobionych w danym dniu). Można zauważyć, że World Community Grid będzie miał inflację roczną na poziomie 20%, SETI@Home około 25%, Radioactive@Home za to aż ok. 90% (ze względu na to, że to stosunkowo nowy projekt, a liczba czujek wzrasta). Do puli projektów mało inflacyjnych nie kwalifikują się DistrRTgen ani GPUGRID.

Zresztą faktem jest to, że duża inflacja nie będzie sprzyjała projektowi, a co za tym idzie jego akcje będą mniej poszukiwane na giełdzie (nawet jeżeli się na niej znajdzie). Nikt nie będzie chciał kupić takich kredytów DistrRTgen, a lepsze będą jak widać po inflacji World Community Grid. W idei pomysłu było to, że procent od operacji na akcjach danego projektu będą dostawać jego admini. Admini więc będą bardziej przykładać się do tego aby ta inflacja była stosunkowo niska, ponieważ tak jak piszę inaczej nie będzie się im to opłacało.

Zresztą co tutaj dużo pisać - może to się tylko przyczynić do lepszego pilnowania jakości naliczania kredytów. W tym systemie możemy otrzymać raczej mniej kredytów, a nie więcej niż powinniśmy.



9. Co z podziałem punktów uzyskanych na CPU / GPU?

Będzie musiał zostać zachowany podział pomiędzy projektami (podprojektami) CPU, a GPU.



10. Przyjmijmy, że jako członek teamu sprzedam swoje kredyty. Czy dorobek mojego zespołu zmniejszy się o sprzedane kredyty? Czy handel kredytami pomiędzy zespołami powinien być możliwy?

Sprawa nie jest taka prosta. Jeżeli zechcemy aby w aktualnym systemie, który działa w większości projektów BOINC (punkty obliczone w zespole zostają w nim nawet po zmianie przez użytkownika teamu) dochodzi do dodatkowych komplikacji.

Przyjmijmy, że mamy użytkownika X. Liczy on jednego dnia 12 godzin dla zespołu T1 (800 kredytów), 6 godzin dla zespołu T2 (400 kredytów) i 4 godziny dla zespołu T3 (300 kredytów). Potem chce sprzedać 1000 kredytów dla użytkownika innego teamu. Jeżeli zdecydujemy się na to, że kredyty przechodzą nie tylko z użytkownika do użytkownika ale także z teamu do teamu to od którego teamu należy odjąć kredyty?

Jeżeli zechcemy odejmować to chyba od ostatnich zespołów w jakich był user czyli tak: 300 kredytów z T3, 400 kredytów z T2 i 300 kredytów z T1. Nie możemy przecież odjąć wszystkich 1000 kredytów od zespołu T3, ponieważ user nie ma w nim nawet takiego wkładu.

Serwer BOINC nie wie na ten temat nic. Statystyki swoją drogą ale do podejmowania decyzji na ten temat potrzeba w najgorszym przypadku statystyk z całego czasu istnienia projektu. Sporo to chyba komplikuje.

Można faktycznie pozostawić teamy w świętym spokoju i niech zostaje wszystko tak jak jest (operacje giełdowe nie będą ich dotyczyły). Można też zrobić tak, że total credit teamu byłby zawsze równy kredytom sumie ich członków (kredyty przechodzą za użytkownikiem z teamu do teamu - o czym pisałem wcześniej) i wtedy operacjami giełdowymi objąć także zespoły.

Wydawaje się, że objęcie operacjami giełdowymi także zespołów może wyjść na plus giełdzie. Uruchamia to dodatkową płaszczyznę do rywalizacji między zespołami.



11. Handel między zespołami to beznadziejny pomysł. Inny zespół zapłaci i śmignie kilka razy w statystykach mój team. Jest na to jakaś rada?

Trudno przewidywać i przy wprowadzeniu Giełdy BOINC wszystko mogłoby się wydarzyć. Każdy kij ma jednak dwa końce - jeżeli jeden zespół kupi (otrzyma) kredyty to jakiś inny musi je sprzedać (stracić). Ilość kredytów na rynku pozostaje ta sama (nie licząc tych które ubijamy licząc) i nie ma tutaj jakiegoś cudownego rozmnożenia. Więc dzięki temu, że team X kupi określoną ilość kredytów od teamu Y zespół Z może nie tylko spaść w rankingu względem X ale także awansować względem Y (ponieważ ten kredyty straci).



12. Jak rozwiązać kwestię kredytów uzyskiwanych w podprojektach? Czy w jakiś sposób można byłoby zakupić/sprzedać kredyty nie tyle projektu co konkretnego jego podprojektu?

Na BOINC podprojekty mogłyby być tak samo traktowane jak projekty. Jeżeli dany projekt posiadałby podprojekty to do obrotu giełdowego wchodziłyby kredyty konkretnych podprojektów (użytkownik mógłby zakupić kredyty, które jego interesują). Jeżeli natomiast projekt nie posiadałby żadnych podprojektów to na rynek wchodziłyby kredyty z pola "total credit".



13. BOINC straci sens. Przecież jeżeli będzie można kupić kredyty to nikt nie będzie ich liczył tylko wszyscy będą kupować.

Ale przecież aby kupić to ktoś z drugiej strony musiałby je sprzedać, a aby sprzedać musiałby je zdobyć obliczając (lub np. kupując wcześniej za niższą cenę). Przecież nie ma czegoś takiego, że wszyscy przestaliby liczyć bo mogliby sobie kupić kredyty.



14. Czy możliwe byłoby znalezienie "złotego środka" pomiędzy userami chcącymi wykonywać operacje giełdowe, a tymi nie wykonujących ich nigdy?

Konta BOINC można byłoby podzielić na te, które mogłyby korzystać z Giełdy BOINC i te, które nie mogłyby na niej wykonywać żadnych operacji. Użytkownik podczas zakładania konta decydowałby do której grupy chce należeć. Decyzja o przynależności do określonej grupy byłaby nieodwołalna (nie można jej zmienić - ktoś mógłby zakupić X kredytów i potem zmienić rodzaj konta na ten, na którym nie wykonuje się operacji giełdowych).

Albo lepiej tak: konto bez dostępu do giełdy można zawsze zamienić na konto z dostępem do giełdy, ale konta z dostępem do giełdy nie można już zamienić na te bez dostępu do niej.

Powstanie takiego podziału rodzajów kont jest proste w implementacji. Dzięki temu nawet po rewolucjach w świecie BOINC miejsce w nim znalazłoby się także dla przeciwników nowej giełdy - mogliby oni liczyć na starych zasadach. Możliwy byłby wtedy do stworzenia ranking kont liczących BOINC ale bez dostępu do operacji giełdowych.



15. Co jeżeli na rynek wejdzie kilka użytkowników posiadających miliardy kredytów i chcących je sprzedać po bardzo niskiej cenie - niższej niż koszty energii elektrycznej potrzebnej do ich wygenerowania? Przecież może to zdestabilizować Giełdę BOINC, a nowym użytkownikom nie będzie się opłacało na nią wchodzić.

Jest to poważny problem Giełdy BOINC. Można spróbować ten problem rozwiązać na kilka różnych sposobów.

Można ustalić kurs minimalny kredyta np. na 75% kosztu jego wytworzenia. Koszt wytworzenia byłby obliczany na podstawie najlepszego dostępnego zestawu do obliczeń oraz jakiejś tam stawki za energię elektryczną i byłby różny dla różnych projektów na Giełdzie BOINC.

Można także wprowadzić limit wrzucania na giełdę kredytów które sie wypracowało w ciągu doby. Nie chodzi tutaj o jakiś stały limit a ograniczenie na podstawie np. średniej dziennej ilości kredytów w ostatnim tygodniu.

Przykład: W ciagu 7 dni zdobył 7000 kredytów podzielić to na 7 (ilość dni w tygodniu) wyszło by 1000 na dobę + 20% (stopniowe uwalnia tego co juz jest) co by dało 1200 i tyle mogły wrzucić na dobę kredytów na giełdę. Można przemyśleć wprowadzenie mechanizmu zliczającego nieobecność na giełdzie i automatycznie umożliwiającego dołożenie do giełdy następującej ilości kredytów: ilość kredytów średniej dziennej x ilość dni nie obecności na giełdzie.

Plus takiego mechanizmu że uniemożliwiło by dopływ dużej ilości kredytów które zalega obecnie u ludzi, zablokowało by tych co juz przestali bawić sie a chcieli by tylko pozbyć sie istniejących kredytów (zmusiło by ich do ponownego liczenia aby móc wystawić to co mają).



16. Czy będą chętni do korzystania z Giełdy BOINC?

To bardzo trudne pytanie. Trudno powiedzieć. Wszystko zależy od nas samych i tego czy pomysł ma szanse przyjąć się. Giełda nie jest dedykowana tylko dla użytkowników jednego forum lub osób pochodzących z określonego kraju, a miałby być to twór międzynarodowy. Gdy zbierzemy wszystkich potencjalnych użytkowników giełdy z całego świata i osoby, które po otwarciu takiego instrumentu świeżo dołączą - ich ilość może być wystarczająca.

Mamy taką oto funkcję:



Dla argumentu 0.5+14i dość dokładna aczkolwiek także przybliżona wartość tej funkcji to:

0.0222411426099935892462132 - 0.1032581232664500579023631i

Spróbujmy sami to policzyć dla kilku pierwszych wyrazów według wzoru.

Dla czterech wyrazów (razem z jedynką) mamy więc:

1 + 1/(2^(0.5+14i)) + 1/(3^(0.5+14i)) + 1/(4^(0.5+14i)) =
= (1+0i) + (1+0i)/((2+0i)^(0.5+14i)) + (1+0i)/((3+0i)^(0.5+14i)) + (1+0i)/((4+0i)^(0.5+14i)) =
= (1+0i) + (1+0i)/(-1.3594-0.3898i) + (1+0i)/(-1.6400+0.5569i) + (1+0i)/(1.6960+1.0599i) =
= (1+0i) - 0.6797+0.1949i - 0.5467-0.1856i + 0.4240-0.2649i =
= 0.3203-0.1949i - 0.5467-0.1856i + 0.4240-0.2649i =
= -0.2264-0.0093i + 0.4240-0.2649i =
= 0.1976-0.2742i

Dla pięciu wyrazów (suma czterech wcześniejszych plus piąty):

0.1976-0.2742i + 1/(5^(0.5+14i)) =
= 0.1976-0.2742i + (1+0i)/(-1.9167-1.1515i) =
= 0.1976-0.2742i - 0.3833+0.2303i =
= - 0.1857-0.5045i

Dla sześciu wyrazów:

- 0.1857-0.5045i + 1/(6^(0.5+14i)) =
= - 0.1857-0.5045i + (1+0i)/(6^(0.5+14i)) =
= - 0.1857-0.5045i + (1+0i)/(2.4466-0.1177i) =
= - 0.1857-0.5045i + 0.4077+0.0196i =
= 0.222-0.4849i

Dla siedmiu wyrazów:

0.222-0.4849i + 1/(7^(0.5+14i)) =
= 0.222-0.4849i + (1+0i)/(7^(0.5+14i)) =
= 0.222-0.4849i + (1+0i)/(-1.3584+2.2703i) =
= 0.222-0.4849i - 0.1940-0.3243i =
= 0.028-0.1606i

Dla ośmiu wyrazów:

0.028-0.1606i + 1/(8^(0.5+14i)) =
= 0.028-0.1606i + (1+0i)/(8^(0.5+14i)) =
= 0.028-0.1606i + (1+0i)/(-1.8923-2.1021i)
= 0.028-0.1606i - 0.2365+0.2627i =
= -0.2085-0.4233i

Dla dziewięciu wyrazów:

- 0.2085-0.4233i + 1/(9^(0.5+14i)) =
= - 0.2085-0.4233i + (1+0i)/(9^(0.5+14i)) =
= - 0.2085-0.4233i + (1+0i)/(2.3795-1.8269i) =
= - 0.2085-0.4233i + 0.2644+0.2029i =
= 0.0559-0.2204i

Dla dziesięciu wyrazów:

0.0559-0.2204i + 1/(10^(0.5+14i)) =
= 0.0559-0.2204i + (1+0i)/(10^(0.5+14i)) =
= 0.0559-0.2204i + (1+0i)/(2.1567+2.3126i) =
= 0.0559-0.2204i + 0.2156-0.2312i =
= 0.2715-0.4516i

Dla jedenastu wyrazów:

0.2715-0.4516i + 1/(11^(0.5+14i)) =
= 0.2715-0.4516i + (1+0i)/(11^(0.5+14i)) =
= 0.2715-0.4516i + (1+0i)/(-1.8281+2.7672i) =
= 0.2715-0.4516i - 0.1662-0.2515i =
= 0.1053-0.2001i

Suma dla pierwszych dwudzistu wyrazów wynosi: -0.2044+0.3320i, a dla dwustu już -0.9251+0.2422i. Jak widać wzrost ilości iteracji objawia się zwiększeniem błędu zamiast jego zmniejszeniem. Pytanie dlaczego tak jest? Gdzie mam błąd? Muszę jeszcze dodać, że akurat w tym przypadku błąd się zwiększa. Czasem wyniki są od razu złe, a czasem dobre (przy uwzględnieniu, że są one przybliżone). Jest to jednak chyba kwestią przypadku.

Plik z kodem źródłowym można podejrzeć tutaj: http://code.google.com/p/olib/source/browse/trunk/samples/mathematics/riemann_zeta.cpp. Jak łatwo zauważyć operacje na liczbach zespolonych sam implementowałem ale dobrze je przetestowałem i wygląda na to, że działają ok.

Co w tym wszystkim nie gra?

Posiada może ktoś jakiegoś Linux'a 64-bit z serwerem X'ów? Potrzebuję upewnić się czy wygaszacz ekranu działa.

Można pobrać archiwum z:

http://atom.goldbach.pl/slide.zip

Należy następnie archiwum rozpakować i uruchomić zawarty w nim plik slide_show. Nie należy rozpakowywać pliku slide_show_images.zip - powinien pozostać w katalogu normalnie bez rozpakowywania.

Gdyby ktoś miał możliwość przetestowania to bardzo bym prosił.

Tak jak w temacie. Wybierajcie miesiąc dla Polish BOINC Conference.

Temat umarł.

Trochę jednak od czasu ostatniego podejścia do konferencji się zmieniło. Rozmawiałem ostatnio z mordim i nie byłoby problemu z salą na czas konferencji w Warszawie (AON). Lokalizacja więc dość dobra.

Może by tak spróbować coś drgnąć?

Mam dziwny problem z programem. Otóż jeżeli kompiluję jego z optymalizacjami dla CPU i O3 to wykonuje się teoretycznie poprawnie. W przypadku gdy kompiluję bez optymalizacji CPU i z O2 podczas uruchamiania dostaję "Segmentation fault".

Program można pobrać z repozytorium googlecode:

svn checkout http://olib.googlecode.com/svn/trunk/ olib

Następnie należy wejść do odpowiedniego katalogu z przykładami:

cd olib/samples

I wykonać odpowiednie polecenie make:

make goldbach_odd

Po kompilacji program będzie znajdował się w podkatalogu mathematics, który znajduje się w katalogu samples.

cd mathematics

Wystarczy uruchomić program odpowiednią dość długą komendą:

time env OMP_NUM_THREADS=2 ./goldbach_odd 100000000209366024193 10000000000000000000000

i program powinien zwrócić Segmentation fault.

Można spróbować dodać optymalizacje CPU w pliku makefile (olib/samples/makefile). Odpowiada za to 71 linijka:

CPU_OPTYMALIZATION = no

Próbowałem debugować programem gdb. Udało mi się jednak uzyskać tylko:

Program received signal SIGSEGV, Segmentation fault.
0x000000000041de43 in __gmpz_set_str ()

Nic mi to nie mówi. Błąd z pewnością jest w sekcji OPenMP w pliku olib/samples/mathematics/goldbach_odd.cpp

    #pragma omp parallel shared(S, add_1, add_2, number_of_threads) private(thread_id, number, upper_range, counter)
   {


   }

Błąd jest jednak niezależny od ilości wątków na których będzie wykonywany program - występuje nawet gdy program uruchomimy na jednym wątku.

Czy ktoś mógłby pomóc i zrobić porządne debugowanie tego programu?

Poniższa strona jest cały czas generowana.

Przedstawia kawałek świata. (Generuje od strony lewej do prawej). Na biało oznaczane powinny być wody.

Co to za obszar?

http://atom.goldbach.pl/img2.php

A ciężko dobrać kategorię:

oproject.info

Opis projektu OProject na wiki

Posiada może ktoś jakiegoś Radeona z systemem operacyjnym Linux i zainstalowanym środowiskiem OpenCL?

Pracuję nad pewną app i chciałbym przetestować ją na kartach AMD.

Jak wygląda sprawa z przenośnością kodu OpenCL między różnymi platformami sprzetowymi? Z tego co widzę program napisany w OpenCL bez zmian nie zadziała chyba na np. procesorze IBM Cell? Co z AMD Radeonami? Czy ten sam kod kompilowalny i uruchamialny na platformie nVidia zadziała na sprzęcie AMD?

Rozumiem, że OpenCL to jeden standard ale coś jednak do końca mi tutaj nie pasuje  %)

Posiadam mikrokomputer. Ciekawa zabawka ale jednak mam problem. Mam na nim Debian'a 6.0.

Zmieniłem hasło na własne. Robiłem to w nocy i na netbooku ze słabo działającą klawą i okazało się, że zmieniłem je na takie, którego nie znam.

Cacko ma tylko dwa orty LAN i USB. Jedyna możliwość połączenia to przez SSH. Po zmianie hasła na takie którego nie znam nie mogę zrobić niczego.

Rozebrałem całość i wyjąłem dysk twardy. Chciałem jego podłączyć do swojego komputera ale okazało się, że albo to nie jest SATA albo to jakaś wersja "mini" tego interfejsu.

Gdyby udało mi się dostać do plików mógłbym tam pogrzebać i jakoś zmienić hasło.

Wie może ktoś co to za interfejs? Zamieszczam zdjęcia mikrokomputera.

http://img849.imageshack.us/img849/6305/52914513.jpg
http://img209.imageshack.us/img209/8762/96332979.jpg
http://img19.imageshack.us/img19/7821/58543187.jpg
http://img819.imageshack.us/img819/4135/39994266.jpg

Jakiś czas temu zastanawiała mnie możliwość budowy lokalizatora.

Nie takiego jak GPS, a umożliwiającego za pomocą odbiornika oszacowanie tylko i wyłącznie odległości od nadajnika.

Nadajnik emitowałby jakiś impuls (fal radiowych?) a odbiornik jakoś próbowałby oszacować odelgłość w jakiej się znajduje od owego nadajnika. Wiem, że dużym problemem są tutaj dodatkowe przeszkody typu drzewa, ściany itp. ale chodzi mi tylko o jakiś szacunek.

Ktoś może myślał nad czymś takim?

Witam wszystkich serdecznie;

W lipcu tego roku planowałem wyjazd w Góry Sowie do kompleksu Riese budowanego w czasie II Wojny Światowej przez Niemców. Zbieram zespół aby to samemu nie jechać a zrobić sporo pomiarów, a przy okazji pozwiedzać i ciekawie spędzić czas.

Nie wiem czy ktoś coś słyszał o tym co Hitler mógł planować w Górach Sowich ale jest sporo interesujących hipotez na ten temat - m. in. możliwość pracy nad bronią biologiczną, chemiczną lub też atomową.

Celem ma być opracowanie mapy promieniowania terenu i podziemnych tunelów wydrążonych w górach, które są lepiej lub gorzej dostępne (nie wiadomo gdzie się dostaniemy).

Niemcy wycofując się z tych terenów powysadzali wszystkie przejścia  - położenie niektórych hipotetycznych budowli do dnia dzisiejszego nie jest znane. Jako ciekawostkę dodam, że jest to jedno z bardziej prawdopodobnych miejsc gdzie może znajdować się bursztynowa komnata.

Zainteresowany tematem napisałem do Svistak'a zapytanie odnośnie tego czy mógłby wypożyczyć Terrę. Dostałem odpowiedź, że nie tyle wypożyczy ją co sam się pisze na wyprawę jeżeli zostanie ona zorganizowana zaraz po 25 lipca. Wcześniej planowałem szybciej pojechać (po 5 lipca) ale chyba wszystko się przesunie skoro będzie można dysponować Terrą (i Svistak'iem).

Może ktoś tutaj jest żądny przygód?  :attack: