Java Ermitteln, ob der RSI-Wert von unten nach oben verläuft

Status
Für weitere Antworten geschlossen.
kali-hi schrieb:
In beiden Modellen schreibt man aber keine oder nur wenige Tests.
Zumindest mit Scrum habe ich jahrelang gearbeitet und kann sagen, dass das Quatsch ist. Scrum äußert sich gar nicht zum Thema Tests.
 
  • Gefällt mir
Reaktionen: BeBur, tollertyp, Bob.Sponge und eine weitere Person
Btw... Wer das zum Handeln verwenden möchte, der sollte die Ergebnisse zusätzlich gewichten und ein Scoring einführen:

Java:
  private double calculateProbability(double rsi, int a, boolean isRsiRising) {
    double absRsi = Math.abs(rsi - 50.0);
    double absA = Math.abs(a);
    double result = 1.0 - (absRsi + absA) / 10.0;
    if ((!isRsiRising || a < 0) && result > 0) {
      result = -result;
    }
    return result;
  }

a ist hierbei ein weiterer Faktor, aus dem Intervall von -10 bis +10, wobei 0 ein Optimum darstellt, den ich aber jetzt nicht weiter benennen möchte.

Die Probability kann dann für eine bestimmte Menge an Assets für ein bestimmtes Kerzen-Intervall (zum Beispiel 5m) berechnet werden - wobei ich dies aber nicht für alle Tier 1 Assets berechnen würde, weil die Börse sonst Soft-Bans verteilt (eine gewisse Wartezeit ist hier wichtig)... - absteigend sortiert werden und das erste Asset gewählt werden, dessen Probability zum Beispiel > 0.1 ist.

Ein paar Tests gestern und heute haben gezeigt, dass danach der Kurs sofort steigt. Ich habe aber kein Backtesting vorgenommen (das heißt, den Indikator auf vergangene Kursverläufe anwenden), wie es im professionellen Umfeld gemacht wird...

Disclaimer: Seid aber bitte immer vorsichtig damit, wenn es um Geld geht. Each to their own.
 
kali-hi schrieb:
Das könnte man machen (statische Hilfsmethode), aber andererseits werden die Daten in dem Objekt gespeichert - deshalb ist es ohne Parameter besser, auch wenn der Testaufwand höher ist.
Ich habe das schlüssige Argument irgendwie übersehen, warum es besser ist.
 
Ja, und man sieht auch, worauf der Fokus liegt.
Auf jeden Fall nicht bei der Test- und Wartbarkeit.

Spaghetti-Code ist auch eine Design-Entscheidung.
 
  • Gefällt mir
Reaktionen: Bob.Sponge und BeBur
Die Funktion ist halt offensichtlich nicht wichtig genug als das man Tests bräuchte, das ist so ähnlich wie mit Daten die nicht wichtig genug sind als das man Backups bräuchte (bis die Daten futsch sind).
 
  • Gefällt mir
Reaktionen: Bob.Sponge und tollertyp
tollertyp schrieb:
Jetzt geht das wieder los :rolleyes:

Wenn die Funktionalität gegeben ist, wird sie durch Tests auch nicht besser.
Ergänzung ()

Und es ist auch kack dreist, so etwas ohne einen Beleg zu behaupten... Hoffe, du machst niemals irgendwelche Reviews. Andererseits, wenn man sich unsere Unternehmen so mal anschaut, dann wundert vieles doch nicht mehr...
 
kali-hi schrieb:
Wenn die Funktionalität gegeben ist
Du musstest hier sogar nach Reviews fragen, weil du nicht sicher warst ob der Code fehlerfrei ist. Klar kann man versuchen, Arbeit einfach auf andere abzuwälzen, aber auch das ersetzt keine Tests.
Selbst wenn Code fehlerfrei wäre benötigt man Tests um später Regression zu vermeiden.
 
  • Gefällt mir
Reaktionen: Bob.Sponge und tollertyp
BeBur schrieb:
Klar kann man versuchen, Arbeit einfach auf andere abzuwälzen, aber auch das ersetzt keine Tests.
Hätte auch woanders fragen können 🤷‍♂️

[ ] Du hast verstanden, wie eine Community (also freundliches Miteinander) funktioniert.
 
Beste Hilfe bekommt man von Ja-Sagern...
Aber wen du sagst "deshalb ist es ohne Parameter besser, auch wenn der Testaufwand höher ist", dann kann man das halt einfach nicht so stehen lassen. Wenn du so etwas nicht hören willst, dann solltest du halt dort hin gehen, wo die Leute unkritisch sind.

