Dwa różne wyniki tej samej funkcji

0

Witam,
Mam dość dziwny problem z następującym kodem:

      for j := 0 to 3 do
          begin
          for i := 0 to 3 do
            begin
              linia[i] := GetUndulationByColRow(col + i-1, row + j-1) / 10000;
            end;
            linia2[j] := Lagrange3(linia, y);
            tekst := tekst + format ('%g',[linia2[j]]) + chr(13)+ chr(13);
          end;
        result := Lagrange3(linia2, x);

Funkcja 'GetUndulationByColRow' wyciąga z tabeli żądaną wartość. W ten sposób powstaje 4-elementowa tablica linia, która jest argumentem funkcji Lagrange3. Po 4 wywołaniach funkcji Lagrange3 powstaje kolejna 4-elementowa tablica linia2, która też jest argumentem dla funkcji Lagrange3 i daje ostateczny wynik. Tyle w teorii. Kod działa, ale daje wynik dziwny. Dopisałem do kodu wrzucanie aktualnej wartości j-tego elementu z tablicy linia2 do stringa, żeby zobaczyć czy funkcja Lagrange3 działa dobrze. Dostałem stringa i . . . zupełnie inny wynik funkcji (chyba nawet poprawny). Co jest źle?

Dodam, że w Delphi stawiam pierwsze kroki (sytuacja trochę wymuszona), ale wiem z innych języków, że to nie powinno być możliwe.

3

Jeśli chcesz wiedzieć jak działa algorytm w różnych krokach (iteracjach), to postaw breakpoint, debuguj linia po linii i obserwuj zawartość macierzy (okno Watches, jeśli Twoje Delphi nie obsługuje hintów w kodzie źródłowym podczas debugowania).

Przy okazji — tabela i tablica to dwa różne terminy w programowaniu i nie powinno się ich używać zamiennie, bo ich znaczenie jest różne. Tabele są w bazach danych, a tablice (macierze) to podstawowe struktury danych.

0

@furious programming: Dzięki, pośrednio pomogłeś. Zacząłem się bawić z breakpointami itd i znalazłem. Błąd się okazał w funkcji Lagrange3. Zmienna odpowiedzialna za wynik końcowy nie była wprost zerowana i to robiło problem.

1

Nie mogłem inaczej pomóc, bo za mało kodu podałeś. ;)

Ogólnie to umiejętności debugowania to obowiązek każdego, kto pracuje z kodem. W przypadku Pascali — Delphi i Lazarus — obowiązkiem jest posługiwanie się breakpointami (zwykłymi i warunkowymi), a także śmiganie po instrukcjach za pomocą step into, step over, step out i step to cursor. Jeśli chce się wiedzieć co w trawie piszczy, to okno watches (lub hinty, jeśli IDE je wspiera), a jeśli dane są nieprawidłowe, ale chce się sprawdzić jak kod będzie działać dalej, to evaluate/modify i poprawiamy co potrzeba.

Powyższe to minimum co należy znać, ale to minimum daje mnóstwo informacji, dzięki czemu większość błędów da się w ten sposób namierzyć. Dlatego polecam pobawić się tymi funkcjami i wiedzieć, że to pierwsza deska ratunku w przypadku kłopotów z kodem.

1 użytkowników online, w tym zalogowanych: 0, gości: 1