🚀 go-pugleaf

> Także u mnie nie obserwuję "efektu sekund". Pewnie problem z glibc
> (tak, zdarzają się takie).


Z tego co doczytałem, pod Windowsem te funkcje obsługuje biblioteka MSVC Runtime - i pewnie tam są bugi... I dobrze, bo była okazja do rozkminy tematu. :-)

W ogóle chętnie przesiadłbym się na Linuksa, ale trzyma mnie CAD i Excel, do którego mam cały worek makr.
A już najlepiej, żeby był z podpiętym CDE - tyle, że chodziłby na nim co najwyżej soft, który bym sobie sam napisał... :-P



> zrobić swoje funkcje, lepiej pasujące do danych


Popełniłem wstępnie funkcję konwertującą double na stringa.
Dzieli liczbę na część rzeczywistą i ułamkową, a potem wyświetla do czterech miejsc po przecinku w ustawionym "na chama" buforze, ale narazie nie chodzi o finezję, tylko o przetestowanie rozwiązania:

//------------------------------------------------------------------------------
inline void DoubleToString(double dValue, char* cBuffer)
{
double dRnd;
unsigned int iReal, val;
char *ptr, *dot;

   ptr = cBuffer + 15;
   dot = cBuffer + 10;
   *ptr = '\0';
   *dot = '.';

   dRnd = dValue + 0.00005; // zaokrąglenie czwartej cyfry
   iReal = (int)dRnd;

   val = (int)((dRnd - iReal) * 10000.0); // część ułamkowa *)
   while (val)
   {
      *--ptr = char(val % 10) | '0';
      val /= 10;
   }

   while (--ptr > dot) // zera do przecinka
      *ptr = '0';

   val = iReal; // część rzeczywista
   while (val)
   {
      *--ptr = char(val % 10) | '0';
      val /= 10;
   }
   
   
   while (ptr > cBuffer) // spacje do początku
      *--ptr = ' ';
}
//------------------------------------------------------------------------------

W porównaniu do sprintf() wykonuje swoją pracę... piętnastokrotnie szybciej, więc tu jest jak najbardziej git! :-)
Od zwycięzcy: https://github.com/miloyip/dtoa-benchmark jest ponad trzykrotnie szybsza - nic zresztą dziwnego, bo tamten algorytm używa int-ów 64-bitowych, co w programie 32-bitowym musi kosztować.

Boję się tylko o jedno - że w linijce *) w jakimś perfidnym przypadku (liczby praktycznie całkowitej) pojawią się mikroskopijne błędy zaokrągleń, które jednak spowodują "przekręcenie" części ułamkowej względem rzeczywistej i zamiast 10.0000 wyjdzie 10.9999, czy jakoś tak.
Póki co katuję algorytm paczkami po kilkaset milionów liczb wygenerowanych według rozmaitych kluczy i porównuję wynik ze sprintf() - do tej pory NIGDY nie wywalił błędu (jedyne co kilka razy wyłapał, to różnicę na czwartym miejscu po przecinku dla liczb XXXXXX.XXXX5000...).
Ale że tu nie ma miejsca na żadne tego typu wypadki, to się boję... ;-)

No i znowu - miało być krótko... ;-)

Jest fajna instrukcja FISTTP, ale dopiero od późnego Pentium 4.