kali-hi schrieb:
Wenn die Funktionalität gegeben ist, wird sie durch Tests auch nicht besser.
Also ich kann nur hoffen, dass du beruflich nichts mit Software-Entwicklung zu tun hast.

Hey, lass uns doch die Tests entfernen, die Funktionalität ist doch gegeben... und hey, Tests sind doch ein Ausdruck des Misstrauens...

Edit:
Ich hatte mal einen sehr guten Kollegen. Der war der Ansicht, dass der Testcode wichtiger ist als der Produktivcode, weil der Testcode letztendlich das Verhalten der Anwendung sicherstellt. Ich finde die Ansicht schon etwas extrem, aber ich kann ihm argumentativ nicht widersprechen.

Edit2:
Und zum Thema kritisch sein: Dein ziemlich erster Satz war, dass es "wichtiger Code" ist. Dann wundere dich bitte nicht, wenn wir den Code auch als "wichtig" ansehen und entsprechend hohen Anspruch daran zeigen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: BeBur und Bob.Sponge
tollertyp schrieb:
lass uns doch die Tests entfernen, die Funktionalität ist doch gegeben
In mancher Hinsicht gar nicht mal verkehrt... denn schlechte Tests sind sogar kontraproduktiv. Aber Hauptsache, man kann 100 % Testabdeckung bewerben.
 
Und weil manche Leute nicht Autofahren könnten, sollte man es allen verbieten...
Dass Testabdeckung wenig Aussagekraft hat, da bin ich bei dir. Aber eine Testabdeckung von 0% sagt dennoch viel aus.
 
  • Gefällt mir
Reaktionen: Bob.Sponge
tollertyp schrieb:
Ja, und man sieht auch, worauf der Fokus liegt.
Auf jeden Fall nicht bei der Test- und Wartbarkeit.

Spaghetti-Code ist auch eine Design-Entscheidung.

Und Erweiterbarkeit würde mir auch noch einfallen. Open-Closed Principle.

BeBur schrieb:
Du musstest hier sogar nach Reviews fragen, weil du nicht sicher warst ob der Code fehlerfrei ist. Klar kann man versuchen, Arbeit einfach auf andere abzuwälzen, aber auch das ersetzt keine Tests.
Selbst wenn Code fehlerfrei wäre benötigt man Tests um später Regression zu vermeiden.

Tut mir Leid @kali-hi, sehe das wie @BeBur. Was hier gepostet wird, wird zwangsläufig auch einem Review unterzogen, so hart und gnadenlos die Kritik dann auch eben sein kann.
Aber auch nur so lernt man doch auch daraus? Wenn man hier eine 1+ erwartet, müsste man auch entsprechenden Code posten.

Ich muss zugeben, das auch ich den ganzen Code von dir in diesem Thread hier nicht einfach zu lesen finde oder gar nachvollziehen kann. Mag aber auch daran liegen, das ich nicht weiß was du am Ende eigentlich für ein Ergebnis erwartest. Bin da halt einfach gestrickt, ohne Spezififaton (und diese darf/muss natürlich auch iterativ reifen dürfen), fehlt mir der Rahmen zu testen (ja, da ist wieder dieses unangenehme Wort) ob Erwartungen und Implementierung zusammen passen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: BeBur und tollertyp
Damit alle glücklich sind:

Java:
import java.util.Arrays;
import org.jetbrains.annotations.NotNull;

public class Tools {
  public record LinearRegressionResult(double slope, double intercept, double[] predictedValues) {
    @Override
    public double[] predictedValues() {
      return predictedValues.clone();
    }

    @NotNull
    @Override
    public String toString() {
      return "LinearRegressionResult{"
          + "intercept="
          + intercept
          + ", slope="
          + slope
          + ", predictedValues="
          + Arrays.toString(predictedValues)
          + '}';
    }
  }

  public static LinearRegressionResult linearRegression(double[] y) {
    int n = y.length;
    double[] x = new double[n];
    for (int i = 0; i < n; i++) {
      x[i] = i;
    }
    return linearRegression(x, y);
  }

