Funkcja MathPow()

[m_c]

Witam,

mam dylemat jaka powinna być poprawna składnia (obie wersje działają, z tym że jedna nie do końca poprawnie a drugą dopiero testuję):

double suma=a1+a2+a3... ;
double podzial=suma/20;

i teraz MathPow():

1. double x=MathPow(podzial,0.4);

czy

2. double x=MathPow((StrToDouble(podzial)),0.4);

Która składnia jest poprawna 1 czy 2?
Dzięki za odpowiedź.

[Bfx]

1 jest dobre. W 2 StrToDouble nie powinno byc, bo zmienna "podział" ma typ double a nie string. Nie wiem jaki masz problem ale spróbuj użyc NormalizeDouble zamiast StrToDouble.

[m_c]

Problem polega na tym że wersja 1 robiła błędy jak w załączniku w stosunku do modelu w excel. Przykładowo 6 transakcji dobrze 2 źle. Ostatnio wersja 1 robiła dodatkowo transakcje których nie było w modelu, czyli oderwane od wszystkiego. NormalizeDouble w tym przypadku raczej nie ma znaczenia, ponieważ zaokrąglenie liczby dziesiętnej jest bez sensu - załącznik. Dlatego jest bez sensu bo co mi da długość a tym samym zaokrąglenie do dwóch/trzech/czterech miejsc po przecinku, jeśli 1,5 jest inne niż 0,3 ?
Sprawdzałem sposób liczenia w kodzie dwa razy i wychodzi że jest dobrze zrobione. W excelu najprawdopodobniej nie ma błędów.
No i mam dylemat dlaczego wychodzi inaczej :)
Biorąc pod uwagę iż duża część sygnałów z transakcjami się pokrywa, wyliczenia muszą być zbliżone, więc najprawdopodobniej jest to jakiś prosty błąd.

[Bfx]

Miałem kiedyś podobny problem, myślałem że mam gdzieś błąd w kodzie a okazało się, że funkcja MathMod() źle obliczała. W ogóle nie zwracała mi reszty z dzielenia liczb całkowitych. Dalej się tak dzieję jak jej używam. Ale znalazłem na to sposób. MathPow() nigdy nie używałem, możliwe że również nie działa prawidłowo. Niestety musisz to sprawdzac ręcznie na kalkulatorze i porównywac czy funkcja dobrze liczy.

EDIT: Spróbuj z tym NormalizeDouble(). Może to miec wpływ, bo jeśli jej nie użyjesz to funkcja przed wykonaniem dalszych obliczeń sama zaokrągli do 5 miejsca po przecinku. A używając tej funkcji możesz zaokrąglic do 10 albo więcej.
Przykład:
MathPow(a/b,x/y);
Jeśli nie użyjesz NormalizeDouble to funkcja ta najpierw obliczy a/b i zaokrągli do 5 miejsca po przecinku, to samo zrobi z x/y i dopiero podniesie do potęgi. Miałem taki przypadki, że nie użycie NormalizeDuble() wpływało na błędne obliczenie ceny nawet o kilkadziesiąt pips. Przy potęgowaniu różnice mogą byc większe.

[m_c]

ok, zrobię NormalizeDouble(), potem też wywale jako alert obliczenia i faktycznie PrtScr i kalkulator :)
Zastanawiałem się też nad obejściem MathPow(), bo w moim przypadku jest to pierwiastkowanie. Teoretycznie mógłbym zrobić mnożenie tylko zastanawiam się jak zrobić potęgę 1/n w mql4, bo do n to najmniejszy problem.
Może faktycznie MathPow() się zakręciło bo jest tam kilka średnich wcześniej jednych z drugich i do tego kursy.

[Bfx]

Możesz obliczyc 1 do n. Są na to wzory. Było w szkole ale nie pamiętam. Poszukaj albo zapytaj na jakimś forum matematycznym.
Alert i sprawdzanie obliczeń to najlepsze droga do znalezienia problemu. Powodzenia

[m_c]

Wiem że było w szkole :) grzebałem też na forach matematycznych :) dzięki

[m_c]

Bfx zagiąłeś mnie :)
Po wywaleniu wyszło że:

suma==0
podzial==0

[m_c]

Wielkie G. Nawet po użyciu NormalizeDouble() z dokładnością do 20 miejsca po przecinku część transakcji się pokrywa z modelem w excel a część nie.
Albo źle użyte jest Normalize albo błąd jest gdzieś indziej.