Dai commenti che ci siamo scambiati, sembra che tu non sia poco familiare con la matematica, ma anche con la disciplina di calcolo numerico di base.
Innanzitutto, per l'amor di dio, non selezionare automaticamente un epsilon per far "passare" i test. Se elimini gli epsiloni fino a quando l'errore non è sotto epsilon, i tuoi test non testano nulla e potresti ignorare problemi di precisione davvero pessimi (forse anche un algoritmo sbagliato se si verificano risultati simili in i tuoi casi di test).
Scegli invece epsiloni ragionevoli a priori e rispettali . Se ottieni errori più gravi di quanto ti aspetti o ti aspetti, ciò significa che devi correggere il tuo codice, non abbassare le tue aspettative . Purtroppo, quali aspettative sono "ragionevoli" dipende dall'applicazione e dall'algoritmo, ma per impostazione predefinita mi aspetterei, per esempio, un errore relativo inferiore a 1e-12 se i float sono a 64 bit.
In secondo luogo, la parola chiave è un errore relativo . L'errore assoluto è, come hai visto, molto sensibile alla grandezza dei valori, e quindi spesso inutile. Inoltre, a causa di come funziona il floating point, c'è un errore relativo fisso che non si può battere a meno che non si produca lo stesso esatto pattern di bit (per i float a 64 bit, si tratta di 1e-17 ). Quindi, se i numeri sono abbastanza grandi, scoprirai che il tuo errore assoluto è zero (improbabile) o piuttosto grande, anche se il calcolo potrebbe essere solo di un'unità nell'ultimo posto (ULP).
Per questo, dovresti anche forzare MATLAB a generare più cifre (17 è il numero massimo che ha senso per i float a 64 bit). Oh, e i calcoli relativi all'errore relativo possono essere piuttosto complicati, come sottolinea anche @CodeInChaos, quindi potresti voler fare affidamento su algoritmi esistenti che gestiscono casi limite meglio degli approcci ingenui, come link