Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Sonstige Fragen zu Delphi (https://www.delphipraxis.net/19-sonstige-fragen-zu-delphi/)
-   -   Delphi Algorithmus (https://www.delphipraxis.net/10705-algorithmus.html)

himitsu 24. Okt 2003 09:35

Re: Algorithmus
 
Liste der Anhänge anzeigen (Anzahl: 1)
@Curby
jetzt lass dich bloss nich verwirren.

Diese beiden Einträge (von "Jens Schumann" + diesen) sind zu Ermittlung der Häufigkeit aller Zeichen im Text.
Kannst es also als zusätzliche Lektüre betrachten.


@Jens Schumann - schneller:
keine reellen Variablen (Double) verwenden. Die Interger-Typen sind schneller.
Da viele Systeme auf 32-Bit ausgelegt und optimiert sind, läuft's mit dem Interger (32 Bit/4 Byte) an schnellsten.

Mit Integer läufter es bei mit etwa 3-mal schneller. (< 10 Sekunden)
Hab dein Prog entsprechend erweitert. Ausser der neuen Zeitmessung wurden nur deine Deklaration mit ins Butten1-Ereigniss verschoben (ändert aber nichts an der Geschwindigkeit)

Deine Test nach der Berechnung kannste auch weg lassen, ergeben immer 1/100. (wurden daher nicht mit in die Zeitmessung einbezogen)

> die Berechnungen laufen jeweils 10-mal durch, um Messungenauigkeiten... zu elliminieren.

Jens Schumann 24. Okt 2003 11:44

Re: Algorithmus
 
Hallo himitsu,
Häufigkeiten haben die Eigenschaft kleiner zu sein als 1.
Wie soll ich solch eine Wert in einem Integer speichern.
Ich könnte die Häufigkeiten *100 o. *1000 nehmen und dann als Integer speichern und
bei der Ausgabe wieder durch 100 o. 1000 teilen. Dann gehen mir aber Kommastellen verloren.

Die Tests habe ich mit Absicht eingefügt. Ersetze mal Double durch Single !!!

Dannyboy 24. Okt 2003 12:01

Re: Algorithmus
 
Zitat:

Zitat von Phoenix
Hrm. Ich würde da auch nur eine einzelne Funktion draus machen:

Delphi-Quellcode:
function GetCharCount(source: string; token: char): integer;
var
   i: integer;
begin
   result := 0;
   for i := 0 to length(source) - 1 do          
     if source[i] = token then
       inc(result);
end;


Be careful, Phoenix!!!!!
Bei Strings gilt immer Index (1 bis n) und NICHT Index (0 bis n-1) !!!
Ich erlaube mir mal, das zu korriegieren:

Delphi-Quellcode:
function GetCharCount(source: string; token: char): integer;
var
   i: integer;
begin
   result := 0;
   for i := 1 to length(source) do  // von 1 bis n
      if source[i] = token then
         inc(result);
end;

negaH 24. Okt 2003 12:54

Re: Algorithmus
 
@Jens Schumann, schau dir mein Posting mal genauer an :)

Hagen

himitsu 24. Okt 2003 12:54

Re: Algorithmus
 
@Jens
Das man die Interger noch scallieren muß, ist mir schon klar. War hier aber nicht nötig (Ist der Geschwindigkeitsoptimierung zum Opfer gefallen).
Delphi-Quellcode:
Series1.Add(MyArray[iCnt] / Gesamt, IntToStr(iCnt), clRed);
Zitat:

Die Tests habe ich mit Absicht eingefügt. Ersetze mal Double durch Single !!!
Brauch ich nicht. Selbst mit Double bekommt man einige Probleme, wenn die Dateien gösser werden.

Der Faktor fürs Scallieren kann ja frei gewählt werden. Bei 1000 liegt der Fehler unter 1 Promille.
Mit 1000 ist 'ne 2 MB Datei noch locker zu bearbeiten.
Mit Int64 (wird ja bald Standard, ist aber auch so schon schneller als reelle Typen) ist 'ne 2 GB Datei mit einer Genauikeit von 0,000001 möglich.

negaH 24. Okt 2003 13:01

Re: Algorithmus
 
@himitsu: die Notwendigkeit den Text mit AnsiUpperCase()/AnsiLowerCase() umzuwandeln besteht nicht. Statt dessen wird zB. mit meinem obigen Code einfach die Anzahl aller Zeichen ermittelt. Bei der Auswertung dieser Entropie werden nun einfach die Anzahlen von "a" und "A" addiert.
Eine vorherige Umwandlung mit AnsiUpper/LowerCase() ist inefizient.

Eine 2Gb Datei ist auch ohne Int64 möglich, es reicht Integer.

Gruß Hagen

himitsu 24. Okt 2003 13:15

Re: Algorithmus
 
2 MB = 2097152
2097152 * 1000 = 2097152000 (Skalierung mit 1000)

2097152000 (skalierte Anzahl der Zeichen in der Datei)
2147483647 (größter Integer)
2147483648000 (skalierte Anzahl der Zeichen einer 2 GB Datei)

negaH 24. Okt 2003 18:27

Re: Algorithmus
 
2 MB = 2.097.152

somit können in dieser Datei maximal nur 2.097.152 Zeichen im gesamten vorkommen.
Da ein Integer bis 2.147.483.647 geht also 2 Giga Byte, können mit ihm 2Gb Dateien bestehend aus einem einzigsten Zeichen zB. "A" eingelesen werden ohne Überlauf.
Nimmt man statt Integer einen Cardinal dann wären es sogar 4 Gb große Dateien.
Würde jedes der 256 möglichen Zeichen gleichverteilt vorkommen so könnte man sogar 1 Terra Byte große Dateien einlesen.

Deine Rechnungen sind inkorrekt, und ich verstehe nicht warum du mit 1000 skalieren willst ??

Wenn eine Datei 2 Mb groß ist und ein Zeichen 1 Byte, dann enthält die Datei 2.097.152 Bytes. Wenn diese Datei nur aus dem Zeichen 'A' besteht, also 2.097.152 mal 'A', dann wird man beim zählen der 'A's exakt auf 2.097.152 kommen. Wenn ein Integer bis 2.147.483.647 ohne Überlauf funktioniert dann heist dies das man diese "A" Datei 1024 mal nacheinander zählen könnte bis zum Überlauf. Selbst mit Skalierung von 1000 würde also kein Überlauf auftreten.
Will man wenig mehr dann nimmt man Cardinals und verdoppelt so nochmals die Auflösung. Dies wären dann 4 Giga Byte große Dateien.

Sorry, aber wenn ich was behaupte dann habe ich das nach 15 Jahren Programmeirerfahrung mindestens hundert mal durchgerechnet.


Gruß Hagen

himitsu 24. Okt 2003 19:25

Re: Algorithmus
 
War mir schon klar, aber Jens wollte halt mit Kommastellen rechnern.

Hast aber recht, habs mir nochmal durch den Kopf gehen lassen.
Wenn der Integer mit der Dateigrösse scalliert wird, gehen keine Kommastellen verloren und es passt eine 2 GB - 1 B Datei in den Integer rein.

:oops: Immer diese fehlgeleiteten Gedankengänge.

negaH 25. Okt 2003 11:51

Re: Algorithmus
 
No Problem :), das was mich ein leichtes bischen gestört hat, sorry für meine harschen Worte, ist das man manchmal erst schwatzt und dann nachdenkt ;)

Gruß Hagen


Alle Zeitangaben in WEZ +1. Es ist jetzt 07:31 Uhr.
Seite 2 von 2     12   

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