Gutenberg
pl.wikipedia.org/wiki/Johannes_Gutenberg

obmyślił kiedyś druk
pl.wikipedia.org/wiki/Druk

i zaczęło się. Wszyscy poszli na łatwiznę.

To samo z samochodami. Nikt już nie chce biec ani nawet jechać na koniu, każdy woli samochodem.

Mamy, my w znaczeniu stworzenia żywe, skłonność do oszczędzania energii a procesy umysłowe chłoną jej najwięcej.

Czy to nie jest ciekawe myślenie abstrakcyjne pochłania fizyczną energię?
W końcu chciałoby się powiedzieć mamy tu dwa światy, jeden abstrakcyjny - niefizyczny a drugi fizyczny, oba ze sobą splątane?

Jakby nie nawoływać do papirusów w dobie urządzeń półprzewodnikowych

pl.wikipedia.org/wiki/Procesor
pl.wikipedia.org/wiki/Napęd_SSD

o papirusach możemy już spokojnie zapomnieć.

Kto ma jeszcze papierowe banknoty z nadrukowaną liczbą

pl.wikipedia.org/wiki/Banknot

ten może je zachować dla wnuczków, bo wnuczęta będą znali takie rzeczy już tylko z opowieści dziadków.

Mój pomysł jest taki, żeby umiejętności analizy - rozkładu

pl.wikipedia.org/wiki/Analiza_matematyczna

podobnie jak i algebry - syntezy

pl.wikipedia.org/wiki/Algebra

rozwijać już tylko dzięki programowaniu.

Skoro pracownik firmy chce poddać działalnie programu w wątpliwość, bo np. zawiera w sobie trojana, wówczas powinien skorzystać z innego, niezależnego programu i porównać działania ich obu ale nie powinien sięgać już po kartkę i długopis, chyba, że chce skończyć marnie.

>Należy podkreślić znaczenie obliczeń na papierze na kierunkach związanych z biznesem, bo to stanowi
>sens studiowania. Niepokojące jest, że firmy mają obecnie większe zaufanie do gotowych programów
>komputerowych niż do samodzielnych obliczeń pracowników.Umiejętności myślenia analitycznego zostały
>zmarginalizowane, chociaż pozwalają ograniczyć koszty nabycia oprogramowania.

Zgadzam się z tym w pełni.

Programowanie zostało zdegradowane do umiejętności używania gotowych programów.

Nie liczy się żadna optymalizacja, pomysł, innowacja, umiejętności matematyczne, itd.

I to jest kolejny krok do samozagłady:
przecież to prowadzi bezpośrednio do utraty wszelkiej kontroli nad maszynami (softem).

>Programowanie zostało zdegradowane do umiejętności używania gotowych programów.

Używanie gotowego oprogramowania to nie programowanie.

>>Programowanie zostało zdegradowane do umiejętności używania gotowych programów.
>Używanie gotowego oprogramowania to nie programowanie.

Ale obecnie tak to wygląda, niestety.

Program komputerowy tworzony od zera przez specjalistę to rzadkość obecnie;
można to nawet zaliczyć do kategorii sztuki - tej tajemnej!

Ja kilka razy próbowałem zlecić wykonanie, zaprogramowanie algorytmów,
z optymalizacji i innych dziedzin, no i nie znalazł się ani jeden chętny;
niektórzy nawet próbowali ale szybko się poddali... bo oni uprawiają zaledwie chałupnictwo komputerowe, a nie żadne programowanie!

>Należy podkreślić znaczenie obliczeń na papierze na kierunkach związanych z biznesem, bo to stanowi
>sens studiowania. Niepokojące jest, że firmy mają obecnie większe zaufanie do gotowych programów
>komputerowych niż do samodzielnych obliczeń pracowników.Umiejętności myślenia analitycznego zostały
>zmarginalizowane, chociaż pozwalają ograniczyć koszty nabycia oprogramowania.
Może wręcz przeciwnie należy podzielić kierunki na ścisłe i pozostałe. Ścisłowcy byliby angażowani w tworzenie oprogramowania

>Należy podkreślić znaczenie obliczeń na papierze
>(...)
>Umiejętności myślenia analitycznego zostały zmarginalizowane

