Nicht lineare "progressbar" % berechnen

Dampfbox schrieb:
Wenn du dich daran störst, dass jemand von der Seite seine valide Meinung zu einem Thema kundtut, bist du in einem öffentlichen Forum vielleicht nicht am besten aufgehoben.
Mich stören unwahre Behauptungen als Reaktion auf meine Beiträge in einem öffentlichen Forum.
 
Dann soll der TE (oder die, Plural) das doch alleine machen. Ich bin hier raus, wenn offensichtlich richtige Lösungen schlechtgeredet werden. Viel Spaß noch.
 
CyborgBeta schrieb:
Dann soll der TE (oder die, Plural) das doch alleine machen. Ich bin hier raus, wenn offensichtlich richtige Lösungen schlechtgeredet werden. Viel Spaß noch.
Ich habe mir seinen Post noch mal durchgelesen und finde nicht, dass deine Lösung als "falsch" dargestellt wurde oder auch nur "schlechtgeredet" wurde.

Nimm so was nicht direkt persönlich :)
 
  • Gefällt mir
Reaktionen: maloz, Raijin, KitKat::new() und 2 andere
@Dampfbox: Danke für deine sachliche Diskussion an dieser Stelle, hätte ich nicht erwartet, auch weil ich stellenweise durchaus provokativ dir gegenüber war.

Aber ja, es war nicht meine Absicht, andere Lösungen als schlechter darzustellen, im Gegenteil. Man muss die Lösungen halt auf verschiedenen Ebenen betrachten. Die Formeln bieten durchaus das für den Endkunden wohl "geglättetste" Erlebnis (ich sprach ja auch von "schöneres Ergebnis"). Legt man den Fokus auf Wartbarkeit, dann haben sie m.M.n. halt Nachteile. Da muss man abwägen, was für einen am wichtigsten ist. Und für mich ist mittlerweile die Wartbarkeit wichtiger.

@CyborgBeta: Wartung bedeutet hier halt auch mal Anpassung der Meilensteine. Oder was hast du darunter verstanden?
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Gelöscht 875920
tollertyp schrieb:
@CyborgBeta: Wartung bedeutet hier halt auch mal Anpassung der Meilensteine. Oder was hast du darunter verstanden?
Ich hab mir nicht jeden Beitrag durchgelesen, aber wenn es hier nur um Meilensteine und einen Gesamtfortschritt geht, dann ist das doch ganz einfach und man braucht keine Formel dafür.

Beispiel:
MS A: 10 Punkte
MS B: 40 Punkte
MS C: 15 Punkte

Von A wurden 8 Punkte erreicht, von B 38 und von C 1. Das ergibt:

(8+38+1)/(10+40+15)*100 = 72,3 %

Also hier würde mEn einfache Prozentrechnung genügen.

Die "Ticks" (Markierungen) werden dann bei 10/(10+40+15), bei (10+40)/(10+40+15) und bei (10+40+15)/(10+40+15) gesetzt.

Oder habe ich jetzt etwas Wichtiges übersehen?
 
CyborgBeta schrieb:
Oder habe ich jetzt etwas Wichtiges übersehen?
Ja, die unterschiedliche Punktedichte in den Abschnitten. Bei dir ist der Abstand zwischen allen Punkten gleich groß.

Außerdem kann man nicht im Abschnitt B Punkte haben während in Abschnitt A Punkte fehlen (war mir anfangs auch nicht klar)
 
  • Gefällt mir
Reaktionen: tollertyp
@KitKat::new() : Jetzt verstehe ich, was gemeint ist, aber auch das ist "einfaches" Rechnen...

CyborgBeta schrieb:
Beispiel:
MS A: 10 Punkte
MS B: 40 Punkte
MS C: 15 Punkte

Nicht-lineare Progressbar:

Java:
public static void updateProgressBar(JProgressBar bar, int[] milestones, int points) {
    int sum1 = Arrays.stream(milestones).sum();
    double sum2 = (double) sum1 / milestones.length;
    int p1 = points;
    double p2 = 0;
    int i = 0;
    for (; i < milestones.length; i++) {
        if (p1 >= milestones[i]) {
            p1 -= milestones[i];
            p2 += sum2;
        } else {
            p2 += (double) p1 / milestones[i] * sum2;
            break;
        }
    }
    int val = (int) p2;
    bar.setMinimum(0);
    bar.setMaximum(sum1);
    bar.setValue(val);
    bar.setForeground(Color.getHSBColor((float) i / milestones.length, 0.5f, 1f));
}

1654782142261.gif


Stellt euch einfach zwei Markierungen bei 1/3 und 2/3 vor. Der Mittlere Part läuft dann natürlich, wie man sieht, viel langsamer.
 
CyborgBeta schrieb:
Stellt euch einfach zwei Markierungen bei 1/3 und 2/3 vor.
Wie man an der Visualierung im Starterpost sieht, sind auch die Markierungen nicht in identischen Intervallen.

Eine Lösung mit ähnlichem Ansatz (der Versuch einer exakten Lösung unter segmeintweiser Betrachtung im Gegensatz zur Approximation mit einer Funktion) findest du in Post #31
 
  • Gefällt mir
Reaktionen: tollertyp
Wenn natürlich... MS 2 vor MS 1 fertig sein kann usw... dann würde ich empfehlen, für jeden MS eine eigene Progress-Bar zu zeichnen, denn das würde sonst rechnerisch keinen Sinn machen.

So handlet das GitHub glaube ich auch.
Ergänzung ()

KitKat::new() schrieb:
Wie man an der Visualierung im Starterpost sieht, sind auch die Markierungen nicht in identischen Intervallen.
Siehe #71.
 
CyborgBeta schrieb:
Ist nicht der Fall und unabhängig von den nicht in konstanten Intervallen verteilten Milensteinen
 
  • Gefällt mir
Reaktionen: tollertyp
KitKat::new() schrieb:
Wie man an der Visualierung im Starterpost sieht, sind auch die Markierungen nicht in identischen Intervallen.
... dann muss er doch einfach nur addieren (vorausgesetzt: MS i+1 kann nicht vor MS i fertig sein...)
Ergänzung ()

KitKat::new() schrieb:
Ist nicht der Fall und unabhängig von den nicht in konstanten Intervallen verteilten Milensteinen
... dann ist es wieder einfach Prozentrechnung, oder nicht?
 
Ach ja, btw: Und im Übrigen habe ich den Ansatz selbst als "naiv" bezeichnet. Naiv, weil ich kein JavaScript-Guru bin (aber immerhin versuche, das Problem in der Sprache zu lösen, die der TE auch verwendet), und naiv, weil es eben keine ausgeklügelten mathematischen Formeln verwendet.

@CyborgBeta, wenn ich das gerade sehe, wie hast du die Progress-Bar eigentlich gecaptured?
 
Ah okay. Schade. Hatte gehofft, es gäbe ein einfaches Tool zum Aufzeichnen von Bildschirm-Ausschnitten.
 
Immer mit der Ruhe meine eifrigen Programmierer, wir sind doch schließlich hier um voneinander zu lernen und profitieren.

Viele Wege führen nach Rom und abhängig von den Anforderungen hat jeder Weg seine Vor- und Nachteile.

Ich habe mehrere Ansätze getestet und bin zu dem Entschluss gekommen das der Ansatz von @tollertyp in meinem Fall die beste Lösung ist. Da hier der Prozentwert am genausten ausgerechnet wird und ich den Code leichter anpassen kann im Fall der Fälle, als die Formel.

Ich bin mir auch ziemlicher sich das man die Formeln weiter anpassen kann so dass der Prozentwert optimiert werden kann. Alles eine Frage der persönlichen Präferenz und Fähigkeiten. Für mich ist hier der "nicht mathematische" Weg die bessere Wahl.

Folgende Formel funktioniert z.B. ziemlich gut aber ist eben mMn nicht so leicht zu pflegen. Aber wie gesagt alles eine Frage eigenen und Projekt Präferenzen :)

Javascript:
var x = 50;
var percent = (129*x)/200 + (247*x**2)/20000 - (21*x**3)/200000


@CyborgBeta Auch dir Danke für die Beteilung und Lösungsvorschläge zu diesem Problem. Ich bin mir aber noch nicht sicher ob du das Problem genau verstanden hast ;)

Vielleicht teste ich deinen Code mal in irgend einer online Java Entwicklungsumgebung, weil es mich interessiert.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: tollertyp und Raijin
machhommy schrieb:
@CyborgBeta Auch dir Danke für die Beteilung und Lösungsvorschläge zu diesem Problem. Ich bin mir aber noch nicht sicher ob du das Problem genau verstanden hast ;)
Dann beschreib genauer, was du vor hast. Die Formel lässt sich nämlich nicht einfach anpassen. Solange bin ich erstmal hier weg.
 
CyborgBeta schrieb:
Dann beschreib genauer, was du vor hast. Die Formel lässt sich nämlich nicht einfach anpassen. Solange bin ich erstmal hier weg.

Das wurde hier nun zu genüge aufgeführt was das Ziel ist ;)
 
  • Gefällt mir
Reaktionen: tollertyp
Zurück
Oben