  public static LinearRegressionResult linearRegression(double[] x, double[] y) {
    if (x.length != y.length) {
      throw new IllegalArgumentException("Input arrays must have the same length.");
    }
    int n = x.length;
    double sumX = 0.0, sumY = 0.0, sumXY = 0.0, sumX2 = 0.0;

    for (int i = 0; i < n; i++) {
      sumX += x[i];
      sumY += y[i];
      sumXY += x[i] * y[i];
      sumX2 += x[i] * x[i];
    }

    double slope = (n * sumXY - sumX * sumY) / (n * sumX2 - sumX * sumX);
    double intercept = (sumY - slope * sumX) / n;

    double[] predictedValues = new double[n];
    for (int i = 0; i < n; i++) {
      predictedValues[i] = slope * x[i] + intercept;
    }

    return new LinearRegressionResult(slope, intercept, predictedValues);
  }

  public static void testLinearRegression_slope_2() {
    double[] y = {1, 3, 5, 8, 7, 12};
    LinearRegressionResult result = linearRegression(y);
    System.out.println(result);
  }

  public static void testLinearRegression_slope_0() {
    double[] y = {0, 5, 0, 5, 0};
    LinearRegressionResult result = linearRegression(y);
    System.out.println(result);
  }

  public static void testLinearRegression_slope_negative() {
    double[] y = {10, 11, 9.5, 8, 11};
    LinearRegressionResult result = linearRegression(y);
    System.out.println(result);
  }

  public static void testLinearRegression_same_values_slope_0() {
    double[] y = {1, 1};
    LinearRegressionResult result = linearRegression(y);
    System.out.println(result);
  }

  public static void testLinearRegression_empty_array_NaN() {
    double[] y = {};
    LinearRegressionResult result = linearRegression(y);
    System.out.println(result);
  }

  public static void testLinearRegression() {
    testLinearRegression_slope_2();
    testLinearRegression_slope_0();
    testLinearRegression_slope_negative();
    testLinearRegression_same_values_slope_0();
    testLinearRegression_empty_array_NaN();
  }

  public static void main(String[] args) {
    testLinearRegression();
  }
}

wobei Arrays in Record-Klassen ein Anti-Pattern ist. :(
 
kali-hi schrieb:
Also, Ironie und Sarkasmus bitte sparen...

Warum, weil Du zum Lachen in den Keller gehst?

Wenn man mal ehrlich ist, sind diese Threads ohne Sarkasmus nur schwer zu ertragen.

kali-hi schrieb:
Damit alle glücklich sind:
[...]

Hm, was auch immer das da sein soll, ein Test ist es schonmal nicht, denn es erfüllt den wesentlichen Zweck eines solchen nicht. Dieser Zweck, so viel ist Dir ja hoffentlich klar, besteht darin, Dinge zu testen. Üblicherweise geschieht dies durch Vergleiche mit erwarteten Werten.
Du schriebst, Du würdest "später" einen JUnit-Test schreiben. Ich würde empfehlen, das dann mal zu tun.

xpad.c
 
  • Gefällt mir
Reaktionen: BeBur, tollertyp und Bob.Sponge
xpad.c schrieb:
was auch immer das da sein soll, ein Test ist es schonmal nicht, denn es erfüllt den wesentlichen Zweck eines solchen nicht. Dieser Zweck, so viel ist Dir ja hoffentlich klar, besteht darin, Dinge zu testen. Üblicherweise geschieht dies durch Vergleiche mit erwarteten Werten.
Hab dich nicht so, weil ich jetzt nicht extra JUnit installieren wollte.

Die Vergleiche fehlen, das stimmt, aber man kann auch einfach in die Ausgabe schauen (und mit dem Methodennamen vergleichen). Ich brauche keine Asserts, nur damit Punkte grün werden. Das ist Boilerplate
 
@kali-hi Maven dependency einfügen = extra installieren?

Boilerplate? Durch eine Testklasse? Und das bei - deine Aussage - wichtigem Code?

Sag es doch einfach wie es ist: Du testet grundsätzlich nicht weil es in SCRUM auch nicht explizit so vorgegeben ist. Das sagtest du gestern. Ist ja auch nicht schlimm, ist deine Entscheidung als mündiger Mensch und gut ist, stehe dazu.

Aber bitte nicht Stuss erzählen. Es geht nicht um grüne Punkte herrje.
 
  • Gefällt mir
Reaktionen: BeBur und kali-hi
Bob.Sponge schrieb:
Maven dependency einfügen
Gradle... aber egal, es ist ein zusätzliches Framework, das den Build Prozess verlangsamen kann.

Aber... die Kritik an der Codequalität aufgrund mangelnder Tests ist angekommen.
 
Status
Für weitere Antworten geschlossen.

Ähnliche Themen

Zurück
Oben