Case-Statement für Float-Werte

[Andreas L.]

Hallo,
ich habe gerade ein simples Case-Statement mit Single-Werten geschrieben. Leider kann ich es nicht kompilieren. Die Meldung lautet:

Zitat:

E2001 Ordinaltyp erforderlich

Mir ist klar das ein Single kein Ordinal-Typ ist. Aber es kann doch nicht sein das man kein Case auf Float anwenden kann? Wie kann ich das Problem lösen? Gibt es irgendeine Funktion dafür (wie z.B. CharInSet, etc.), muss das über RTTI gemacht werden oder komme ich um einfache If-Abfragen nicht vorbei?

So habe ich es versucht:

Delphi-Quellcode:

  TibZoomFactorPercent = (
    Custom,
    Percent10,
    Percent25,
    Percent50,
    Percent75,
    Percent100,
    Percent125,
    Percent150,
    Percent175,
    Percent200,
    Percent250,
    Percent300,
    Percent400,
    Percent500
  );

function TfrmEditor.GetZoomFactorAsPercent(
  AZoomFactor: Single = 1): TibZoomFactorPercent;
begin
  Result := TibZoomFactorPercent.Custom;
  case AZoomFactor of // Hier tritt der Fehler auf...
    0.10: Result := TibZoomFactorPercent.Percent10;
    0.25: Result := TibZoomFactorPercent.Percent25;
    0.50: Result := TibZoomFactorPercent.Percent50;
    0.75: Result := TibZoomFactorPercent.Percent75;
    1: Result := TibZoomFactorPercent.Percent100;
    1.25: Result := TibZoomFactorPercent.Percent125;
    1.50: Result := TibZoomFactorPercent.Percent150;
    1.75: Result := TibZoomFactorPercent.Percent175;
    2: Result := TibZoomFactorPercent.Percent200;
    2.50: Result := TibZoomFactorPercent.Percent250;
    3: Result := TibZoomFactorPercent.Percent300;
    4: Result := TibZoomFactorPercent.Percent400;
    5: Result := TibZoomFactorPercent.Percent500;
  end;
end;

[Bernhard Geyer]

Was spricht dagegen das du nur mit ganzen Prozentwerten arbeitest.
Damit hast du einen Integer und kannst wieder mit case-Statement arbeiten.

[haentschman]

Moin...

Zitat:

Wie kann ich das Problem lösen?

...den Eingangswert x 100 vor dem case.

[Sherlock]

Zitat von haentschman:

Moin...

Zitat:

Wie kann ich das Problem lösen?

...den Eingangswert x 100 vor dem case.

Trunc nicht vergessen, oder round, oder was auch immer genutzt wird, um ein Integer zu erhalten.

Gleitkommazahlen sind nun mal mathematisch keine Ordinalen.

Sherlock

[Uwe Raabe]

Dazu lässt sich 0.10 auch gar nicht exakt als Single darstellen.

[Redeemer]

Zitat von Uwe Raabe:

Dazu lässt sich 0.10 auch gar nicht exakt als Single darstellen.

Oder überhaupt als Kommazahl mit Exponenten-Basis 2.

[Rollo62]

Zitat von haentschman:

Moin...

Zitat:

Wie kann ich das Problem lösen?

...den Eingangswert x 100 vor dem case.

Das sehe ich auch als Lösung an, also konkreter mal so in der Art:

Delphi-Quellcode:

function TfrmEditor.GetZoomFactorAsPercent(
  AZoomFactor: Single = 1): TibZoomFactorPercent;
begin
  Result := TibZoomFactorPercent.Custom;
  case Trunc(AZoomFactor * 100) of // Hier tritt der Fehler auf...
      10: Result := TibZoomFactorPercent.Percent10;
      25: Result := TibZoomFactorPercent.Percent25;
      50: Result := TibZoomFactorPercent.Percent50;
      75: Result := TibZoomFactorPercent.Percent75;
    100: Result := TibZoomFactorPercent.Percent100;
    125: Result := TibZoomFactorPercent.Percent125;
    150: Result := TibZoomFactorPercent.Percent150;
    175: Result := TibZoomFactorPercent.Percent175;
    200: Result := TibZoomFactorPercent.Percent200;
    250: Result := TibZoomFactorPercent.Percent250;
    300: Result := TibZoomFactorPercent.Percent300;
    400: Result := TibZoomFactorPercent.Percent400;
    500: Result := TibZoomFactorPercent.Percent500;
  end;

