Lese Zahl in Zeile x aus Spalte y ein!

[Rayo]

Guten Morgen Javanesen

ich bin grade am einlesen dieser Textdatei:

111111111111111111011111111111
111100011000000000000010010001
110000000000000001010100010101
101000000000001000001001000011
100000000000000000010010010011
101010101100000001000100000011
100000100010100001100110010001
100010000100010011010000001111
111100011000000000000000100001
100010000000000010001000001101
110001000001100000100000000101
110010010000000000000010010011
100000010000011000000010000001
101001010000100000000100000001
101000001000000000010000010111
110000100000000100000000000001
100100110000000001010000010001
100000000010010010000000010101
100100000000010001000010001001
100000010000000000001000100001
100000001100110110000001001011
101100100000000010101000000011
100100000110001010110110010001
100001000011000000000111000111
111111111111111111111111111111

Mein Ziel ist, aus Zeile x und Spalte y den Wert einzulesen.
Ist dazu ein bestimmter Reader nötig welcher, eine Methode besitzt zu Stelle x, y zu springen?

 

[faetzminator]

Mach dir ein boolean[][] oder List<String> oder wie auch immer... Danach mit [c]array[y][x][/c] bzw. [c]list.get(y).charAt(x)[/c] o.ä.

 

[Michael...]

Mein Ziel ist, aus Zeile x und Spalte y den Wert einzulesen.
Ist dazu ein bestimmter Reader nötig welcher eine Methode besitzt zu Stelle x, y zu springen?

Nein, hier kann man mit einem einfachen BufferedReader die Datei zeilenweise einlesen. In Daten an eine bestimmte Stelle springen geht ohnehin nicht.
Je nach Umfang der Datei und dem geplanten Lese/"Spring"verhalten macht es Sinn den Inhalt bzw. die einzelenen Zeilen der Datei in einem eigenen Objekt zu halten, welches eine Methode gibMirDenInhaltVon(int x, int y) anbietet.

 

[Rayo]

und wie würde ich es dann im Reader einbinden? Der Reader selbst besitzt nämlich keine solche Methode...

 

[L-ectron-X]

Scanner aus java.util liest auch zeilenweise ein: Scanner (Java Platform SE 7 )

 

[Michael...]

und wie würde ich es dann im Reader einbinden? Der Reader selbst besitzt nämlich keine solche Methode...

Im Reader einbinden? Dann müsstest Du von BufferedReader erben und diesen u.a. um diese Methode erweitern. In dem Du bei jedem gibXY(...) die Datei neu von vorne bis zur gewünschten Stelle einliest.
Das macht m.M. aber keinen Sinn. Ich nehme mal an es sollen verschiedene Werte an unterschiedlichen Stellen ausgelesen werden? Dann definiere Dir - wie gesagt - eine Klasse, die den Dateiinhalt repräsentieren kann und eine solche Methode anbietet.

 

[Rayo]

@Michael
Die Frage galt ehr faetzminator, da ich deinen Beitrag davor nicht gelesen hab.

@L-ectron-X
Das klingt nach einer recht einfachen Lösung!
Heißt das, dass der Scanner auch ein "Reader" ist? Wenn es klappt erhälst du ein Danke von mir.

 

[L-ectron-X]

Scanner kann Zeichenketten aus verschiedenen Datensenken einlesen.
Bspw. direkt aus einem String, aus einer Datei, einem Stream etc., über Umwege auch von URLs.

 

[Michael...]

@Michael
Die Frage galt ehr faetzminator, da ich deinen Beitrag davor nicht gelesen hab.

@L-ectron-X
Das klingt nach einer recht einfachen Lösung!
Heißt das, dass der Scanner auch ein "Reader" ist? Wenn es klappt erhälst du ein Danke von mir.

faetzminators Beitrag zielt auf das selbe ab und den Hinweis von L-ectron-X würde ich deuten als: Man kann (neben dem BufferedReader) auch mit Scanner Textdateien zeilenweise einlesen.

 

[L-ectron-X]

Genauso war es gedacht. Allerdings halte ich den Scanner für etwas komfortabler.

 

[faetzminator]

Nicht gerade schön, sollte aber laufen:

public boolean[][] readFile(File file) throws IOException {
    List<boolean[]> list = new ArrayList<boolean[]>();
    BufferedReader br = new BufferedReader(new FileReader(file));
    String line;
    while ((line = br.readLine()) != null) {
        boolean[] array = new boolean[line.length()];
        for (int i = 0; i < array.length; i++) {
            array[i] = "1".equals(line.charAt(i));
        }
    }
    return list.toArray(new boolean[list.size()][]);
}

 

[Rayo]

Naja, das Thema ist erledigt, ich hab es mit dem Scanner hinbekommen, danke an alle die mir geantwortet haben.

 

[hüteüberhüte]

Das Problem ist, dass die Datei sequenziell eingelesen werden muss. Einen wahlfreien Zugriff gibt es nicht. Aber der Inhalt kann in eine solche Datenstruktur geladen werden

 

[Mujahiddin]

Wenn jede Zeile gleichlang ist, kannst du auch RandomAccessFile verwenden.
Wenn es sehr viele Zeilen sind, wäre es sehr umständlich, jedes mal einen BufferedReader anzuhauen. Du könntest zwar das ganze in einem zweidimensionalen Array speichern, aber bei sehr großen Dateien wird das viel Arbeitsspeicher in Anspruch nehmen.
Ein RandomAccessFile kann aber nicht direkt auf die .jar zugreifen - falls deine Datei also im Archiv ist, würde ich davon abraten.

private static final char readInt(File f, int x, int y) throws IOException {
	try(RandomAccessFile raf = new RandomAccessFile(f, "r");) {
		final int lineLength = raf.readLine().getBytes().length;
		raf.seek(x*lineLength + y*2);
		return raf.readChar();
	}
}

 

[hüteüberhüte]

Wenn jede Zeile gleichlang ist, kannst du auch RandomAccessFile verwenden.
Wenn es sehr viele Zeilen sind, wäre es sehr umständlich, jedes mal einen BufferedReader anzuhauen. Du könntest zwar das ganze in einem zweidimensionalen Array speichern, aber bei sehr großen Dateien wird das viel Arbeitsspeicher in Anspruch nehmen.
Ein RandomAccessFile kann aber nicht direkt auf die .jar zugreifen - falls deine Datei also im Archiv ist, würde ich davon abraten.

1. Liest man mit BufferedReader ein File nur einmal ein
2. Ist das Beispiel so winzig, dass der Cache/RAM völlig ausreicht
3. Ist RandomAccessFile bei mehreren Zugriffen langsam

 

[Mujahiddin]

1. Liest man mit BufferedReader ein File nur einmal ein
2. Ist das Beispiel so winzig, dass der Cache/RAM völlig ausreicht
3. Ist RandomAccessFile bei mehreren Zugriffen langsam

1. Das meinte ich nicht. Wenn mehrere solche Anfragen zu verschiedenen Zeitpunkten gesendet werden, müsste er entweder die gesamte Datei in einem String (oder String-Array) speichern; oder den BufferedReader offenhalten (und somit die Datei blockieren) oder jedes Mal einen neuen BufferedReader erstellen.
2. Sein Beispiel war winzig, aber ich persönlich weiß nicht, wofür die Frage formuliert war, weißt du es? Vielleicht arbeitet er für eine Firma und rein theoretisch wäre es möglich, dass bei besagter Firma MB-große Dateien nach diesem Muster aufgebaut sind.
3. Davon weiß ich nichts.

 

[Hüte]

Zu 1: Sieh dir doch mal das Beispiel von faetzminator an, readFile muss während der Laufzeit des Programms nur einmal aufgerufen werden. Alles andere wäre Käse
2: Nehme ich bei einer Frage nicht das fast Auszuschließende an, sonder das Naheliegendste
3: (zynischer Kommentar verkniffen)

 

[Spacerat]

