Proszę, niech mi to ktoś sprawdzi i powie, że moje WinUAE doprowadza mnie do obłędu a nie jest to wina AMOS-a, czy Amigi w ogóle. Próbuję wykonać z pozoru błahą operację dodania dwóch liczb dziesiętnych:



W AMOS-ie wygląda to tak:

A#=3000000.0
B#=14.48
Print A#+B#

Jeśli zredukuję 300000 do 30000, to wynik jest poprawny, ale to dla mnie żadne rozwiązanie. Moje liczby sięgają milionów i zawierają dane po przecinku, które muszą być dokładne do jednej dziesiątej.
Gdyby ktoś mógł odpalić na prawdziwej Amidze, to tutaj ma skompilowaną binarkę na dropboksie. Mam nadzieję, że rozwiązanie jest banalne a ja po prostu zmęczony.

Ostatnia aktualizacja: 23.04.2016 06:20:28 przez Umpal

• Odpowiedz

@Umpal, post #1

Set Double Precision

• Odpowiedz

@void, post #2

Heh, nie natrafiłem do tej pory na ten pierwszy cytat, ale resztę czytałem po kilka razy. Nie wspomniałem o tym w moim pierwszym poście, ale oczywiście Set Double Precision próbowałem. Ale albo moja matematyka jest tak słaba, albo nie potrafię zrozumieć wyniku, jaki po jej użyciu wyświetla. Tak czy siak, ustawienie podwójnej precyzji jest wątpliwym rozwiązaniem, bo:

This extent of accuracy will consume twice as much memory as the standard version, and it will also cause a great slowing down of calculations. It should only be used when extra accuracy is absolutely vital.

Za great slowing down bardzo dziękuję. Jakby Amiga za wolna była . Trudno, pomyślę, co mogę zmienić żeby się z tym nie męczyć. Dzięki.

• Odpowiedz

@Umpal, post #3

• Odpowiedz

@Umpal, post #1

• Odpowiedz

@sanjyuubi, post #5

Dzięki chłopaki. Początkowo chciałem zrobić tak, jak proponujecie, ale ta metoda rozwala mi totalnie wyniki pewnych formuł. Nie do zaakceptowania w tym przypadku. Wpadłem więc na pomysł, żeby w jednej zmiennej trzymać całkowitą, a w drugiej po przecinku. Osobno wykonuję operację na całych i osobno na częściach (jak brakuje, to zabieram całą z głównego ciągu). Działa

Wizualizacja tej metody:


PS Ale muszę szczerze przyznać, że tak głęboko w liczeniu nigdy na Amidze nie siedziałem i wiele rzeczy wydawało mi się oczywistych (na PC zmienne typu Sinlge, Long, Double są normalką i łatwo jest się zapomnieć, że Amiga jest liczydłem sprzed dekad).


Ostatnia aktualizacja: 23.04.2016 16:39:42 przez Umpal

• Odpowiedz

@Umpal, post #6

• Odpowiedz

@Krashan, post #7

Pewnie masz rację, ale ja tego nigdy nie doświadczyłem, tzn. takiego "błędu", bo nie wiem, czy to błąd, czy ograniczenie konstrukcyjne (za tępy na to jestem). W każdym razie na przykładzie z pierwszego posta na PC bez żadnych kombinacji wynik jest poprawny. Dla mnie, kmiotka-programisty, operacja matematyczna zawsze powinna dać logiczny wynik. Jeśli jest inaczej, to odchodzę od zmysłów i chcę palić czarownice

• Odpowiedz

@Umpal, post #8

int main(void)
{
	float x = 300000.0f;
	float y = 14.48f;

	printf("%f\n", x + y);
	return 0;
}

• Odpowiedz

@Umpal, post #1

• Odpowiedz

@Krashan, post #9

Na leciwym już Visual Basicu 6.0 wynik mam dokładny, bez przekłamań (nie deklaruję typu zmiennych), stąd napisałem, że jest poprawny i do niego robię referencje, gdy dłubię w AMOS-ie. Na innym nie sprawdzałem. Ale nie spieram się z niczym, bo na własnej skórze widzę, jak to niestety działa...
Z innej beczki. Czy wykorzystanie koprocesora do takich obliczeń coś by zmieniło? (za chwilę obejrzę wideo podlinkowane przez teh_KaiNa, więc być może tam jest odpowiedź. Gdyby nie, to chętnie przeczytam tutaj)

[Update]
Właśnie skończyłem oglądać i już wiem, że koprocesor nic tutaj nie zmieni. Po prostu . Gościu świetnie to tłumaczy i nawet ja to pojąłem . Dzięki teh_KaiN jeszcze raz, czuję, że nastąpił przełom w moim życiu

@teh_KaiN, dzięki za wskazówki. Przetrawię to i zobaczę, jak mi będzie szybciej i wygodniej. Co do wyników, to tak, są mi bezwzględnie potrzebne z dokładnością do dwóch po przecinku.


Ostatnia aktualizacja: 23.04.2016 18:05:47 przez Umpal

• Odpowiedz