🚀 go-pugleaf

> Pan uwaznie to czytal...?

W miare uwaznie.
Co w tym takiego dziwnego ?
Malo to nawet samych algorytmow bywalo delikatnie mowiac
"nie dzialajacych zgodnei z zalozeniami" ?

> Pewnie mnostwo publikacji wciaz zawiera ten sam blad.

Normalka.
Copy & Paste based development

> Nie jest wiec to problem jednej skopanej implementacji.

Powiem tak.
W numeryce az sie zawsze roilo od przypadkow
(a + b + c) * z /  y

To do programisty nalezalo temu podobne wyraznienia
tak napisac, aby nie wystapil overflow ani NAN ani INF itp.

Daletego uwazam dalej ze jest to spie.. implementacja
a nei algorytm.
(niewazne kto ja napisal: autor algorytmu czy podrzedny programista
jak np ja).

Teoterycznie/matematycznie (nie wnikajac w nature intow longow
czy innych, zapis (a + b)  integer_divide 2 jest przeciez poprawny

A to co oni kombinuja z ta naprawa w Javovej implementacji
wola o pomste do nieba.

<cytat>
The bug is in this line:

 6:             int mid =(low + high) / 2;So what's the best way to fix the 
bug? Here's one way: 6:             int mid = low + ((high - low) / 2);
Probably faster, and arguably as clear is:

 6:             int mid = (low + high) >>> 1;
In C and C++ (where you don't have the >>> operator), you can do this:

 6:             mid = ((unsigned) (low + high)) >> 1;<cytat>

Czy nie mozna po prostu ?:
 6:             int mid =((long)low + (long)high) / 2;Z w/w ich poprawek 
podoba mi sie jedynie ta:

6:             int mid = low + ((high - low) / 2);


(w C++ juz tak latwo nie ma)

PS: a ta ksiazke Bentley "Programming Pearls" mam od bardzo dawna

AK