@Hüte: Mal 'ne Frage... Wozu gibt es RandomAccessFile eigentlich, wenn der Zugriff auf Dateien langsamer wär, als bei Streams oder Readern? RandomAccess könnte man sich nämlich auch mit Pipes zusammenfrickeln. RandomAccessFile hätte damit keinerlei Existenzberechtigung mehr.
Ne, ernsthaft, was könnten denn da noch für zynische Kommentare kommen? RandomAccessFile bietet allemale den schnellsten, komfortabelsten und sogar speichersparendsten Zugriff auf jedwede Datei. Tut es das nicht, wird's Zeit, dass man die (Fest)Platte putzt (defragmentiert).
Schon allein die Tatsache, dass die Kern-Lese- unt Schreiboperationen native von statten gehen, lässt irgendwie darauf schliessen, dass Java hier das native Dateisystem nebst nativen Cache usw. nutzt, schneller geht's kaum, nur bei Heap belastenden Streams bzw. Readern.

 

[hüteüberhüte]

Ist irgendwie logisch, dass für den Zugriff letztendlich der Schreib- und Lesekopf der Festplatte bewegt werden muss. Damit erübrigt sich jede weitere Erklärung, denn das ist, weil mechanisch, das langsamste Bauteil
Von mir aus kann Mujahiddin noch 10 likes für einen Beitrag geben, am grundlegendem Prinzip ändert das nix

Um das mit Zahlen zu belegen, müsste erst klar sein, wie schnell die Festplatte ist, wie groß das File und wie oft eine Zahl angefordert wird

 

[Spacerat]

Ist irgendwie logisch, dass für den Zugriff letztendlich der Schreib- und Lesekopf der Festplatte bewegt werden muss. Damit erübrigt sich jede weitere Erklärung, denn das ist, weil mechanisch, das langsamste Bauteil
Von mir aus kann Mujahiddin noch 10 likes für einen Beitrag geben, am grundlegendem Prinzip ändert das nix

Um das mit Zahlen zu belegen, müsste erst klar sein, wie schnell die Festplatte ist, wie groß das File und wie oft eine Zahl angefordert wird

Die Trägheit der Leseköpfe ist ja ein schlagendes Argument. :autsch: War es zumindest vor ca. 15 Jahren mal. Heute jedoch arbeiten Massenspeicher mit Caches und Anzahl der Umdrehungen, sowie Positionierung der Leseköpfe ist erstmal Nebensache (ausser evtl. bei SSD-Laufwerken oder USB-Sticks, wo Verzögerungszeiten eher elektoteschnischer Natur sind). Mal rein hypothetisch: Weisst du wofür es (bzw. das es überhaupt) die Funktion "Hardware sicher entfernen" bei Massenspeichern gibt? Ich geh' mal davon aus, dass du, wie geschätzt 80% der Leute, die sich mit PCs auskennen wollen, diese Funktion ignorierst und dich anschliessend über Datenverlusst ärgerst. Wie auch immer... diese Funktion leert den Cache und schreibt evtl. noch vorhandene Daten auf den Massenspeicher.
Alles in Allem wird ein Massenspeicher ebenso wie ein Stream genau erst dann langsamer, wenn man exessiv Daten darin bewegt (massenweise Daten überfluten den Cache) und um dass mit Zahlen zu belegen, helfen nur Benchmarks mit abgeschaltetem Multitasking in Assembler.

 

[Mujahiddin]

Von mir aus kann Mujahiddin noch 10 likes für einen Beitrag geben, am grundlegendem Prinzip ändert das nix

Die Dinger heißen "Danke" und man kann pro Post nur einen davon geben. 400 Beiträge und keine Ahnung vom Forum!

Spaß beiseite, hast du was gegen mich? Postest ständig unter mir und beschwerst dich oder sonst was.

 

[hüteüberhüte]

Die Trägheit der Leseköpfe ist ja ein schlagendes Argument. :autsch: War es zumindest vor ca. 15 Jahren mal. Heute jedoch arbeiten Massenspeicher mit Caches und Anzahl der Umdrehungen, sowie Positionierung der Leseköpfe ist erstmal Nebensache (ausser evtl. bei SSD-Laufwerken oder USB-Sticks, wo Verzögerungszeiten eher elektoteschnischer Natur sind). Mal rein hypothetisch: Weisst du wofür es (bzw. das es überhaupt) die Funktion "Hardware sicher entfernen" bei Massenspeichern gibt? Ich geh' mal davon aus, dass du, wie geschätzt 80% der Leute, die sich mit PCs auskennen wollen, diese Funktion ignorierst und dich anschliessend über Datenverlusst ärgerst. Wie auch immer... diese Funktion leert den Cache und schreibt evtl. noch vorhandene Daten auf den Massenspeicher.
Alles in Allem wird ein Massenspeicher ebenso wie ein Stream genau erst dann langsamer, wenn man exessiv Daten darin bewegt (massenweise Daten überfluten den Cache) und um dass mit Zahlen zu belegen, helfen nur Benchmarks mit abgeschaltetem Multitasking in Assembler.

