eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programming › Program cosinusowej transformaty Fouriera
Ilość wypowiedzi w tym wątku: 246

  • 191. Data: 2011-03-12 23:09:33
    Temat: Re: Program cosinusowej transformaty Fouriera
    Od: A.L. <l...@a...com>

    On Sat, 12 Mar 2011 20:27:16 +0100, Sebastian Biały
    <h...@p...onet.pl> wrote:

    >On 2011-03-12 18:42, A.L. wrote:
    >> Nie, drogi Kolego. Jakies 40 lat temu w dziedzinie makroporcesorow
    >> robiono rzeczy takie o ktorych makrogeneratorowi C++ zwanemu
    >> "templates" nawet sie nie sni.
    >
    >Generatory kodu we wszelakiej postaci mocno odbiegają od tematu wątku.
    >Ale tak, stosuje sporadycznie. Zaryzykuje że sa słabo związane z
    >konkretnym językiem.

    Makro a generatory kodu to dwie zupelnei inne rzeczy

    A.L.


  • 192. Data: 2011-03-12 23:46:02
    Temat: Re: Program cosinusowej transformaty Fouriera
    Od: Andrzej Jarzabek <a...@g...com>

    On Sat, 12 Mar 2011 23:48:47 +0100, Wit Jakuczun
    <w...@g...com> wrote:
    > > To co w takiej sytuacji byłoby zgodne ze zdrowym
    > > rozsądkiem?
    > Oddać cesarzowi co cesarskie, czyli kawałek funkcyjny napisać
    > w języku funkcyjnym. Albo kawałek programowania
    > w logice w języku, który to wspiera, np. w prologu.

    To by było dopiero sprzeczne ze zdrowym rozsądkiem. Samo
    przeniesienie danych wymagałoby o wiele więcej wysiłku, niż
    zakodowanie tego w C++.


  • 193. Data: 2011-03-12 23:49:05
    Temat: Re: Program cosinusowej transformaty Fouriera
    Od: Wit Jakuczun <w...@g...com>

    W dniu 2011-03-13 00:46, Andrzej Jarzabek pisze:
    > On Sat, 12 Mar 2011 23:48:47 +0100, Wit Jakuczun
    > <w...@g...com> wrote:
    >> > To co w takiej sytuacji byłoby zgodne ze zdrowym
    >> > rozsądkiem?
    >> Oddać cesarzowi co cesarskie, czyli kawałek funkcyjny napisać
    >> w języku funkcyjnym. Albo kawałek programowania
    >> w logice w języku, który to wspiera, np. w prologu.
    >
    > To by było dopiero sprzeczne ze zdrowym rozsądkiem. Samo przeniesienie
    > danych wymagałoby o wiele więcej wysiłku, niż zakodowanie tego w C++.
    Zakodowanie czego?

    Pozdrawiam,
    Wit


  • 194. Data: 2011-03-13 01:02:05
    Temat: Re: Program cosinusowej transformaty Fouriera
    Od: Andrzej Jarzabek <a...@g...com>

    On 12/03/2011 23:49, Wit Jakuczun wrote:
    > W dniu 2011-03-13 00:46, Andrzej Jarzabek pisze:
    >>> > To co w takiej sytuacji byłoby zgodne ze zdrowym
    >>> > rozsądkiem?
    >>> Oddać cesarzowi co cesarskie, czyli kawałek funkcyjny napisać
    >>> w języku funkcyjnym. Albo kawałek programowania
    >>> w logice w języku, który to wspiera, np. w prologu.
    >>
    >> To by było dopiero sprzeczne ze zdrowym rozsądkiem. Samo przeniesienie
    >> danych wymagałoby o wiele więcej wysiłku, niż zakodowanie tego w C++.
    > Zakodowanie czego?

    Kawałka funkcjonalności, który napisałem w stylu funkcyjnym, bo kaurat
    tak było najwygodniej/najbardziej elegancko/najbezpieczniej/najczytelniej.


  • 195. Data: 2011-03-13 01:14:25
    Temat: Re: Program cosinusowej transformaty Fouriera
    Od: Andrzej Jarzabek <a...@g...com>

    On 11/03/2011 04:14, Jacek wrote:
    > Dnia Thu, 10 Mar 2011 23:22:11 +0000, Andrzej Jarzabek napisał(a):
    >
    >> On Wed, 9 Mar 2011 13:50:44 +0100, Jacek<a...@o...pl> wrote:
    >>> VBA calkiem przyjemny w uzyciu do tego, do czego
    >>> zostal stworzony.
    >>
    >> Miałem otóż ostatnio przyjemność używać, i była to przyjemność
    >> bardzo wątpliwa.
    >
    > Moglbys doprecyzowac?

    Na dzień dobry składnia jest strasznie kaszaniasta: np. dosyć podobne
    wywołania metod czasem trzeba poprzedzić instrukcją Call, a czasem nie,
    w zależności od liczby argumentów. Tak w ogóle strasznie głęboko się nie
    wgryzałem, ale nawet przy banalnie prostych skryptach człowiek się
    natyka na takie dziwactwa.


  • 196. Data: 2011-03-13 01:57:37
    Temat: Re: Program cosinusowej transformaty Fouriera
    Od: Andrzej Jarzabek <a...@g...com>

    On 12/03/2011 16:32, Sebastian Biały wrote:
    > On 2011-03-12 16:44, Andrzej Jarzabek wrote:
    >>>>> b) Jest obiektowy albo nie, jak kto woli.
    >>>> To jest raczej wada.
    >>> Dlaczego?
    >> W skrócie: bo do nauki programowania obiektowego lepszy jest język tylko
    >> obiektowy, a do nieobiektowego - w ogóle nie obiektowy.
    >
    > Ale C++ jest porzadnie obiektowy,

    Tak sobie...

    > porządnie nieobiektowy i troche
    > funkcyjny jak na jezyki klamrowe.

    No ale właśnie piszę - łączenie tego wszysztkiego w tym zastosowaniu
    jest wadą, bo niepotrzebnie komplikuje język.

    >>> Jesli chcesz pokazać bebechy - zaleta. Jesli nie chcesz - zaleta.
    >> Jeśli się chce pokazać bebechy, to jaką zaletą jest, że pozwala "jak się
    >> chce albo nie"?
    >
    > Zamiast w języku 1 opisywać częsc problemów a w języku 2 inną część
    > można wszystko pokazac w jednym oszczędzając czas i klarując rozwiązania.

    Można, ale ani w ten sposób nie oszczędzisz czasu, ani nie otrzymasz
    klarowniejszych rozwiązań. Stracisz na jednym i drugim pakując się w
    nieistotne szczegóły. Lepiej do nauki określonych klass zagadnień
    stosować małe, proste języki, które dobrze te zagadnienia wspierają bez
    kompromisów w celu wspierania innych rzeczy.

    >>> A kto mowi o programowaniu funkcyjnym w C++? Ja mówie że jak trzeba to
    >>> też da się.
    >> To, że coś "da się" nie jest zaletą, jeśli chodzi o walory dydaktyczne.
    >
    > Nie zgadzam się. Część typowych problemów algorytmicznych wygodnie jest
    > rozwiązywać funkcyjnie. Ale tylko część. Stosowanie na siłę języka
    > funkcyjnego tylko po to bo połowa problemu jest funcyjna jest po prostu
    > niezrozumiałe i mało sensowne.

    No ale przecież masz małe i dobre języki do uczenia rzeczy na przecięciu
    programowania funkcyjnego i imperatywnego. Np. Scheme.

    >> Ale są języki, z którymi łatwiej. Nikt nie proponuje Pascala do nauki
    >> programowania funkcyjnego.
    >
    > Ja też nie. W przeciwienstwie jednak do twardogłowych widze że typowe
    > zagadnienia projektowania/programowania są rozmyte pomiedzy funkcyjnośc,
    > obiektowość i strukturalność.

    A ja mówię o tym, że żeby pisać poezję, najpierw dobrze jest opanować
    alfabet. I do tego lepiej nadają się małe i proste języki skupione na
    realizacji określonego paradygmatu czy nawet określonych założeń
    dydatktycznych.

    > W Pascalu i paru innych jezykach o ściśle
    > nakiewanym celu musisz naginać naturanle rozwiązania w kierunku czegoś
    > konkretnego. W C++ w sortowaniu mogę sobie napisać strukturalny sorter
    > przyjmujący obiekty który przyjmie lambdę do komparacji. To jest
    > naturalne i oczywiste. Dlaczego mam się męczyć z "łatwiejszym sporobem
    > programowania"?

    Bo jak nie umiesz, to łatwiejszy sposób jest łatwiejszy.

    >> Z językami bez ogromnego wsparcia też może czerpać wiedzę. Jeśli nie
    >> może czerpać gotowców, to raczej zaleta tych języków.
    >
    > Nie. To wygląda inaczej: "Heniek, poszukaj na necie jakiegoś quick sorta
    > do pascala". "ok". "O k.... nie działa, ale gówno, napiszmy bąbelkowo i
    > h...". Algorytm był inny ale cytat autentyczny z całkiem sporej firmy
    > robiącej całkiem spore rzeczy. I dotyczył kryptografii.

    Ale przecież ja nie postuluję stosowania Pascala w przemyśle. W
    wariancie edukacyjnym wygląda to tak, że student nie znajduje quick
    sorta w pascalu, a nie rozumie ze znalezionych opisów i kodu w innych
    językach jak go zaimplementować, to polewa kurs.

    >> Standardowy Pascal jest chyba dość przenośny?
    >
    > Standardowy Pascal to średniowiecze.

    I co za problem? Nie nadaje się do nauczenia jak wygląda lista albo jak
    działa quicksort?

    >> Nie chodzi o pokazywanie cech języka, tylko na czym np. polega lista
    >> dwukierunkowa. Zrobienie tego na konkretnym przykładzie jest ok.
    >
    > - Panie Profesorze, a jak by tu można bylo zrobić real?
    > - Napisać na nowo dla real!

    I ok, bo leksja o tym, jak zrobić, żeby nie pisać na nowo to osobny
    temat i można się go uczyć na osobnym języku. I ten temat znacznie
    łatwiej przyswoić, jak się robiło konkretną strukturę dla Integer albo
    Payload = Record.

    >> No ale zauważ, że dydaktyka właśnie polega na tym, że uczysz kogoś bez
    >> wiedzy i obeznania. I że tę wiedzę się nabywa w określonej kolejności.
    >
    > Dlatego najlepiej nauczyć operatora koparki kopania rowu łyżką. Co
    > prawda nie przyda mu się to w praktyce, ale machania pod odpowiednim
    > kątem się nauczy, nie?

    Jeśli chodzi o naukę kopania rowów, to nie będę się kłócił, bo na pewno
    znasz się lepiej.

    >>> Złośliwy. Osoby ktore przechodziły "kursy" pascala na uczelniach w pl
    >>> zapewne będą to rozumialy.
    >> Ja przechodziłem, ale nie mam pojęcia o czym mówisz.
    > Gratuluje wykładowców.

    A na innych uczelniach uczą, że tylko bubblesort? Bo tylko do tego się
    Pascal nadaje?


  • 197. Data: 2011-03-13 01:59:01
    Temat: Re: Program cosinusowej transformaty Fouriera
    Od: Andrzej Jarzabek <a...@g...com>

    On 12/03/2011 16:50, Grzegorz Krukowski wrote:
    > On Sat, 12 Mar 2011 16:19:43 +0000, Andrzej Jarzabek
    > <a...@g...com> wrote:
    >
    > OK, słowo polskiego polityka, że nie będę się z ciebie śmiał - o co
    > chodzi z tym sortowaniem bąbelkowym. Za karę kazali ci to w Pascalu
    > pisać, czy co? ;)

    To przecież nie jak napisałem <ildsgv$jlr$1@news.onet.pl>


  • 198. Data: 2011-03-13 05:19:06
    Temat: Re: Program cosinusowej transformaty Fouriera
    Od: Jacek <a...@o...pl>

    Dnia Sun, 13 Mar 2011 01:14:25 +0000, Andrzej Jarzabek napisał(a):

    > On 11/03/2011 04:14, Jacek wrote:
    >> Dnia Thu, 10 Mar 2011 23:22:11 +0000, Andrzej Jarzabek napisał(a):
    >>
    >>> On Wed, 9 Mar 2011 13:50:44 +0100, Jacek<a...@o...pl> wrote:
    >>>> VBA calkiem przyjemny w uzyciu do tego, do czego
    >>>> zostal stworzony.
    >>>
    >>> Miałem otóż ostatnio przyjemność używać, i była to przyjemność
    >>> bardzo wątpliwa.
    >>
    >> Moglbys doprecyzowac?
    >
    > Na dzień dobry składnia jest strasznie kaszaniasta: np. dosyć podobne
    > wywołania metod czasem trzeba poprzedzić instrukcją Call, a czasem nie,
    > w zależności od liczby argumentów. Tak w ogóle strasznie głęboko się nie
    > wgryzałem, ale nawet przy banalnie prostych skryptach człowiek się
    > natyka na takie dziwactwa.

    You are not required to use the Call keyword when calling a procedure.
    However, if you use the Call keyword to call a procedure that requires
    arguments, argumentlist must be enclosed in parentheses. If you omit the
    Call keyword, you also must omit the parentheses around argumentlist. If
    you use either Call syntax to call any intrinsic or user-defined function,
    the function's return value is discarded.


  • 199. Data: 2011-03-13 07:02:51
    Temat: Re: Program cosinusowej transformaty Fouriera
    Od: "Waldek M." <w...@l...localdomain>

    Dnia Sat, 12 Mar 2011 18:53:22 +0100, Sebastian Biały napisał(a):

    > On 2011-03-12 18:02, slawek wrote:
    >>> To akurat katastrofa w rękach studenta ;)
    >> Nie pytałem o studenta. Pytałem: czy jest to w Delphi?
    >
    > Nie ma wielobazowego dziedziczenia. W Javie też. To raczej lepiej niż
    > gorzej. Dziedziczenie z definicji jest żadko potrzebne, a jeszcze
    > wielobazowe ...

    E? Dziedziczenie jest z definicji *rzadko* potrzebne?
    A co to za definicja?

    Waldek


  • 200. Data: 2011-03-13 08:10:19
    Temat: Re: Program cosinusowej transformaty Fouriera
    Od: Sebastian Biały <h...@p...onet.pl>

    On 2011-03-12 22:13, Przemek O. wrote:
    > W dniu 2011-03-12 07:57, Sebastian Biały pisze:
    >> a) nie ma sensownego miejsca w przemysle (traci na rzecz głównie Java/C#)
    > Po pierwsze, Delphi nigdy nie miało sensownego miejsca w przemyśle, bo
    > nie do tego jest/było stworzone.

    Przemysł != automatyka. Przemysłem jest też drukowanie faktur.

    >> b) brak metaprogramowania (cast hell)
    > I dobrze. Czym innym jest wynikowy program natywny, a czym innym
    > kompilowany do kodu pośredniego. Niemniej podobną funkcjonalność osiąga
    > się w inny sposób.

    Kod pośredni nie ma nic wspólnego z metaprogramowaniem. Co ciekawe chyba
    w 2009 coś tam w Delphi dłubano przy genarykach ale nie wiem z jakim
    skutkiem. Na pewno skutek to żaden dla dydaktyki.

    >> c) nieprzenosny
    > Tak samo jak i C/C++/C$ z VS jeśli odwołuje się do zasobów specyficznych
    > dla systemu operacyjnego. Nie rób tego w Delphi i też będzie przenosny.

    Delphi jest nieprzenośny z definicji. C/C++ z głupoty.

    >> d) wsparcie spadające asymptotycznie do zera
    > Jakiś konkret? Bo żaden z poważnych dostawców bibliotek/frameworków,
    > sterowników dla urządzeń które miały wsparcie dla Delphi nie zrezygnował
    > z niego. Ba w nowych wersjach powstają nawet nowe rozwiązania o których
    > do tej pory można było w Delphi pomarzyć.

    Cały czas rozmawiamy w kontekście dydaktyki. Interesuje mnie wsparcie w
    postaci pieryliarda rozwiązanychproblemów.

    > Cienko ze znajomością. Może dlatego, że dla Delphi takie biblioteki
    > (poważne) są w większości płatne, bo to środowisko komercyjne. A może
    > właśnie o to chodzi? Że nie ma darmowych?

    - Panie profesorze, może na jutrzejszych zajęciach coś powiemy o mapach?
    - To proszę zrobić składkę.

    > Sam vector jest zrozumiały, ale zapis array of integer nawet tłumaczony
    > z angielskiego na polski już coś znaczy.

    Jeśli to jest istotne dydaktycznie to poponuje COBOLa.

    > Po pierwsze, jeśli by tworzyć oprogramowanie zgodne z koncepcją RAD to
    > GC nie jest potrzebne, bo nie licząc wywalenia się programu nie ma
    > możliwości żeby coś gdzieś wyciekło.

    Jeśli piszesz logikę typu "onclikc() { sql.execute() }" to faktycznie.
    Jesli potrzebujesz obrobić dane *nie* sqlem to już by się przydało.

    > Zresztą samo GC nie jest żadnym rozwiązaniem, a w sumie to jest większym
    > problemem. Nie wiem czy pamiętasz jak pojawił się .NET. Z wielkim hura
    > skoczyliśmy do pisania aplikacji w tym czymś. I co się okazało, że
    > aplikacje mają zwiechy w dowolnym momencie, trwające zauważalny czas. Co
    > było przyczyną? Ano - słabe komputery, windows 98SE i nieszczęsne
    > zwalnianie zasobów przez GC.

    Zwiechy podczas zwalniania formy z steka przycisków jakoś nie stanowią
    problemu dla usera bo to nie są aplikacje *real* time.

    > Mówisz, że w Delphi robi się problemy typu "wystawianie faktur". Może
    > zaciekawi Cię, że firma notowana na WIG20 ma cały system obsługujący
    > całą firmę produkcyjną. I to system nowy, a nie rozwijany od lat. I ma
    > możliwość modyfikacji samego siebie i to w trakcie pracy. I jeszcze
    > wiele możliwość których jak twierdzisz w wymierającym języku nie da się
    > zrealizować.

    Z pamiętnika managera:

    Mamy 40 developerów znających się na Delphi.

    a) zwalniamy wszystkich i zatrudniamy studentów pisząc w C#

    b) męczymy się w Delphi bacznie patrząc ko będzie jutro właścicielem

    Co wybrać, hmmm ...

    >> Zupełnie jak oprogramowanie napisane w C++, Javie, C#. Lisp na ten
    >> oprzykład lata w kosmos. W dodatku miałem okazję rozmawiać z programista
    >> który popełnił fragment sterownika do rezonanu magnetycznego w ...
    >> VisualBasicu.
    > No i? Przecież to Ty starasz się udowodnić że w Delphi się już nic nie
    > pisze, a teraz wypisujesz że zupełnie jak pisane w C++, Javie itd. To w
    > końcu jak jest?

    Jak jest wiedzą statystyki. Ja ch nie mam. Mam poszlaki.

    > W Delphi też można użyć odpowiednią bibliotekę i wykonać po prostu sort,
    > bez konieczności jego implementacji.

    Bo delphi to taki soft do pisania onklików. Jakiekolwiek "wypasione"
    algorytmy kosztuja pieniądze. Mocno to dydaktyczne.

strony : 1 ... 10 ... 19 . [ 20 ] . 21 ... 25


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: