On Tue, 25 Mar 2014 10:43:50 +0100, IDKrzych <n...@p...onet.pl>
wrote:
> > Banki maja tendencje do długiego trzymania przy zyciu systemow
> > zbudowanych dawno temu przy uzyciu antycznych technologii ktore
juz
> > dawno przestały byc uwazane za wskazane dla "critical systems"
(np.
> > COBOL) albo dorobily sie lepszych zastepnikow (np. Excel VBA).


> a przepraszam co jest lepszym zastępnikiem dla Excel VBA?

C#, Python.

RW

do góry

On Wed, 26 Mar 2014 19:31:34 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> On 2014-03-26 18:00, pwola wrote:
> > Trzeba tylko pamietać, o ze jest to język skryptowy i ma sluzyć do
> > prezentacji wyników oraz generowania raportów PDF do wydruku i
> > arkuszy MS Excel dla tych co wolą VB ;)
> I znowu nie ma ani słowa o równaniach nielinowych.

Wyliczanie wypłaty z uwzględnieniem nadgodzin to też jest równanie
nieliniowe.

RW

do góry

On 2014-03-26, g...@g...com <g...@g...com> wrote:
>> > PHP powstal jako jezyk do tworzenia
>> > licznikow na stronach domowych, i trzeba mu przyznac, ze zaszedl daleko.
>> > Jednak wspolczesnie fakt, ze rzeczy zaawansowanych nie pisze sie w PHP,
>> > nie wynika juz z semantycznych niedostatkow tego jezyka, tylko z (w pelni
>> > zasluzonej) marnej reputacji PHP.
>>
>> ...która wynia w dużej części właśnie z semantycznych niedostatków.
>
> Historycznie. Wiele z tych niedostatkow zostalo juz poprawionych,

...w ciągu ostatnich czterech-sześciu lat, czyli już dawno po
terminie...

>> >> A coś, co potrafi podobne rzeczy do lispowych makr (manipulację drzewem
>> >> wyprowadzenia) występuje w całkiem sporej liczbie języków, od Pythona
>> >> zaczynając.
>> >
>> > Moglbys powiedziec cos wiecej na ten temat? Ew. rzucic jakims linkiem?
>> > (Jedyny jezyk z nielispowa skladnia, o jakim slyszalem, ze ma lispowe
>> > makra, to ruby-podobny jezyk o nazwie elixir)
>>
>> Uwaga: nie chodzi o makra w stylu Lispa, czyli coś, co się wywołuje jak
>> funkcję. Chodzi o manipulację drzewem wyprowadzenia danego języka
>> z możliwością wykonania takiego drzewa, ale nie musi to wyglądać jak
>> w Lispie.
>>
>> W Pythonie do tego służą moduły parser i ast. W Erlangu jest to zrobione
>> bardziej elegancko (parse_transform), bo tam proces kompilacji występuje
>> jawnie, więc można się w niego wpiąć.
>
> No to prawie jak w lispie :]

Dość blisko. Dokładnie lispowych nie będzie, bo prawie żadnego języka
się nie zapisuje jako drzewa wyprowadzenia, jak Lispa.

>> >> > Dlaczego glupio pomieszane? Jest jeden prosty interfejs i bardzo
>> >> > potezna struktura danych, ktora daje ci to, czego od niej oczekujesz.
>> >>
>> >> ...gwarancje czasowe?
>> >
>> > Jezeli piszesz "time-critical application", to zgadzam sie, ze PHP
>> > to zly wybor. Podobnie jak wybor wiekszosci innych jezykow dynamicznych
>> > oraz wszystkich jezykow z garbage collectorem.
>>
>> Ależ nie chodzi o aplikacje krytyczne czasowo. Chodzi o bardziej
>> elementarną rzecz: przewidywalne zachowanie w przypadku wzrostu ilości
>> danych. Nie chcę żeby nagle się okazało, że mój program *wyglądający*
>> jak mogący sobie poradzić z danymi osiem razy większymi w czasie jedynie
>> osiem razy dłuższym kończy pracę w czasie czterysta razy dłuższym.
>
> Takich gwarancji nie daje nawet C.
> A PHP pod tym wzgledem nigdy mnie nie zaskoczyl, chociaz robilem
> z nim naprawde dziwne rzeczy.