A co to jest "myślenie analityczne"? Tak na chybił trafił z googla:

www.uwe.ed(*)analityk-biznesowy-ile-zarabia

Cytat:

Jeżeli to jest definicja "analitycznego myślenia", to nie ma ono nic wspólnego z umiejętnością liczenia, a nawet czytania lub pisania, łącznie ze sprawnym wzrokiem, słuchem, czy innym kalectwem.

>Niepokojące jest, że firmy mają obecnie większe zaufanie do gotowych programów komputerowych niż do samodzielnych obliczeń pracowników.

Obliczenia są tyle warte ile warte są dane użyte do obliczeń - jak się nakarmi papier bzdurnie wybranymi danymi, to nawet największy geniusz obliczeń papierowych wyprodukuje absurdalne wyniki i to mimo ich matematycznej poprawności.

Umiejętność "liczenia" jest ostatnią z potrzebnych umiejętności, najpierw trzeba się nagłowić skąd wziąć wiarygodne dane, które grupy danych można ze sobą zestawić i szukać między nimi powiązań, a które nie, które dane z których mogą wynikać, a które są zupełnie niezależne i nie ma sensu brać ich pod uwagę - dopiero potem można zacząć cokolwiek liczyć, a nawet powierzyć samo liczenie komuś innemu, z programem komputerowym włącznie.

Tak, tak.
Właśnie zaprezentowałeś świetny przykład 'chałupnictwa komputerowego'.

Masz danych ile chcesz: encyklopedie, biblioteki, kamery, wszystko - Peta Bajty!

Zatem zrób program, który nakarmisz tymi danymi, no i niech on... nauczy się - czegokolwiek!

Takie mrzonki były nawet bardzo popularne w latach 80-tych:
sztuczna inteligencja, systemy samouczące, ekspertowe, itd.

Po kilku latach wszystko to zdechło kompletnie - dlaczego?

Właśnie dlatego że dane to za mało - tu potrzebny jest algorytm!
A algorytm sam się nie zrobi, niestety.

Była też popularna skrajnie fantastyczna utopia, że samo ładowanie informacji utworzy samoświadomość - masa krytyczna informacji i inne takie brednie chałupnicze.

Albo weźmy bezpośredni przykład: szachy.

I co takiego w tej dziedzinie się wdarzyło, że obecnie komputer wygrywa z człowiekiem?

Nic! Programy szachowe są w zasadzie takie same od 30 lat,
nic nowego tu nie wymyślone, jedynie obecne komputery są z milion razy szybsze... i tyle wystarczyło, aby pokonać człowieka.

Czy istnieje lepsze metoda - lepszy algorytm szachowy?
Z pewnością, no ale po co to komu, skoro wystarczają gotowce,
algorytmy zrobione przez analityków 30 lat temu!

>Takie mrzonki były nawet bardzo popularne w latach 80-tych:
> sztuczna inteligencja, systemy samouczące, ekspertowe, itd.

Ja przepraszam, ale w którym miejscu o tym napisałem?

>Ja przepraszam, ale w którym miejscu o tym napisałem?

Napisałeś wiele fantastycznych rzeczy:

"Obliczenia są tyle warte ile warte są dane użyte do obliczeń - jak się nakarmi papier bzdurnie wybranymi danymi, to nawet największy geniusz obliczeń papierowych wyprodukuje absurdalne wyniki i to mimo ich matematycznej poprawności".

i dalej:

"Umiejętność "liczenia" jest ostatnią z potrzebnych umiejętności, najpierw trzeba się nagłowić skąd wziąć wiarygodne dane, które grupy danych można ze sobą zestawić i szukać między nimi powiązań, a które nie, które dane z których mogą wynikać, a które są zupełnie niezależne i nie ma sensu brać ich pod uwagę - dopiero potem można zacząć cokolwiek liczyć, a nawet powierzyć samo liczenie komuś innemu, z programem komputerowym włącznie".

To są typowe błędy w tej dziedzinie.

Nie potrzeba umiejętności?

