eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingBłędny epsilon - this is not a bug, this is ?Re: Błędny epsilon - this is not a bug, this is ?
  • Data: 2012-11-03 17:59:28
    Temat: Re: Błędny epsilon - this is not a bug, this is ?
    Od: Michoo <m...@v...pl> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    On 03.11.2012 10:14, slawek wrote:
    > Użytkownik "Michoo" napisał w wiadomości grup
    > dyskusyjnych:k71ct6$fjv$...@m...internetia.pl...
    >
    >> Jakbyś przed trollowaniem zadał sobie trud jego przeczytania to byś
    >> nie znowu pieprzył jak potłuczony. Współczesny sprzęt operuje
    >> wewnętrznie na liczbach 80 bitowych. [Chodzi o to, żeby zapewnić
    >> dostateczną precyzję na "zwykłym" double.]
    >
    > I znowu "mowa nienawiści", próba manipulacji - zamiast merytorycznej
    > wiedzy.

    Ty trollujesz jak karmię trolle - to chyba standard.

    >
    > Choćby o tym, jak wygląda architektura procesorów Itanium.

    I zapomniałem już że czepiasz się "domyślnych" dla innych szczegółów.
    Nie mówię o Itanium, nie mówię o NEONach, czy innych FVP. Jeżeli nie
    wspomniano inaczej to mówimy na tej grupie o FPU x86.

    No chyba, że Ty testowałeś na Itanium i nie raczyłeś o tym wspomnieć?

    >
    >> Obliczenia są przycinane w momencie konwersji do double, dla pełnej
    >> zgodności ze standardem niektóre kompilatory mają specyficzne opcje
    >
    > Gdyby były obcinane,

    Nie obcinane. "Przycinane" - znaczy się redukowanie bez wdawania się w
    szczegóły implementacji. (Tryb zaokrąglania można zresztą ustawić.)

    >
    > One są zaokrąglane - czyli także "w górę", ceil.

    Nie chce mi się sprawdzać, ale oidp jest to zaokrąglanie do
    najbliższego. Zresztą tylko taka forma by miała sens przy tej dyskusji o
    dokładności.

    >
    > I nie dlatego aby uzyskać zgodność ze standardem (dla tej zgodności
    > obliczenia musiałyby być przeprowadzane na liczbach 64-bitowych,

    Ale FPU nie liczy na 64 bitowych.

    > ewentualnie po każdym pojedynczym działaniu arytmetycznym przekształcane
    > na 64-bitowe, co da się zrobić np. w gcc jest -ffloat-store).

    Tak, właśnie o tym napisałem.

    >
    >> powodujące to przycięcie po każdej operacji, w przeciwnym razie ciąg
    >
    > Tym razem ja zachowam się nieładnie: przyciąć... to można palec szufladą.

    Loglan jest równie ścisły co mało użyteczny.

    >
    >> obliczeń w typie double. "Eksperymentalnie" możesz więc otrzymywać
    >> bzdury nie mające związku z formatem "double".
    >
    > Podsumowując - polski "informatyk" jest głęboko wierzący: woli wierzyć w
    > swoje wewnętrzne głębokie przekonanie we własną nieomylność , niż
    > zmierzyć się z rzeczywistością i zauważyć chociażby tak prosty fakt, jak
    > że 2.22E-16 nie równa się 1.11E-16.

    Gdzie ja się odnosiłem do tej wartości? Ja tylko napisałem ogólnie, że
    liczenie bez uwzględnienia platformy może dawać dziwne wyniki. To Ty
    wspomniałeś, że z manuala coś wynika, mimo, że go chyba nie czytałeś.

    >
    > "jednak dodanie, używając liczb double, 1.5E-16 i 1.0 daje więcej
    > niż 1.0".

    Tak. I jak Ci już wspomniano - w praktyce nie interesuje programisty
    dokładność maszynowa a odległość między dwiema liczbami, czyli 2*e.
    Komentarz jest błędny w nagłówku a dobry w matlabie.


    > Niemniej szacun - dołączyłeś do całkiem pokaźnego stadka osobników,
    > którym żaden jakiś tam Eksperyment nie będzie będzie mówił co mają robić.

    Wydaje ci się.

    --
    Pozdrawiam
    Michoo

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

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: