AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Projekte HxD - schneller Hexeditor, Disk-Editor und RAM-Editor
Thema durchsuchen
Ansicht
Themen-Optionen

HxD - schneller Hexeditor, Disk-Editor und RAM-Editor

Ein Thema von mael · begonnen am 4. Feb 2005 · letzter Beitrag vom 11. Feb 2021
Antwort Antwort
Benutzerbild von jaenicke
jaenicke
Online

Registriert seit: 10. Jun 2003
Ort: Berlin
10.054 Beiträge
 
Delphi 12 Athens
 
#1

AW: HxD - schneller Hexeditor, Disk-Editor und RAM-Editor

  Alt 16. Jan 2016, 19:25
Danke für die Erklärung.
Ja, so ein Problem hatte ich auch schon. Bei mir ließ sich das so lösen, dass ich die Zwischenberechnungen weggelassen habe und direkt nur am Ende alles so berechnet habe, dass keine zu großen Zahlen entstehen. Aber das geht natürlich nicht immer...
Sebastian Jänicke
AppCentral
  Mit Zitat antworten Zitat
Benutzerbild von mael
mael

Registriert seit: 13. Jan 2005
391 Beiträge
 
Delphi XE3 Professional
 
#2

AW: HxD - schneller Hexeditor, Disk-Editor und RAM-Editor

  Alt 16. Jan 2016, 20:12
Durch deine Frage ist mir ein Vergleich zu Arduino eingefallen, hatte nie genauer darüber nachgedacht.

Interessanter Weise hat die map()-Funktion dort ein paar Probleme, und ich dachte schon die löst das clever :/ :
http://www.jetmore.org/john/blog/201...-distribution/
http://forum.arduino.cc/index.php/topic,72153.0.html
HxD, schneller Hexeditor:
http://mh-nexus.de/hxd

Geändert von mael (16. Jan 2016 um 20:26 Uhr)
  Mit Zitat antworten Zitat
Blup

Registriert seit: 7. Aug 2008
Ort: Brandenburg
1.492 Beiträge
 
Delphi 12 Athens
 
#3

AW: HxD - schneller Hexeditor, Disk-Editor und RAM-Editor

  Alt 18. Jan 2016, 14:28
Gerade beim Progressbar ist eine hohe Genauigkeit nicht erforderlich, mehr als 100 Positionen sind optisch kaum unterscheidbar.
Die Berechnung der neuen Progressbarposition darf sich dabei aber nur auf den neuen Absolutwert stützen.
Delphi-Quellcode:
{Die resultierende Position des Progressbar mit Wertebereich 0..1}
function NormalProgress(ACurrentPos, AMinPos, AMaxPos: Int64): Float;
begin
  Result := (ACurrentPos - AMinPos) / (AMaxPos - AMinPos);
end;

procedure SetProgressBarPos(APos, AMinPos, AMaxPos: Int64);
begin
  {z.B. Progressbar.Max = 100}
  ProgressBar.Position := Round(NormalProgress(Pos, AMinPos, AMaxPos) * ProgressBar.Max);
end;
  Mit Zitat antworten Zitat
Benutzerbild von mael
mael

Registriert seit: 13. Jan 2005
391 Beiträge
 
Delphi XE3 Professional
 
#4

AW: HxD - schneller Hexeditor, Disk-Editor und RAM-Editor

  Alt 19. Jan 2016, 06:23
Theoretisch sind so viele Stellen relevant wie Pixel am Schirm für den Fortschrittsbalken/Scrollleiste dargestellt werden, wird natürlich trotzdem < 10000 bleiben bei üblichen Auflösungen.

Aber das Problem ist auch die Rückkonvertierung, also aus der aktuellen Position der ScrollBar die Position innerhalb der Datei zu bestimmen. Ein Int64 kann nur näherungsweise in einem Double gespeichert werden. Da passiert es auch mal das hochgerundet wird und man dann nicht mehr in ein Int64 konvertieren kann, obwohl es gehen sollte. High(Int64) = 9223372036854775807 wird zu 9223372036854780000 wenn man es in ein Double konvertiert. Also größer als der größte Int64-Wert.

Delphi-Quellcode:
procedure FloatTests;
var
  i, i2: Int64;
  e: extended;
begin
  i := High(Int64);
  e := i;
  assert(e <= i); // wird nicht bemängelt obwohl eindeutig falsch unter x64
  i2 := Trunc(e); // erzeugt exception unter x64 (überlauf)
  assert(i = i2); // stimmt immer unter x86, egal welche Int64 man dem e zugewiesen hat
end;

Das könnte man vielleicht noch umgehen indem man zusichert dass der Double-Wert immer kleiner als der maximale Int64-Wert ist vor der Konvertierung.
Da Trunc und andere Rundungsmethoden aber alle Exceptions werfen, muss man also immer vorhersagen wann es (implizite) Rundungen geben könnte die den Wertebereich überschreiten. In diesem Fall wäre es problemlos bis High(Int64) - 512. 10-byte Extended hat das Problem nicht.


Also, so oder so, es sind deutlich mehr Prüfungen und Codereviews notwendig, da auch häufig mal implizit in Extended gerechnet wird in Delphi, wenn man keine expliziten Gleitkommatypen angibt. Also etwa sowas:
Delphi-Quellcode:
var
  i: Integer;
begin
  i := Round(i / 20);
end;
HxD, schneller Hexeditor:
http://mh-nexus.de/hxd

Geändert von mael (19. Jan 2016 um 06:30 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu
Online

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.542 Beiträge
 
Delphi 12 Athens
 
#5

AW: HxD - schneller Hexeditor, Disk-Editor und RAM-Editor

  Alt 19. Jan 2016, 09:47
Kommst du überhaupt in diesen Größenbereich?

RAM und Festplatten/Dateigrößen im Bereich von paar Exabyte.
Ein Therapeut entspricht 1024 Gigapeut.
  Mit Zitat antworten Zitat
Benutzerbild von Luckie
Luckie

Registriert seit: 29. Mai 2002
37.621 Beiträge
 
Delphi 2006 Professional
 
#6

AW: HxD - schneller Hexeditor, Disk-Editor und RAM-Editor

  Alt 19. Jan 2016, 11:51
Zitat:
Aber das Problem ist auch die Rückkonvertierung, also aus der aktuellen Position der ScrollBar die Position innerhalb der Datei zu bestimmen.
Moment. Um den Fortschritt anzeigen zu können, musst du doch schon vorher wissen an welcher Position du in der Datei bist. Was muss man da wieder zurück konvertieren? Oder habe ich hier jetzt ein Verständnisproblem?
Michael
Ein Teil meines Codes würde euch verunsichern.
  Mit Zitat antworten Zitat
Benutzerbild von mael
mael

Registriert seit: 13. Jan 2005
391 Beiträge
 
Delphi XE3 Professional
 
#7

AW: HxD - schneller Hexeditor, Disk-Editor und RAM-Editor

  Alt 19. Jan 2016, 16:24
Zitat:
Aber das Problem ist auch die Rückkonvertierung, also aus der aktuellen Position der ScrollBar die Position innerhalb der Datei zu bestimmen.
Moment. Um den Fortschritt anzeigen zu können, musst du doch schon vorher wissen an welcher Position du in der Datei bist. Was muss man da wieder zurück konvertieren? Oder habe ich hier jetzt ein Verständnisproblem?
Ich bin da vielleicht etwas konfus in meiner Beschreibung. Fortschrittsanzeige und ScrollBars haben nicht direkt was miteinander zu tun, haben nur verwandte Probleme insofern dass ich Gleitkommazahlen benötige.

Wenn ich mit der ScrollBar Thumbtracking mache (also diesen "Schieber" die Leiste entlangbewege -- Hey! Schiebeleiste wäre doch eine gute Übersetzung für ScrollBar... naja Bildlaufleiste gibt es ja schon, oder Rollleiste wäre eine Idee, hört sich aber komisch an, dann wäre der "Schieber" ein "Roller"... Übersetzungen sind immer so eine Sache ).

Also, wenn man den "Schieber" die Bildlaufleiste entlangbewegt kann man so eine Art wahlfreien Zugriff (random access) auf die Datei erzeugen. Abhängig davon wo man den Schieber mit der Maus hinbewegt und wie schnell kann es deutliche Sprünge von TScrollBar.Position geben. Man kann also nicht wie beim Klicken der "Hoch"/"Runter"-Knöpfe oder Scrollen per Mausrad schrittweise inkrementieren und so das Problem umgehen.

Also muss sowas in der Art berechnet werden:
DateiPosition := Round(ScrollBar.Position * Skalierungsfaktor);
Kommst du überhaupt in diesen Größenbereich?

RAM und Festplatten/Dateigrößen im Bereich von paar Exabyte.
Ist natürlich ein berechtigter Einwand. Hätte halt gerne vermieden solche Abschätzungen machen zu müssen ab wann ich Probleme mit Doubles bekomme.

Theoretisch ist die Grenze des virtuellen Arbeitsspeichers 8 EiB, praktisch ist er momentan unter Windows bei 8TiB bzw. 128 TiB (Memory Limits for Windows and Windows Server Releases).
D.h. momentan sind alle virtuellen Adressen <= $800000000000 (128TiB). $8000000000000000 (8EiB) ist $10000 mal größer als 128TiB. 128TiB würde also wohl noch in einen Double passen. Hmm, wäre also zumindest für den Moment kein Problem. Zukunftssicher wäre natürlich schöner.

P.S.: Man kann die hohen Adressen auch nicht in den meisten Fällen ignorieren da dort die System-Dlls geladen werden oder auch Programme vom Speicherallozierer fordern können Speicher in hohen Adressen zu bekommen (also vom Maximum abwärts "wachsend").
HxD, schneller Hexeditor:
http://mh-nexus.de/hxd

Geändert von mael (19. Jan 2016 um 16:48 Uhr) Grund: Falscher Wert für 128TiB angegeben
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:25 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz