Konwersja real48 na double

Witam
Czy w nowych wersjach Delphi dla .net są funkcje wspierające konwersję typu real48. Na codzień korzystam z c#, ale mam jeszcze trochę natywnego kodu i taki ładny kwiatek z którym nie wiem jak sobie poradzić

jaką konwersję???

var
  r: Real48;
  d: Double;
begin
  r := 123.45;
  d := r;
  //i tutaj masz inną wartość w d niż 123.45??

BTW kto używa delphi for net?

Ohoh, raz Misiekd nie ma racji :)

Real48

Typ Real48 nie istnieje w Delphi dla .NET.

Więc najlepiej przepisz/wywal ten kod, w sumie to nie wiem czy takie duże modyfikacje są wymagane między real48 a double.

Jeżeli chodzi o czytanie/pisanie tego typu, to napisz sobie od tego jakąś prockę najlepiej która Od razu to zrobi na double.

ja wiem, że go nie ma w d for net ale mnie co innego zastanawia - w "normalnym" delphi nie potrzeba robić żadnej "konwersji" - działa tak jak napisałem wcześniej. Jedynie problem może być jeśli autor ma pliki typowane, gdzie występuje real48 (chociaż nie wiem co skłoniło kogoś aby tak zrobić). Tu wystarczy napisać prosty konwerter, który otworzy plik typowany "po staremu", tzn z real48 i zapisze "po nowemu", np z typem double.

Mam w tej chwili program w c# dla .net, który czyta pliki binarne z danymi zapisanymi w formacie liczb real48 korzystając z natywnej biblioteki zrobionej w delphi do konwersji.
Rozwiązanie mało eleganckie i stwarzające swoje problemy ale ma dwie zalety:

1. Łatwe w implementacji
2. Zachowana jest maksymalna dokładność w konwersji (bardzo ważne)
   W googlach sporo jest różnych dziwnych procedurek do konwersji w obie strony, ale ze względu na pkt.2 nie odważyłem się ich stosować, zwykle są one dość zagmatwane. Wolałbym skorzystać z czegoś pewniejszego, a czymś takim wydają się być funkcje biblioteczne producenta kompilatora

1. Zachowana jest maksymalna dokładność w konwersji (bardzo ważne)

Bardzo ważna jest dokładność i dlatego używasz real48? To tak jakbym powiedział: Chcę móc przechowywać bardzo duże liczby i dlatego zastosuje typ byte albo lepiej shortint. Genialne. Ja jakbym chciał mieć bardzo wysoką dokładność to napisałbym swój moduł ułamków zwykłych i dużych liczb.

W googlach sporo jest różnych dziwnych procedurek do konwersji w obie strony, ale ze względu na pkt.2 nie odważyłem się ich stosować, zwykle są one dość zagmatwane. Wolałbym skorzystać z czegoś pewniejszego, a czymś takim wydają się być funkcje biblioteczne producenta kompilatora

Czyli im dłuższa procedura tym mniej dokładny wynik daje? wow. Problem leży w tym że funkcje biblioteczne producenta kompilatora nie są dostępne pod .NET . Proste, ale ty oczekujesz magii?

@123 Rozumiem, że musisz się wymądrzać ale może przydałoby się trochę mniej emocji, a więcej uważnego czytania ze zrozumieniem.

1. Używam real48 bo muszę, mam takie pliki do przeczytania i już. Gdybym nie musiał to skorzystałbym z typów bardziej współczesnych i nie kombinowałbym z natywnymi bibliotekami.
2. Napisałem o dokładności konwersji z jednego typu na drugi. Jest sporo różnych algorytmów, nie wiem jakim obarczone są błędem konwersji, że nie wspomnę o błędach w algorytmach.
3. Chciałem dowiedzieć się tylko czy w Delphi dla .net są dostępne biblioteki z funkcjami do konwersji, pozwalałoby to na napisanie biblioteki działającej w środowisku zarządzanym.

@123 Rozumiem, że musisz się wymądrzać ale może przydałoby się trochę mniej emocji, a więcej uważnego czytania ze zrozumieniem.

Masz rację, troche mnie już ponosi jak czytam te wszystkie mądre wypowiedzi.

1. Używam real48 bo muszę, mam takie pliki do przeczytania i już. Gdybym nie musiał to skorzystałbym z typów bardziej współczesnych i nie kombinowałbym z natywnymi bibliotekami.

No to czemu się martwisz o dokładność która i tak będzie nic nie warta? Nie uzyskasz z dupnych danych wejściowych super dokładnych wyników. Więc po co w ogóle się martwisz o to. Nie rozumiem. Jakby ci zależało na dokładności to byś załatwił te dane w double.

1. Napisałem o dokładności konwersji z jednego typu na drugi. Jest sporo różnych algorytmów, nie wiem jakim obarczone są błędem konwersji, że nie wspomnę o błędach w algorytmach.

To ja proponuje pokazać nam/przetestować pare i wybrać najlepszy, to chyba logiczne. Btw. nie wiem jakie to 'różne' algorytmy, których jedynym zadaniem jest przekopiowanie odpowiednich bitów w odpowiednie miejsce... A błędy, to tylko twoje domysły w których zapewne nie ma żadnej prawdy.

1. Chciałem dowiedzieć się tylko czy w Delphi dla .net są dostępne biblioteki z funkcjami do konwersji, pozwalałoby to na napisanie biblioteki działającej w środowisku zarządzanym.

Jeżeli Help i google o tym milczy (a zakładam że to już sprawdziłeś), to wątpie żeby ktokolwiek tutaj miał wiedzę wykraczającą poza to (zwłaszcza że real48 to prehistoria). Wydaje mi się że to pytanie jest bezcelowe, bo to co inni zrobią to najwyżej googla przeszukają (co już zrobiłeś).

Podczas konwersji liczb całkowitych na całkowite nie ma problemu. Z rzeczywistymi już ne ma tak łatwo. Zdarzyło mi się nie raz (z pewnością Tobie też) zapisać liczbę całkiowitą do bazy danych w pole typu rzeczywistego, a odczytać wartość rzeczywistą (np. 2 -> 1,99998). Chodzi o to żeby przy konwersji real48 -> double uzyskać tą liczbę możliwie bez przekłamań. Mała różnica po przecinku decyduje o tym w którą stronę będzie ta liczba zaokrąglona, a więc będzie różnica o 1. W programach księgowych to nie przejdzie.
Tak jak pisałem, nie mogę "przejść" na inne typy, plik generowany jest przez inny system powstały w czasach świetności Turbo Pascala.

Zdarzyło mi się nie raz (z pewnością Tobie też) zapisać liczbę całkiowitą do bazy danych w pole typu rzeczywistego, a odczytać wartość rzeczywistą (np. 2 -> 1,99998).

Ja to zapisuje całkowite póki się da, a potem robię wszystko tak żeby mnie nie obchodziły małe zmiany, i nie wydaje mi się żeby to występowało przy real48->double, a nawet jeżeli to tego nie przeskoczysz, bo po prostu dokładniej się nie da.

Chodzi o to żeby przy konwersji real48 -> double uzyskać tą liczbę możliwie bez przekłamań.
Double jak i real48 to jedno wielkie przekłamanie, więc ciężko obwiniać algorytm, o to że nie robi niemożliwego.

Mała różnica po przecinku decyduje o tym w którą stronę będzie ta liczba zaokrąglona, a więc będzie różnica o 1.
Jak użyjesz trunc na głupiego to tak. Jak zrobisz próg tolerancji to będzie ok. Przecież w każdej książce jest o tym że powinno się stosować progi przy np. porównywaniu rzeczywistych.

Tak jak pisałem, nie mogę "przejść" na inne typy, plik generowany jest przez inny system powstały w czasach świetności Turbo Pascala.

No to co się martwisz o takie duperele jak wysoka dokładność odczytu, co jest w samych założeniach niemożliwe. Wysoce prawdopodobne jest że te twoje 2 jest zapisywane jako 1.999998 więc ciężko od algorytmu wymagać tego by to odczytał 2 skoro to też znaczy 1.99998 . W takim przypadku musisz się pobawić w zaokrąglanie do progu, co również nie poprawia, tylko pogorsza dokładność w teorii.