No to dawaj... oblicz mi np. taką prostą rzecz (masz 100% danych):
int dx/(1 + c*cosx) = ?

a to jest pikuś, bo mogłem zadać np. równanie cząstkowo-całkowe, a nawet i o wiele gorsze sprawy są tu nietrudne do wymyślenia!

>To są typowe błędy w tej dziedzinie.

Może rozmawiamy o różnych dziedzinach - w tym problem.

>Nie potrzeba umiejętności?
>No to dawaj... oblicz mi np. taką prostą rzecz (masz 100% danych):
>int dx/(1 + c*cosx) = ?

A co ta funkcja liczy i na jakich danych ma operować? Czym jest x - jakąś daną rynkową lub biznesową, wszak takich dotyczy wątek?

Czym innym jest tworzenie wzorów obliczeniowych, a czym innym przepuszczenie danych przez owe wzory w celu wyliczenia czegoś, łącznie z wykresami. Po pierwsze, muszę wiedzieć, że ta funkcja jest mi do czegokolwiek potrzebna, po drugie mowa jest o kierunkach związanych z biznesem, gdzie trygonometria, jeżeli w tych dziedzinach jest potrzebna, to na pewno nie występuje w obliczeniach papierowych, tylko siedzi głęboko w rzeczonych algorytmach. Rachunek prawdopodobieństwa zapewne też się przyda i nie sądzę by ktoś się podejmował obliczeń papierowych (obliczeń w sensie wartości, a nie tworzenia wzorów pod algorytmy).

Tyle, że aby zacząć tworzyć algorytm do obróbki danych trzeba wiedzieć, a w zasadzie wymyślić, ocenić i intuicyjnie przeanalizować, jakie dane chce się obrabiać i czemu mają służyć wyniki - i tu zanim dojdzie w ogóle do tworzenia jakichkolwiek wzorów, obliczeń czy symulacji, nie mówiąc o zbieraniu danych, potrzeba "myślenia analitycznego" na poziomach abstrakcyjnych, którego posiadacz wcale nie musi być "programistą", a "programista" wcale nie musi mieć abstrakcyjnego "analitycznego myślenia" w dziedzinie, której dotyczyć będą obliczenia - we dwójkę (myślący analitycznie i programista) mogą się już dogadać i to jest lepsze rozwiązanie niż jedna multispecjalista, który sam siebie weryfikuje i jest zadowolony, że dostał "przyjazne wyniki", zgodne z "genialnym algorytmem", który w zderzeniu z rzeczywistością i nakarmiony absurdalnie dobranymi danymi może wypluwać wyniki, które można sobie wsadzić głęboko.

To, że ludzie skupiają się na gotowych rozwiązaniach wynika ze złożoności problemów związanych z ogromem danych, których pojedynczy ludzki mózg nie jest w stanie przetworzyć - ale gotowe rozwiązania trzeba też umieć używać i nie karmić ich bzdurnymi danymi, bo wyniki będą równie bzdurne.

Jest mnóstwo przykładów że algorytm decyduje o sensowności całego projektu, a nie jakieś tam gotowce.

Był nawet taki fajny przypadek w grafice gier 3D:
jak efektywnie obliczyć 1/sqrt(x) z dobrym przybliżeniem?

No i jeden facet takie coś wymyślił, że szok!
en.wikipedia.org/wiki/Fast_inverse_square_root

i co tam się dzieje w pale nie mieści!

Facet rypie algorytm wyliczania 1/sqrt(x) w postaci:

float Q_rsqrt( float number )
{
long i;
float x2, y;
const float threehalfs = 1.5F;

x2 = number * 0.5F;
y = number;
i = * ( long * ) &y; // evil floating point bit level hacking
i = 0x5f3759df - ( i >> 1 ); // what the f**k?
y = * ( float * ) &i;
y = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration
// y = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed

return y;
}

żaden współczesny chałupniczy programer w życiu by takiego cudactwa nie wyprodukował,
bo to wymagało perfekcyjnej wiedzy o reprezentacji fizycznej liczb w komputerze itd.
co jest obecnie czarną magią!