Ja klar, Festplatten sind schneller als RAM/Cache.. lol
Und was hat "sicheres Entfernen" mit dem Thema zu tun.. nix

Es bleibt dabei, dass so und so viele Zugriffe auf die Festplatte langsamer sind, als das File einmal einzulesen

Die Dinger heißen "Danke" und man kann pro Post nur einen davon geben. 400 Beiträge und keine Ahnung vom Forum!

Spaß beiseite, hast du was gegen mich? Postest ständig unter mir und beschwerst dich oder sonst was.

Ne, wieso? Etwas richtigstellen darf ich wohl noch. Viel eher sind deine konträren Beiträge auffällig

 

[Mujahiddin]

Ne, wieso? Etwas richtigstellen darf ich wohl noch. Viel eher sind deine konträren Beiträge auffällig

Okay, etwas richtigstellen klingt in meinen Augen anders:

1. Liest man mit BufferedReader ein File nur einmal ein
2. Ist das Beispiel so winzig, dass der Cache/RAM völlig ausreicht
3. Ist RandomAccessFile bei mehreren Zugriffen langsam

Du hast meinen Post schon genau gelesen, oder?

Wenn es sehr viele Zeilen sind, wäre es sehr umständlich, jedes mal einen BufferedReader anzuhauen. Du könntest zwar das ganze in einem zweidimensionalen Array speichern, aber bei sehr großen Dateien wird das viel Arbeitsspeicher in Anspruch nehmen.

Ich habe mein Beispiel damit eingeleitet, dass bei sehr großen Dateien ein RAF eher geeignet wäre als den Arbeitsspeicher auszulasten. Du meckerst rum, weil ich über die Aufgabenstellung hinausschaue. Nirgends in der Frage war erwähnt "es handelt sich nur um minimale Dateien". Du ziehst dir also Sachen aus der Nase.

Wieso erwähnst du also Sachen, die ich schon ausgeräumt hatte?

 

[Spacerat]

Ja klar, Festplatten sind schneller als RAM/Cache.. lol
Und was hat "sicheres Entfernen" mit dem Thema zu tun.. nix

Es bleibt dabei, dass so und so viele Zugriffe auf die Festplatte langsamer sind, als das File einmal einzulesen.

Was soll' ich sagen...
1. zu dir: wenn du meinst.
2. zu allen anderen: RandomAccessFile cached die gelesene Datei (native statt im Heap). Soviel zum Thema x-maliger Plattenzugriff und langsamer. Und wenn Java abstürzt, wird die Datei auch meistens wieder freigegeben, aber es gibt Programme, wo das nicht der Fall ist und die Daten im Cache bleiben. Geänderte Daten verschwinden dann im Walhalah oder sonst wo und der Massenspeicher wird inkonsistent. [IRONIE]Mit "sicheres Entfernen" hat das nur sehr wenig zu tun.[/IRONIE]

 

[Hüte]

@Spacerat: Du weißt doch gar nicht, wie viel von einer Datei gecached wird. Außerdem öffnet Mujahiddin's Code auch noch jedes mal ein neues File

@Mujahiddin: Ist "über die Aufgabenstellung hinausschauen" ein neues Wort für nix verstanden haben?

Langsam macht es echt keinen Sinn mehr, sich mit euch weiter zu unterhalten. Bleibt bei eurer Meinung und freut euch

 

[Spacerat]

@Spacerat: Du weißt doch gar nicht, wie viel von einer Datei gecached wird.