W C wiadomo, że dostęp do elementu w tablicy ma złożoność O(1). W PHP
nie wiadomo, bo przy tej mieszance nie-wiadomo-jakiej-mapy (hasz
z porządkiem to *nie jest* standardowa implementacja hasza) i tablicy
nie jestem w stanie powiedzieć, że złożoność jest O(F(n)).

>> >> A pomieszane głupio, bo nie potrzebuję indeksować tablicy stringami.
>> >> Potrzebuję mieć gwarancję dostępu w czasie O(1). Jak będę potrzebował
>> >> indeksowanie stringami, to sobie użyję hasza i będę wiedział, jakie on
>> >> daje gwarancje na operacje.
>> >
>> > Jezeli nie potrzebujesz indeksowac tablicy stringami, to nie musisz
>> > tego robic. Jezeli korzysasz ze spojnych kluczy numerycznych od 0, to
>> > bedziesz mial normalna tablice numeryczna z dostepem w czasie O(1)
>>
>> A gdzie są te gwarancje zapisane? W dokumentacji nie pamiętam żeby były.
>>
>> Czy tak tylko zmyślasz na temat gwarancji złożoności w PHP?
>
> Faktycznie w dokumentacji tego nie ma, i nie sadze, zeby PHP dawal
> gwarancje. (Jak stanowi licencja, THIS SOFTWARE IS PROVIDED
> BY THE PHP DEVELOPMENT TEAM ``AS IS'' AND ANY EXPRESSED OR
> IMPLIED WARRANTIES). Ale z tego co czytalem, to w praktyce
> tak wlasnie jest implementowane, co szybki risercz wydaje
> sie potwierdzac:
> http://stackoverflow.com/questions/2350361/how-is-th
e-php-array-implemented-on-the-c-level

Czyli chcesz powiedzieć, że mam się oprzeć o nieudokumentowane
zachowanie, które może się zmienić między patchlevelami? Naprawdę tak
uważasz? W swoim własnym kodzie tak robisz?

>> >> Tablice w PHP to jakby ktoś wymieszał B-drzewa z wyrażeniami
>> >> regularnymi. Można to trzymać razem, ale kto przy zdrowych zmysłach
>> >> potrzebuje takiej konstrukcji?
>> >
>> > Nie wiem, jaki jest zwiazek B-drzew z wyrazeniami regularnymi.
>> > Tablice php-owe opieraja sie na spostrzeniu, ze sekwencje rowniez
>> > stanowia forme asocjacji.
>>
>> Co nie znaczy, że to dobry pomysł mieszać haszmapy z tablicami, bo te
>> struktury mają różne zastosowanie, różną budowę i różnie się zachowują
>> przy większości operacji.
>
> Maja taki sam interfejs.

Nie. W haszu nie ma pojęcia pojęcia "połowa tablicy". W haszu nie ma
pojęcia "element 2*n+1", w każdym razie nie bez dziwnego, sztucznego
traktowania kontenera przez programistę ("umówmy się, że nie będę
robić X").

> Bystry kompilator moglby sam wpasc na to, kiedy uzyc jakiej struktury
> danych.

W PHP nie ma bystrego kompilatora (czy tam parsera). W PHP jest
interpreter, który jest tak głupi, że dla niego 0x0+2 = 4.
Interpreter PHP nawet nie konstruuje drzewa wyprowadzenia, tylko
uruchamia kod od razu w ramach akcji semantycznych.

> A z perspektywy uzytkownika nie musi miec znaczenia, czy uzywa
> drzewa, wektora czy haszmapy, i jezeli ktos moze tutaj cos pojeciowo
> namieszac, to tylko sam uzytkownik.

Dlaczego chcesz *zmuszać* użytkownika do stałego uważania jeszcze w tym
miejscu? W PHP jest wystarczająco dużo miejsc gdzie można się potknąć.
Dlaczego dokładać jeszcze to jedno? Bo na pewno nie dla wygody (w innych
językach hasz i tablica są rozdzielone i *nikt* nie narzeka).

--
Secunia non olet.
Stanislaw Klekot

do góry

> > Ależ nie chodzi o aplikacje krytyczne czasowo. Chodzi o bardziej
>
> > elementarną rzecz: przewidywalne zachowanie w przypadku wzrostu ilości
>
> > danych. Nie chcę żeby nagle się okazało, że mój program *wyglądający*
>
> > jak mogący sobie poradzić z danymi osiem razy większymi w czasie jedynie
>
> > osiem razy dłuższym kończy pracę w czasie czterysta razy dłuższym.
>
>
>
> Takich gwarancji nie daje nawet C.
>

ciekawa kwestia, ogolnie nie ma gwarancji, ogolnie przy wzroscie danych cczas
wykonania moze nawet spadac, ale warto pewnie przygladac sie jak zachowuja sie
konkretne i popularne kody w c w przewidywalnych sytuacjach, pewnie czesc jest
wielomianowa a czesc jest troche ponad liniowa,
Z natury liniowe kody sa chyba jednak liniowe i nie ma chyba czegos takiego ze kazdy
program liniowy staje sie w praktyce nieliniowy wraz ze wzrostem ilosci danych

do góry

W dniu czwartek, 27 marca 2014 02:28:31 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
> On 2014-03-26, g...@g...com <g...@g...com> wrote:
>
> > Historycznie. Wiele z tych niedostatkow zostalo juz poprawionych,
>
> ...w ciągu ostatnich czterech-sześciu lat, czyli już dawno po
> terminie...

A jaki byl termin?

> >> >> > Dlaczego glupio pomieszane? Jest jeden prosty interfejs i bardzo
> >> >> > potezna struktura danych, ktora daje ci to, czego od niej oczekujesz.
> >> >>
> >> >> ...gwarancje czasowe?
> >> >
> >> > Jezeli piszesz "time-critical application", to zgadzam sie, ze PHP
> >> > to zly wybor. Podobnie jak wybor wiekszosci innych jezykow dynamicznych
> >> > oraz wszystkich jezykow z garbage collectorem.
> >>
> >> Ależ nie chodzi o aplikacje krytyczne czasowo. Chodzi o bardziej
> >> elementarną rzecz: przewidywalne zachowanie w przypadku wzrostu ilości
> >> danych. Nie chcę żeby nagle się okazało, że mój program *wyglądający*
> >> jak mogący sobie poradzić z danymi osiem razy większymi w czasie jedynie
> >> osiem razy dłuższym kończy pracę w czasie czterysta razy dłuższym.
> >
> > Takich gwarancji nie daje nawet C.
> > A PHP pod tym wzgledem nigdy mnie nie zaskoczyl, chociaz robilem
> > z nim naprawde dziwne rzeczy.
>
> W C wiadomo, że dostęp do elementu w tablicy ma złożoność O(1). W PHP
> nie wiadomo, bo przy tej mieszance nie-wiadomo-jakiej-mapy (hasz
> z porządkiem to *nie jest* standardowa implementacja hasza) i tablicy
> nie jestem w stanie powiedzieć, że złożoność jest O(F(n)).

To mowimy o czasie, czy o zlozonosci?
Jezeli uruchamiasz cos na systemie ze stronicowaniem pamieci,
to tracisz wszelkie gwarancje czasowe (chyba ze korzystasz z jakichs
watkow czasu rzeczywistego). Na potrzeby praktyczne mozna uznac,
ze w PHP czas dostepu do tablicy jest rzedu O(1)

> >> >> A pomieszane głupio, bo nie potrzebuję indeksować tablicy stringami.
> >> >> Potrzebuję mieć gwarancję dostępu w czasie O(1). Jak będę potrzebował
> >> >> indeksowanie stringami, to sobie użyję hasza i będę wiedział, jakie on
> >> >> daje gwarancje na operacje.
> >> >
> >> > Jezeli nie potrzebujesz indeksowac tablicy stringami, to nie musisz
> >> > tego robic. Jezeli korzysasz ze spojnych kluczy numerycznych od 0, to
> >> > bedziesz mial normalna tablice numeryczna z dostepem w czasie O(1)
> >>
> >> A gdzie są te gwarancje zapisane? W dokumentacji nie pamiętam żeby były.
> >>
> >> Czy tak tylko zmyślasz na temat gwarancji złożoności w PHP?
> >
> > Faktycznie w dokumentacji tego nie ma, i nie sadze, zeby PHP dawal
> > gwarancje. (Jak stanowi licencja, THIS SOFTWARE IS PROVIDED
> > BY THE PHP DEVELOPMENT TEAM ``AS IS'' AND ANY EXPRESSED OR
> > IMPLIED WARRANTIES). Ale z tego co czytalem, to w praktyce
> > tak wlasnie jest implementowane, co szybki risercz wydaje
> > sie potwierdzac:
>
> > http://stackoverflow.com/questions/2350361/how-is-th
e-php-array-implemented-on-the-c-level
>
> Czyli chcesz powiedzieć, że mam się oprzeć o nieudokumentowane
> zachowanie, które może się zmienić między patchlevelami? Naprawdę tak
> uważasz? W swoim własnym kodzie tak robisz?

To zalezy, jaki problem chce rozwiazac. Ale jezeli tak niepokoi Cie kwestia
gwarancji, to:
1) zrodla PHPa sa dostepne, mozna sobie poczytac
2) nie musisz robic update'u do nowszej wersji, jezeli mialyby z tego
wynikac jakies problemy

> >> >> Tablice w PHP to jakby ktoś wymieszał B-drzewa z wyrażeniami
> >> >> regularnymi. Można to trzymać razem, ale kto przy zdrowych zmysłach
> >> >> potrzebuje takiej konstrukcji?
> >> >
> >> > Nie wiem, jaki jest zwiazek B-drzew z wyrazeniami regularnymi.
> >> > Tablice php-owe opieraja sie na spostrzeniu, ze sekwencje rowniez
> >> > stanowia forme asocjacji.
> >>
> >> Co nie znaczy, że to dobry pomysł mieszać haszmapy z tablicami, bo te
> >> struktury mają różne zastosowanie, różną budowę i różnie się zachowują
> >> przy większości operacji.
> >
> > Maja taki sam interfejs.
>
> Nie. W haszu nie ma pojęcia pojęcia "połowa tablicy". W haszu nie ma
> pojęcia "element 2*n+1", w każdym razie nie bez dziwnego, sztucznego
> traktowania kontenera przez programistę ("umówmy się, że nie będę
> robić X").

Tablice PHP zachowuja porzadek wprowadzania, wiec jest w nich
pojecie "polowa tablicy". Jezeli nie masz potrzeby robic z tego
uzytku, to mozesz ignorowac kwestie porzadku w haszach.

> > Bystry kompilator moglby sam wpasc na to, kiedy uzyc jakiej struktury
> > danych.
>
>
> W PHP nie ma bystrego kompilatora (czy tam parsera). W PHP jest
> interpreter, który jest tak głupi, że dla niego 0x0+2 = 4.
> Interpreter PHP nawet nie konstruuje drzewa wyprowadzenia, tylko
> uruchamia kod od razu w ramach akcji semantycznych.

To prawda. Ale to kwestia implementacji, a nie semantyki.
(Choc akurat jezeli idzie o kwestie semantyki, to to dopiero
jest bajzel).

> > A z perspektywy uzytkownika nie musi miec znaczenia, czy uzywa
> > drzewa, wektora czy haszmapy, i jezeli ktos moze tutaj cos pojeciowo
> > namieszac, to tylko sam uzytkownik.
>
> Dlaczego chcesz *zmuszać* użytkownika do stałego uważania jeszcze w tym
> miejscu? W PHP jest wystarczająco dużo miejsc gdzie można się potknąć.
> Dlaczego dokładać jeszcze to jedno? Bo na pewno nie dla wygody (w innych
> językach hasz i tablica są rozdzielone i *nikt* nie narzeka).

W PHPie nie sa rozdzielone, i tez nikt nie narzeka.
Jezeli ktos wie, jak korzystac z haszow, poradzi osobie z tablicami PHP.
Jezeli ktos wie, jak korzystac z tablic, tez sobie poradzi.

do góry

On 2014-03-27, g...@g...com <g...@g...com> wrote:
> W dniu czwartek, 27 marca 2014 02:28:31 UTC+1 użytkownik Stachu 'Dozzie' K.
napisał:
>> On 2014-03-26, g...@g...com <g...@g...com> wrote:
>>
>> > Historycznie. Wiele z tych niedostatkow zostalo juz poprawionych,
>>
>> ...w ciągu ostatnich czterech-sześciu lat, czyli już dawno po
>> terminie...
>
> A jaki byl termin?

Tak z piętnaście lat temu, kiedy Python zaczął dobrze zdobywać
popularność.

>> > Takich gwarancji nie daje nawet C.
>> > A PHP pod tym wzgledem nigdy mnie nie zaskoczyl, chociaz robilem
>> > z nim naprawde dziwne rzeczy.
>>
>> W C wiadomo, że dostęp do elementu w tablicy ma złożoność O(1). W PHP
>> nie wiadomo, bo przy tej mieszance nie-wiadomo-jakiej-mapy (hasz
>> z porządkiem to *nie jest* standardowa implementacja hasza) i tablicy
>> nie jestem w stanie powiedzieć, że złożoność jest O(F(n)).
>
> To mowimy o czasie, czy o zlozonosci?

O złożoności czasowej? Ja nie chcę pisać systemu czasu rzeczywistego, ja
chcę wiedzieć że system nie klęknie przy wzroście ilości danych.

> Jezeli uruchamiasz cos na systemie ze stronicowaniem pamieci,
> to tracisz wszelkie gwarancje czasowe (chyba ze korzystasz z jakichs
> watkow czasu rzeczywistego). Na potrzeby praktyczne mozna uznac,
> ze w PHP czas dostepu do tablicy jest rzedu O(1)

...z dokładnością do tego, że nie można, bo to nie jest normalna
tablica, a nigdzie nie ma deklaracji, że tak to będzie się zachowywać.

>> >> >> A pomieszane głupio, bo nie potrzebuję indeksować tablicy stringami.
>> >> >> Potrzebuję mieć gwarancję dostępu w czasie O(1). Jak będę potrzebował
>> >> >> indeksowanie stringami, to sobie użyję hasza i będę wiedział, jakie on
>> >> >> daje gwarancje na operacje.
>> >> >
>> >> > Jezeli nie potrzebujesz indeksowac tablicy stringami, to nie musisz
>> >> > tego robic. Jezeli korzysasz ze spojnych kluczy numerycznych od 0, to
>> >> > bedziesz mial normalna tablice numeryczna z dostepem w czasie O(1)
>> >>
>> >> A gdzie są te gwarancje zapisane? W dokumentacji nie pamiętam żeby były.
>> >>
>> >> Czy tak tylko zmyślasz na temat gwarancji złożoności w PHP?
>> >
>> > Faktycznie w dokumentacji tego nie ma, i nie sadze, zeby PHP dawal
>> > gwarancje. (Jak stanowi licencja, THIS SOFTWARE IS PROVIDED
>> > BY THE PHP DEVELOPMENT TEAM ``AS IS'' AND ANY EXPRESSED OR
>> > IMPLIED WARRANTIES). Ale z tego co czytalem, to w praktyce
>> > tak wlasnie jest implementowane, co szybki risercz wydaje
>> > sie potwierdzac:
>>
>> > http://stackoverflow.com/questions/2350361/how-is-th
e-php-array-implemented-on-the-c-level
>>
>> Czyli chcesz powiedzieć, że mam się oprzeć o nieudokumentowane
>> zachowanie, które może się zmienić między patchlevelami? Naprawdę tak
>> uważasz? W swoim własnym kodzie tak robisz?
>
> To zalezy, jaki problem chce rozwiazac. Ale jezeli tak niepokoi Cie kwestia
> gwarancji, to:
> 1) zrodla PHPa sa dostepne, mozna sobie poczytac
> 2) nie musisz robic update'u do nowszej wersji, jezeli mialyby z tego
> wynikac jakies problemy