>Jest mnóstwo przykładów że algorytm decyduje o sensowności całego projektu, a nie jakieś tam gotowce.
>Był nawet taki fajny przypadek w grafice gier 3D:

Z uporem odbiegasz od tematu.

Tak przy okazji odnośnie danych - najprostszy przykład zasilania super algorytmu bzdurnymi danymi - załóżmy, że danymi są jakieś tam ilości czegoś, przy czym wprowadza je grupa ludzi - problem polega na tym, że można owe ilości wprowadzać w różnych jednostkach, w tym w jednostkach niemożliwych do przeliczenia i unormowania bez narzucenia sztywnego standardu wprowadzania np. w: metrach, sztukach, kompletach, kilogramach, m2, m3...

...no i wskutek niedomówienia i braku wiedzy każdy wprowadza dane jak chce i w jakich chce jednostkach, co powoduje, że ów zbiór danych jest jako całość wyłącznie wielkim chaosem - i wtedy jedyną możliwością jest wyczyszczenie bazy danych i zaczęcie wszystkiego od nowa - przykład może prostacki, ale realnie występujący, łącznie z jakąś misją kosmiczną, gdy rozwalono sondę o powierzchnię jakiejś tam planety, bo ktoś wprowadzając dane pomieszał funty z kilogramami, a śmiem wątpić, by wykonywał te obliczenia na kartce papieru...

>Jest mnóstwo przykładów że algorytm decyduje o sensowności całego projektu, a nie jakieś tam gotowce.

A ja myślę, że wszyscy, którzy wykorzystują gotowe procesory i kompilatory to cieniasy

Prawdziwy profesjonalista sam projektuje swój procesor, samodzielnie tworzy dla niego kompilator, a dopiero na końcu zabiera się za programowanie.

www.youtube.com/watch?v=g_ZaioqF1B0

.

>>Jest mnóstwo przykładów że algorytm decyduje o sensowności całego projektu, a nie jakieś tam gotowce.
>A ja myślę, że wszyscy, którzy wykorzystują gotowe procesory i kompilatory to cieniasy
>Prawdziwy profesjonalista sam projektuje swój procesor, samodzielnie tworzy dla niego kompilator, a dopiero na końcu zabiera się za programowanie.
>www.youtube.com/watch?v=g_ZaioqF1B0

Może i tak - w końcu wszystko to i tak... ciul:
może na początku troszkę mniejszy, ale za to później jeszcze większy!

>int dx/(1 + c*cosx) = ?

Wspomniany kiedyś SymPy robi takie rzeczy od ręki:



.

>>int dx/(1 + c*cosx) = ?
>Wspomniany kiedyś SymPy robi takie rzeczy od ręki:

Podobne bzdury wolfram wywala,
o ile nie wysiada kompletnie, bo to też nietrudno rozwalić - wystarczy pyknąć nieco bardziej złożoną funkcję, i już leży.

... a ta całka to zwyczajny arctan, a nie jakieś takie wariactwa, które wydrukowałeś.

Niemniej mam i tak swój super hit w tej dziedzinie, którego jeszcze chyba nikt nie wymyślił:

całkowanie numeryczne z szybkością miliony/biliony razy większą od wszelkich znanych metod - gotowców!

Standardowe metody mają tę wadę że mają ustalony rząd zbieżności,
np. metoda Simpsona ma rząd zbieżności 4, co jest bardzo dobre wbrew pozorom...
no ale moja metoda rozwala Simpsona w diabli.

Obecnie do naszjybszych zalicza się chyba metody Gaussa, ale to też jest słabe w porównaniu z moją, bo wymaga znacznie więcej obliczeń, jak i zbędnych danych w postaci tablic współczynników, co jest mało sensowne, bo wymaga wyliczania od początku po zwiększeniu rzędu.

Mam na myśli obliczenia z dużą precyzją, np. 100 cyfr chociaż,
bo wyliczenie całki do 10 czy 16 cyfr, to... ja w pamięci takie trywializmy realizuję.

>>>int dx/(1 + c*cosx) = ?
>>Wspomniany kiedyś SymPy robi takie rzeczy od ręki:
>Podobne bzdury wolfram wywala,
>o ile nie wysiada kompletnie, bo to też nietrudno rozwalić - wystarczy pyknąć nieco bardziej złożoną funkcję, i już leży.

No nie wiem,

dla c równego 1 lub -1 wynik zwracany przez komputer jest poprawny:



dla pozostałych nie mam teraz czasu żeby to sprawdzić

>... a ta całka to zwyczajny arctan, a nie jakieś takie wariactwa, które wydrukowałeś.

A z ciekawości co to za arctan, z czego?

.

Wystarczy podstawić z gotowca:

t = tg(x/2)

wtedy otrzymasz: cos(x) = (1-t^2)/(1+t^2)

oraz: x/2 = arctan(t), czyli dx = 2dt/(1+t^2)

co po wstawienie daje:

dx/(1 + c*cos(x)) = 2dt/(1+t^2) * 1/(1 + c * ... ).

a dalej to już będzie widać, że to pójdzie w arctan.

Być może lepiej tu użyć: z = e^ix, ale to już... nie dla frajerów.

>t = tg(x/2)
>wtedy otrzymasz: cos(x) = (1-t^2)/(1+t^2)
>oraz: x/2 = arctan(t), czyli dx = 2dt/(1+t^2)
>co po wstawienie daje:
>dx/(1 + c*cos(x)) = 2dt/(1+t^2) * 1/(1 + c * ... ).
>a dalej to już będzie widać, że to pójdzie w arctan.

Tam się pojawi wyrażenie z jakimś arctan i tg(x/2),

ale arctan można wyrazić za pomocą logarytmu z uwagi na związek:

arctan(z) = (ln(1 + iz) - ln(1 - iz)) / 2i

en.wikiped(*)ic_functions#Logarithmic_forms

więc b. możliwe, że to się jednak sprowadzi do postaci zwróconej przez komputer,

w wyrażeniu z komputera jest właśnie różnica dwóch logarytmów w liczniku, w SymPy "log" to logarytm naturalny

.

Ta całka jest interesująca generalnie.

przykłady: orbita eliptyczna:
r(f) = p/(1 + e*cosf); p = a*(1-e^2); a - półoś duża elipsy

jaka jest średnia odległość na takiej orbicie (po f i po t - czasie)?

No i tu właśnie należy wyliczyć tę całkę aby to odkryć.

A dalej jest jeszcze straszniej: prędkość światła względem układu poruszającego się z prędkością v:

c(f) = c/(1 + v/c cosf)

tak to wygląda!

średnia z tego (po f):
<c> = c*sqrt(1-v^2/c^2) = c/gamma;
no i to jest rzeczywistą przyczyną zwalniania zegarków, czyli popularnie: dylatacji czasu w ruchomych obiektach: prędkość światła/komunikacji maleje wtedy gamma razy!

Domyśliłem się, że to ma jakiś związek z fizyką.

No i sprawdziłem, to co komputer wypisał, to jest postać równoważna z arctan:



Wynik poprawny tylko po prostu niezbyt optymalnie zapisany.

.

spróbuj coś w tym stylu wyliczyć:
int cos(x)^5 dx = ?

>spróbuj coś w tym stylu wyliczyć:
>int cos(x)^5 dx = ?
>

To jest ta trudna całka na której SymPy ma się wywalić?



I jest to poprawne, bo:



.

>To jest ta trudna całka na której SymPy ma się wywalić?

Może się wywalić na czymś podobnym, np. spróbuj: cos^99

Chodzi o metodę liczenia tego typu całek.

Należy podstawić: z = exp(ix), a wtedy:

cos(x) = (z + 1/z)/2

zatem: cos(x)^n = [(z + 1/z)/2]^n, co łatwo wyliczyć;

przykład:
cos(x)^2 = [(z + 1/z)/2 ]^2 = (z^2 + 2 + 1/z^2)/4 = (z^2 + 1/z^2)/4 + 1/2 = cos(2x)/2 + 1/2

a potem całe całkowanie sprowadza się do wyliczenia całek z: cos(kx), k = 1,2,... co jest przecież łatwe: int cos(kx)dx = 1/k sin(kx);

podobnie z sinusami: sinx = (z - 1/z)/2i