Alles mit "Wert = 0.10" KANN nicht funktionieren, also genausowenig mit case,
weil man float Werte nicht einfach vergleichen kann.
(Siehe unten die Vorschläge mit SameValue)
Deshalb wird es ein case mit float nicht geben können.

[Medium]

Um den Grund an sich noch mal auf den Punkt zu bringen:

CASE und IF sind nur funktional miteinander verwandt. CASE war ursprünglich mehr als nur eine andere (kürzere) Schreibart für eine Kette von IF-Statements, da es dem Compiler hier einfacher war effizienteren Maschinencode daraus zu generieren. Einschränkung: Da dafür Sprungtabellen (bestehend aus relativen Adressen, die halt immer ganzzahlig sind) aus den zu unterscheidenden Werten gebildet wurden/werden, waren/sind nur solche als Kriterium zulässig. In Zeiten, in denen jeder einzelne Prozessorzylus noch in vielfachen (Dollar-)Cents zu bemessen war, war das eine lukrative Angelegenheit.
Und auch heute noch sind solche "kleinkarierten" Optimierungen hier und da noch messbare Vorteile - jedoch werden diese immer seltener, und das Argument der einfacheren Schreib-/Lesbarkeit ist in den Vordergrund gerückt. Welcher Seite man als Compiler-Hersteller nun die Stange hält, ist meiner Meinung nach weitestgehend Geschmackssache. Delphi hat die Optimierbarkeit beibehalten, und somit die Beschränkung auf Ordinaltypen. Will man das nicht, muss man mit diesem Compiler etwas tricksen um die Lesbarkeit zu erhalten, oder einen anderen wählen und die Optimierbarkeit aufgeben.

[himitsu]

Es gäbe aber keinen Grund Beides nicht zu kombinieren.

Wenn der CASE-Wert Ordinal ist, dann den optimierten Code generieren,
und ansonsten könnte der Compilier das notfalls auch als viele IF-ElseIf-ElseIf-...-Else umsetzen,
bzw. für Strings in ein CASE mit IndexStr/IndexText übersetzen usw.

Denn wenn wir versuchen das Vorhaben so zu optimieren, damit es ins CASE passt,
dann kommt weniger lesbarer Code bei raus, als wenn das der Compilier intern anpassen würde.


Genauso wie es echt saudoof ist, dass IN immernoch als grauenhaftes SET-Assembler übersetzt wird, anstatt es optional mit BitMasken oder InArray umzusetzen.
Oder dass CharInSet intern nur Mist macht und man den Dreck nicht wieder entfernt, weil IN durch ein IN in einer Funktion zu ersetzen, welche einfach nur die CompilerWarnung unterdrückt, dass ist sowas von schwachsinnig nutzlos.
Wobei das CharInSet-Problem sofort behoben ist, wenn man für "IN WideChar" die grade erwähnte Verbesserung hätte, oder einfach die selbe Codeoptimierug verwenden würde, wie aktuell beim CASE.

[Rollo62]

Zitat von Medium:

Und auch heute noch sind solche "kleinkarierten" Optimierungen hier und da noch messbare Vorteile - jedoch werden diese immer seltener, ...

Ich denke CASE hat durchaus seine Berechtigung behalten, wenn mehrere, vieleicht > 3 Fälle bearbeitet werden müssen.
Das sollte immer schneller sein als sequentielles IF.

Falls du Recht hast das dies nicht schneller ist würde es doch bedeuten
das der Compiler das IF intern doch als Sprungtabelle optimiert, oder nicht ?

Schneller wäre vielleicht nur ein Auslagern in Prozeduren-Pointer, als einfache State-Machine
statt CASE oder IF, aber auch das bezweifele ich wenn im case nur wenig gemacht wird.
Da kann der Compiler doch perfekt optimieren (wenn er das könnte).

Die Sprungtebellen der CPU sollten doch das effektivste Mittel bleiben, oder habe ich da was verpasst ?
(Ich habe aber die letzten Jahre intensives CPU-Technologie Studium geschwänzt, Hauptsache das Ding läuft )