Jeszcze lepiej, każesz mi pilnie śleldzić wnętrzności! Może zakończmy tę
dyskusję, bo o ile jestem tylko sysadminem, to to, co mi właśnie radzisz
o PHP kłóci się straszliwe ze wszystkim, co wiem o pisaniu softu,
a nawet ze zwyczajnym zdrowym rozsądkiem.

>> >> >> Tablice w PHP to jakby ktoś wymieszał B-drzewa z wyrażeniami
>> >> >> regularnymi. Można to trzymać razem, ale kto przy zdrowych zmysłach
>> >> >> potrzebuje takiej konstrukcji?
>> >> >
>> >> > Nie wiem, jaki jest zwiazek B-drzew z wyrazeniami regularnymi.
>> >> > Tablice php-owe opieraja sie na spostrzeniu, ze sekwencje rowniez
>> >> > stanowia forme asocjacji.
>> >>
>> >> Co nie znaczy, że to dobry pomysł mieszać haszmapy z tablicami, bo te
>> >> struktury mają różne zastosowanie, różną budowę i różnie się zachowują
>> >> przy większości operacji.
>> >
>> > Maja taki sam interfejs.
>>
>> Nie. W haszu nie ma pojęcia pojęcia "połowa tablicy". W haszu nie ma
>> pojęcia "element 2*n+1", w każdym razie nie bez dziwnego, sztucznego
>> traktowania kontenera przez programistę ("umówmy się, że nie będę
>> robić X").
>
> Tablice PHP zachowuja porzadek wprowadzania, wiec jest w nich
> pojecie "polowa tablicy".

Który z kluczy jest tym w "połowie tablicy"? I co to znaczy "zachowują
porządek wprowadzania"? Jak wprowadzę klucze 9, 8, 7, to będę miał
iterację w tej właśnie kolejności? (Co jest niedorzeczne, bo dla *tablicy*
powinna być rosnąca.) A może w kolejności 7, 8, 9? (Co jest
niedorzeczne, bo klucze-stringi są traktowane inaczej, zgodnie z tym co
mówisz.) W którą stronę się nie obrócić, sytuacja do dupy, bo
w pierwszym wyborze (mieszanie tablic z haszem) ktoś zj***ł sprawę.

> Jezeli nie masz potrzeby robic z tego
> uzytku, to mozesz ignorowac kwestie porzadku w haszach.

Ale to już dawno nie jest standardowy hasz, skoro zapamiętuje kolejność
wprowadzania kluczy. Z samego tego tytułu nie mogę nic powiedzieć
o złożoności czasowej operacji.

>> > Bystry kompilator moglby sam wpasc na to, kiedy uzyc jakiej struktury
>> > danych.
>>
>>
>> W PHP nie ma bystrego kompilatora (czy tam parsera). W PHP jest
>> interpreter, który jest tak głupi, że dla niego 0x0+2 = 4.
>> Interpreter PHP nawet nie konstruuje drzewa wyprowadzenia, tylko
>> uruchamia kod od razu w ramach akcji semantycznych.
>
> To prawda. Ale to kwestia implementacji, a nie semantyki.

Sam wyciągnąłeś kwestie implementacyjne. Aktualnie sprawa wygląda tak,
że PHP ssie jak odkurzacz.

>> > A z perspektywy uzytkownika nie musi miec znaczenia, czy uzywa
>> > drzewa, wektora czy haszmapy, i jezeli ktos moze tutaj cos pojeciowo
>> > namieszac, to tylko sam uzytkownik.
>>
>> Dlaczego chcesz *zmuszać* użytkownika do stałego uważania jeszcze w tym
>> miejscu? W PHP jest wystarczająco dużo miejsc gdzie można się potknąć.
>> Dlaczego dokładać jeszcze to jedno? Bo na pewno nie dla wygody (w innych
>> językach hasz i tablica są rozdzielone i *nikt* nie narzeka).
>
> W PHPie nie sa rozdzielone, i tez nikt nie narzeka.

Jak to nikt? Dużo tych, którzy znają cokolwiek więcej niż sam PHP.
To nie jest "nikt".

> Jezeli ktos wie, jak korzystac z haszow, poradzi osobie z tablicami PHP.
> Jezeli ktos wie, jak korzystac z tablic, tez sobie poradzi.

Nie ma "sobie poradzić". Ma się nie potykać *niepotrzebnie* o głupoty.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu czwartek, 27 marca 2014 15:44:10 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
>
> Jeszcze lepiej, każesz mi pilnie śleldzić wnętrzności! Może zakończmy tę
> dyskusję,

OK

do góry

>
>
>
> ciekawa kwestia, ogolnie nie ma gwarancji, ogolnie przy wzroscie danych cczas
wykonania moze nawet spadac, ale warto pewnie przygladac sie jak zachowuja sie
konkretne i popularne kody w c w przewidywalnych sytuacjach, pewnie czesc jest
wielomianowa a czesc jest troche ponad liniowa,
>
> Z natury liniowe kody sa chyba jednak liniowe i nie ma chyba czegos takiego ze
kazdy program liniowy staje sie w praktyce nieliniowy wraz ze wzrostem ilosci danych

w praktyce w jakims tam kodowaniu przemyslowym chyba spotyka si ejeszcze jeden rodzaj
opoznienia ;/ tj zwisanie albo lagowanie na jakichs zaleznych składnikach ;\ -
przynajmniej tak mi sie to kojarzy bo w zyciu nie pisalem tego raodzaju 'programow' a
wmoim peogramowaniu pod win32 szczesliwie wszystko jest jednak responsywne

do góry

On Wednesday, March 26, 2014 7:32:50 PM UTC+1, Sebastian Biały wrote:
> Ten branch zaczał się od tego że ponoć w jakimś banku *wybrano* PHP do
> implementacji czegoś związanego z równaniami nieliowymi w windykacji.

To już Twoja interpretacja. :)

w.

do góry

On Wednesday, March 26, 2014 7:58:22 PM UTC+1, Sebastian Biały wrote:
> Dodatkowo sugeruje uwzględnić że kazdy z przedziałów zawiera liczbę z
> zakresu <0,NDA> (żeby nie bylo za łatwo) którą należy w locie wyjąć z
> odwrócenia MD5 i umozliwić działanie w O(-1) zapewniając oczywiście że
> całość algorytmu zajmnie nie więcej jak 40 linijek co jasno pokaże jakie
> można, kurna, argumenty na grupie zapodać, co wciskają rozmówcę w ziemię.

Sam zacząłeś od wymyślonego przykładu z jakimś grafikiem dla sprzątaczek.
Podałem Ci, jaki napotkasz problem *alogrytmiczny*, nawet w tak pozornie
prostym zastosowaniu.

> > Jak to zrobisz z pomocą tej biblioteki boostowej? I jak to zrobisz
> > boostem, jeśli żądam, żeby test wykonał się czasie O(n log n)?
> > (Odpuszczam złożoność pamięciową, nie mam serca wymagać O(1)).
>
> Własnie zauważyleś za złożone problemy nie mają uniwersalnych rozwiązń.

To nie jest trudny problem, już sama klasa złożoności czasowej powinna
sugerować, jakie jest rozwiązanie. Da się rozwiązać bez boosta,
bez żadnej biblioteki, nawet w PHP-pie, czy javascripcie.