Und woher weisst du, dass ich das nicht weiss? Solange die Datei nicht grösser als 8MB ist, landet sie komplett im Cache. Wer garantiert dir eigentlich, dass die Daten im Heap nicht Betriebssystem bedingt im Virtuellen Speicher auf der Festplatte landen? Niemand!
Ob ihr zwei da nun 1000 Mal ein und die selbe Datei öffnet, lest und wieder schliesst (was per nativen Cache theoretisch ohnehin schneller gehen dürfte) ist dabei nicht relevant. Relevant ist nur, dass es nicht gerade gut ist, im Anfängerforum ungesundes Halbwissen ohne Beweise gnadenlos zu verteidigen, nur damit man keinen Moralischen bekommt.
Fakt ist und bleibt, dass RandomAccessFile durchaus seine Existensberechtigung hat (gerade bei RandomAccess) und in den meisten Fällen definitiv schneller ist, als es Streams jemals sein können. Deine Argumentation - RandomAccessFile sei grundsätzlich lahm - aber lässt den Anschein erwecken, als wäre das nicht so. Keine Frage, bei so kleinen Dingen eignen sich Streams bzw. Reader/Writer mehr, obwohl inda auch mehr zum Scanner tendiere, aber wer bitte schön läd schon X-MB in den Heap (der Puffer des BufferedReaders) nur um diese anschliessend dem Wohlwollen des GC zu überlassen?
Mujahiddins Idee war ja auch eben nur auf grössere Projekte bezogen. Von uns weiss ja nun auch keiner, wie gross die Datei im Beispiel in der Realität ist. Alles andere aber lässt sich nach lesen.

 

[Mujahiddin]

: Du weißt doch gar nicht, wie viel von einer Datei gecached wird. Außerdem öffnet Mujahiddin's Code auch noch jedes mal ein neues File

: Ist "über die Aufgabenstellung hinausschauen" ein neues Wort für nix verstanden haben?

Langsam macht es echt keinen Sinn mehr, sich mit euch weiter zu unterhalten. Bleibt bei eurer Meinung und freut euch

Nix verstehen tust hier anscheinend nur du... Ich sagte: Für kleine Dateien = Reader, für große Dateien = RAF. Nicht mehr, nicht weniger. Ich habe mich selbst falsch ausgedrückt, indem ich meinte "über die Aufgabenstellung hinausschauen". Ich hätte eher "Eventualitäten klären" sagen sollen. Falls du in deinen Projekten weder Exceptions abfängst, noch Ausnahmefälle in Betracht ziehst, dann sei das so, aber akzeptiere bitte, dass es Leute wie mich gibt, die über den Horizont hinausschauen können. Ohne arrogant klingen zu wollen!

Mach's gut!

 

[hüteüberhüte]

Dann macht doch einen Test. Erstellt etwa eine 10 MB große Datei (Editor öffnen, Strg+A=alles markieren, Strg+C=kopieren, Strg+V=einfügen) und greift etwa 10-mal so oft auf die Datei zu mit RandomAccessFile (etwa 100.000.000-mal), und lest sie einmal mit BufferedReader ein und greift auch wieder darauf zu. Das dürfte aber stark System- und Hardwareabhängig sein

Ich mache das nicht

Und warum sollte der Puffer des BufferedReaders MB-groß sein? Das ist m.M.n. "gefährliches Halbwissen". Außerdem sprach ich von einem Vergleich zwischen x Zugriffen auf eine Datei und x Zugriffen auf eine Datenstruktur. Nicht davon, dass RandomAccessFile generell langsam sei. Das hast du, Spacerat, also aus dem Kontext genommen und völlig falsch wiedergegeben

Mujahiddin hat das einfach nachgeplappert/kritiklos übernommen, um seine Idee zu protegieren

 

[Spacerat]

Und warum sollte der Puffer des BufferedReaders MB-groß sein? Das ist m.M.n. "gefährliches Halbwissen".

Weil er nun mal soviel buffert... wenn die Datei entsprechend groß ist.

Außerdem sprach ich von einem Vergleich zwischen x Zugriffen auf eine Datei und x Zugriffen auf eine Datenstruktur. Nicht davon, dass RandomAccessFile generell langsam sei. Das hast du, Spacerat, also aus dem Kontext genommen und völlig falsch wiedergegeben

Jeder dreht sich's wie er's gern hätt'.

 

[bone2]

Die Trägheit der Leseköpfe ist ja ein schlagendes Argument.

Auch heute noch. Siehe jeden Random Acces Benchmark. In CPU Zeit vergehen da Lichjahre und Milliarden Cycles verbringt der CPU mit warten.
Allerdings hat man die Probleme bei größeren Files auch mit Streamen, da die Chancen gut stehen, das sie fragmentiert ist.
Da man RAM in Mengen hinterhergeschmissen bekommt, die sowieso fast niemand ausnutzen kann, würde ich je nach Dateigröße (<1GB) und Anteil der Bytes die man nun eigentlich braucht auch eher alles in den Ram laden statt random von Festplatte zu lesen. Wenn man nun aber 500MB Files hat und aus jedem nur 5 Zahlen lesen will, ist RAF ganz offensichtlich die bessere Wahl.

 

[JCODA]

In CPU Zeit vergehen da Lichjahre

Wohin denn? :joke:

Leute beruhigt euch doch

 

[Mujahiddin]

Auch heute noch. Siehe jeden Random Acces Benchmark. In CPU Zeit vergehen da Lichjahre und Milliarden Cycles verbringt der CPU mit warten.
Allerdings hat man die Probleme bei größeren Files auch mit Streamen, da die Chancen gut stehen, das sie fragmentiert ist.
Da man RAM in Mengen hinterhergeschmissen bekommt, die sowieso fast niemand ausnutzen kann, würde ich je nach Dateigröße (<1GB) und Anteil der Bytes die man nun eigentlich braucht auch eher alles in den Ram laden statt random von Festplatte zu lesen. Wenn man nun aber 500MB Files hat und aus jedem nur 5 Zahlen lesen will, ist RAF ganz offensichtlich die bessere Wahl.

Klar hat heutzutage jeder PC übermäßig viel RAM. Aber oft wird dieser RAM für viele Sachen genutzt. Ja, für 10MB große Dateien ist das vielleicht noch nicht so erheblich ob RAF oder BR, aber mein Beitrag hat ja - wie schon 100mal gesagt - ausgeräumt, dass es sich um sehr große Dateien handeln müsste, um das in Erwägung zu ziehen.
Ich selbst verwende RAF auch nur in den allerseltensten Fällen...
Ich hoffe, damit wäre das Thema geklärt.

 

[hüteüberhüte]

[OT]

Jeder dreht sich's wie er's gern hätt'.

Btw: Bei den Kurzformen von "sich es" und "er es" muss das Semikolon nicht gesetzt werden Das "e" kommt einfach zu häufig vor, deshalb bedarf es keines Semikolons, um daran zu erinnern [/OT]

 

[hüteüberhüte]

Klar hat heutzutage jeder PC übermäßig viel RAM. Aber oft wird dieser RAM für viele Sachen genutzt. Ja, für 10MB große Dateien ist das vielleicht noch nicht so erheblich ob RAF oder BR, aber mein Beitrag hat ja - wie schon 100mal gesagt - ausgeräumt, dass es sich um sehr große Dateien handeln müsste, um das in Erwägung zu ziehen.
Ich selbst verwende RAF auch nur in den allerseltensten Fällen...
Ich hoffe, damit wäre das Thema geklärt.

Es kommt immer noch auf das Verhältnis zwischen Dateigröße und Anzahl der Zugriffe an, außerdem um eine gewisse Mindestgröße der Datei, ab der sie vom OS/Hardware nicht mehr gecached wird. Aber gut, in diesem Fall tappen wir da im Dunkeln

 

[Mujahiddin]

[OT]

Btw: Bei den Kurzformen von "sich es" und "er es" muss das Semikolon nicht gesetzt werden Das "e" kommt einfach zu häufig vor, deshalb bedarf es keines Semikolons, um daran zu erinnern [/OT]

Apostroph*, Semikolon == ";"

 

[Mujahiddin]

Mal eine Frage (ich denke, es passt hier rein )

Files (Java Platform SE 7 )

Was spricht denn gegen diese Methode? (

Files.readAllLines( Path path, Charset cs );

). Liefert List<String> zurück. Gibt es einen Nachteil zu BufferedReader?

 

[hüteüberhüte]

Den einzigen Nachteil, den ich sehe:

Since: 1.7

Das ist Hexenwerk