> A w wątku rzecz w tym że PHP nie ma żadnych rozwiązań w standardzie,
> nawet uniwersalnych. NAWET.

W tym wątku była mowa, że programista PHP nic nie musi umieć.

> >> Równległe zmiany w bazie obsługuje baza. Zazwyczaj. Bywa że jak nie
> >> obsługuje to się zmienia bazę (częste podejście wiekszych firm).
> > Nie na tym polega problem: masz dwa wątki (niechby i std::thread)
>
> W PHP? Jak to się stało że przytaczasz już dwa zadania w C++ jako
> argument w kierunku lepszości PHP?

W dyskusji jest pewien kontekst, bez kontekstu ciężko prowadzić rozmowę.
Cofnij się o dwa posty wstecz i spróbuj dojść skąd przykład z wątkami.

> > one sobie czytają z bazy, aktualne na daną chwilę, listę przedziałów,
> > sprawdzają czy mogą dodać nowy przedział i wtedy go dopisują; baza
> > danych nie weryfikuje poprawności (w sensie: constrainty w bazie).
> > Nie ma tutaj wzajemnego wykluczania wątków, więc baza może stać się
> > niespójna. To jest trudne w sytuacji webowej, gdzie nie ma mutexów.
>
> A czemu nie ma? I dlaczego powinienem workaroundowac problemy braku
> czegoś w designie tandemu apache/php/mysql?

Bo HTTP to protokół bezstanowy. Nie ma znaczenia, czy na końcu jest PHP,
Python, skrypt shellowy CGI, itd. - będzie dokładnie ten sam problem.

> >> Ja po 5 minutach zabawy dostałem w łeb =, ==, ===. Może kwestia
> >> szczęscia, nie wiem. Ale jakoś nie tylko ja narzekam.
> > Kwestia niezrozumienia. Praktycznie to samo jest w Pythonie, tylko
> > zamiast === masz słówko "is". W javascripcie też jest === i to dokładnie
> > to samo działanie. Niedobre w PHP jest to, że == sam z siebie rzutuje
> > w mało rozsądny sposób. BTW C++ też ma niejawne konwersje, które są
> > nieoczywiste.
>
> A kto tu twierdzi że C++ jest jakimś wzorcem?

Jako język wieloparadygmatowy, przemysłowy, z wieloletnią historią
i ciągle rozwijający się -- to dobre odniesienie do innych języków.

> >> Oni też potrafili się wykłucać że uniwersalny kontener na wszystko
> >> jest lepszy niż specjalizowane o znanych złożonościach "bo kto
> >> obrabia więcej niż 200 wpisów".
>
> > Akurat dość rozsądny argument. Przywołaj proszę jakiś mniej sensowny.
>
> Powiedz że żartujesz... to idealnie pasuje do profesjonalnego systemu
> zarządzania windykacjami w banku.

No jeżeli rzeczywiście nie obrabia się więcej niż "200 wpisów", nie
ma się specjalnych wymogów (czas, czy pamięć), to te uniwersalne są
lepsze. A nawet są lepsze w tym sensie, że już działają i ktoś je
przetestował. Ale oczywiście zgadzam się, że jeśli są szczególne
potrzeby, to trwanie przy uniwersalnych rozwiązaniach nie jest dobre.

> Ale jak ja mam mieć dłuższą przygode? Sugerujesz że mam się umartwiać
> nad PHP i dopiero dostrzegać błedy po 10 latach? Miej że litość, życie
> jest za krotkie na babranie się w g...

Nic nie musisz, tylko wydawanie kategorycznych sądów o teraźniejszości
na podstawie doświadczeń sprzed kilku lat jest trochę bez sensu.

> Ustawienia phpini w apache mają wpływ na runtime PHP. Jak chcesz różne
> to ... no cóż ...

To są ustawienia serwera, a nie przeglądarki. Pomieszałeś. :)

> > Sorry, ale nie dostaniesz dostępu do bankowego intranetu. Ja też już
> > nie mam szans, więc nie zadowolę nikogo w tym wątku.
>
> Znaczy że były tam te krzywe rownania

Były.

> czy nie było i mowisz o jeszcze jednym z miliona widoku na bazę danych?

A to też było, nie przeczę.

w.

do góry