Umgang mit referenzierten Arrays: Schön schreiben No. 2 (gelöst) (Allgemeines zu Perl)

[thread]16767[/thread]

Umgang mit referenzierten Arrays: Schön schreiben No. 2 [gelöst]

Leser: 24

Articles: hide open all | hide show old branches

+9 replies
Sven_123

2011-09-30 11:50
User since
2010-06-01
120 Artikel
BenutzerIn
Hallo,
Moritz' Vorschlag, Variablen, die ich aus einer Datei auslese einfach komplett in einem Hash zu speichern, hat mich auf etwas gebracht, dass ich bei dem Programm, das ich grad schreib gern ändern würde.
Nochmal: Ich lese aus einer Datei, abhängig von verschiedenen Optionen Informationen aus, um sie weiter zu benutzen - z.B. Gradienten. Bisher hatte ich eine Variable @grad, in der immer der Gradient zu den aktuellen Optionen gespeichert war, aus Vergleichsgründen wäre es allerdings manchmal nicht schlecht verschiedene Gradienten zu speichern. Eine Möglichkeit wär nun zig Variablen einzuführen, die ich nach den verschiedenen Optionen benenn, besser gefällt mir allerdings einfach nur einen Hash zu haben, in dem ich dann unter z.B. @{$var{'grad'}{'modus1'}} das Zeug abspeicher.

Da ich aber viel mit den Informationen rumrechne, wird es irgendwann unübersichtlich, wenn ich das "{'grad'}{'modus1'}" etc. immer mitschleifen muss, weswegen ich trotzdem gerne eine Variable, z.B. @grad mitführen würde, die immer auf die entsprechende Information des aktuellen Modus zeigt. An einer einfachen Referenz, wie im ersten Teil des Beispiels hier gezeigt gefallen mir aber die $ und -> nicht so sehr (Zeile 15). Lieber wäre es mir, wirklich die Arrayreferenzen in einem eigenen Array abzuspeichern, wie im zweiten Teil gezeigt:
Code (perl): (dl )

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

#!/usr/bin/perl use strict; use warnings; use Data::Dumper; #+~~~~~~~ Referenz { my %vars; my $mode = 1; my $curr_grad =\$vars{'gradient'}{$mode}; #...tu was... $vars{'gradient'}{1} = [[1,1,1],[1,2,3]]; print $$curr_grad->[1][1]++,"\n"; print $vars{'gradient'}{$mode}[1][1],"\n"; } #+~~~~~~~ Array { my %vars; my $mode = 1; $vars{'gradient'}{1} = [[],[]]; my @curr_grad = @{$vars{'gradient'}{$mode}}; #...tu was... (@{$vars{'gradient'}{1}[0]}[0..2],@{$vars{'gradient'}{1}[1]}[0..2]) = ((1,1,1),(1,2,3)); print $curr_grad[1][1]++,"\n"; print $vars{'gradient'}{$mode}[1][1],"\n"; }
Unten stört mich ein bisschen die Notwändigkeit $vars{'gradient'}{1} erst befüllen zu müssen (Zeile 23), aber v.a., dass man beim Befüllen der Arrays wahnsinnig vorsichtig und umständlich sein muss (Zeile 27), dass man nicht plötzlich einen neuen anonymen Array erstellt.

Ich hab mich noch für keine der beiden Methoden entschieden, entweder ich nehm das kleinere Übel (Zeile 15, die Referenzen) oft in Kauf, oder das große (Zeile 27, das Array Befüllen) nur ein paar mal...

Gibt es sinnvolle, gänzlich andere Methoden, oder hat jemand Vorschläge, wie ich bei einem der beiden noch was verbessern kann?
- +6 replies
- rosti
  
  2011-09-30 17:40
  User since
  2011-03-19
  3502 Artikel
  BenutzerIn
  Moritz Vorschlag ist doch gut. Warum ein Array extra führen? Das ist in einem Hash genausogut aufgehoben.
  
  Mein ergänzender Vorschlag dazu (falls das Moritz nicht schon geschrieben hat): Schreibe eine Klasse zum entsprechenden Dateityp. Das gibt eine Datenstruktur, die rein- oder rauskommt. Deine Anwendung jedoch, die greift NICHT in die Datenstruktur, die ruft NUR Methoden auf.
  
  Weil: Falls sich mal an der Datenstruktur was ändert, muss das nur in der Klasse gemacht werden.
  
  Dein Array kriegt ganz einfach eine Methode, welche das Array zurückgibt (oder eine Array-Referenz). Dann könnte es noch Methoden geben wie insert, update, delete. Jow, beim Hash geht das delete besonders schön ;)
  
  Die letzte zu schreibende Methode heißt $myObject->store und schreibt den ganzen Kram zurück in die Datei.
  
  Schleife im Objekt das Handle mit und auch den Dateinamen, das hilft beim Debuggen solcher Sachen. Übergeben bei der Objekterstellung die Möglichkeit zum flock() und prüfe, ob ein Lock gesetzt werden konnte. Alles schön in Attribute schreiben.
  
  Code (perl): (dl )
  
  1 2 3
  
  use strict; use warnings; use Carp;
  
  .. und alles wird gut ;)
  
  Viel Spaß dabei!
  
  PS: use IO::File;
  
  Nochn Beispiel für weitere Entwicklungen. Gerne würde ich Dir das Modul mal eben komplett schreiben, es macht doch Spaß!
  
  Aber machs mal selber ;)
  
  Hier Dein Einstieg:
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
  
  use Storable qw(freeze thaw); # example of data structure my $r = { ARRAY => [localtime], HASH => \%ENV, }; # hier die Möglichkeiten zum Speichern in einer Datei # Herzstück ist freeze() und thaw() # mit IO::File dann weitermachen.... my $bin = freeze $r; # Serialize my $rep = thaw $bin; # Deserialize # test it #print dump $rep; # Entwicklung in Richtung Klasse # Zum testen wird das Objekt hier zu einer Instanz der main-Class gemacht bless $r, __PACKAGE__; # main-Class # damit kann nun eine Methode aufgerufen werden $r->printarray; sub printarray{ my $self = shift; # extrahiere Instanz foreach my $e( @{$self->{ARRAY}} ){ print "$e\n", } return $self->{ARRAY}; # falls wir das Array draußen brauchen }
  
  Ergo: Überlege Dir eine "schöne" Datenstrukur für das Objekt (die Instanz Deiner Klasse). Dateianbindung: Storable.pm hat neben freeze/thaw auch Methoden, die direkt mit dem Dateihandle umgehen können, das kannst Du vorzüglich nutzen. Das wird auch sehr performant, Du wirst Dich wundern, wie "schön" das dann geht ;)
  
  IO::File importiert auch die Flags (Konstanten) welche den Modus des FH bestimmen, z.B. O_CREAT|O_BINARY|O_RDWR. Weitere Konstanten importiert Fcntl.pm.
  
  use Fcntl qw(:DEFAULT :flock); # falls Du FH locken musst
  
  Wobei :DEFAULT bereits von IO:File importiert wird.
  Last edited: 2011-10-01 10:09:43 +0200 (CEST)
  - +5 replies
  - Sven_123
    
    2011-10-04 16:30
    
    User since
    2010-06-01
    120 Artikel
    BenutzerIn
    
    Es kann sein, dass ich nicht verstanden hab, was du mit ner Klasse erreichen willst - falls doch:
    
    Es geht mir in erster Linie darum, dass ich in meinem Programm nach dem Auslesen der Variablen noch einiges mit ihnen rechne und riesige Variablennamen (also die Hash-keys) das dann doch unübersichtlich machen. Zudem sollen Leute, die sich nicht so viel mit Perl selbst beschäftigen wie ich das Programm lesen und auch ändern können. V.a. an den Stellen wo eben gerechnet, oder am Ende was rausgeschrieben wird. Das Einlesen ist ziemlich fix und uninteressant. Deswegen wollte ich auch möglichst die Referenz-auflösenden Pfeile und $$ umgehen.
    
    Da ich aber ab und zu Vergleiche zwischen ausgelesenen Informationen ziehen möchte, oder zumindest gerne die Möglichkeit dazu hab, war mein Plan, optional wirklich alles auslesen zu können und dann in verschiedenen Variablen in nem Hash zu speichern. Dabei werden viele Rechnungen dann aber nur mit einer bestimmten durchgeführt.
    
    Ich wollte zu Beginn, wenn die Parameter eingelesen werden festlegen @grad ist diesmal z.B. der Array, der unter $var{'grad'}{'mode1'} abgelegt ist, dann das ganze Zeug auslesen und dann sehr bequem mit @grad rechnen können, ohne immer ein $var{'grad'}{$mode} schreiben zu müssen.
    Was natürlich ginge, wäre, den Array, der in @grad gespeichert sein soll erst nach dem Auslesen festzulegen, aber da ich in dem Programm teilweise öfters ähnliche Dinge ausles, die ich dazwischen schon brauch, würde das definieren der Variablen ziemlich verstreut im Code passieren, und nicht schön geordnet an einer Stelle...
    
    Als Auswege die mir einfallen bleiben entweder, 1. im Vorfeld eine Referenz auf die noch nicht befüllte Arrayreferenz $grad = \$var{'grad'}{'mode1'}, mit dem Nachteil, dass ich Elemente dann mit $$grad->[...] dereferenzieren muss, dem Vorteil, dass ich beim Auslesen keine Rücksicht nehmen muss, 2. alle Elemente zu initialisieren(?) $var{'grad'}{'mode1'} = [[],[],...] und dann den Array zu übernehmen @grad = @{$var{'grad'}{'mode1'}}, was aber den Nachteil hat, dass ich beim Befüllen von dem Hash arg aufpassen muss, die Referenzen an sich unangetastet zu lassen und 3. ein Mittelding, wie es pq in ihrer Antwort beschrieben hat.
    
    Eine eigene Klasse für den Gradienten, z.B. würde, so wie ich es mir vorstell, ja nur eine Schnittstelle für das Befüllen und z.B. Referenz zurückgeben darstellen, bzw. die Routinen dafür auslagern, aber keine der drei Möglichkeiten grundlegend ändern oder?
    
    (Und ja - das Programmieren macht Spaß, das hier ist deswegen auch weniger ein "ich weiß gar nicht, wie ich es machen soll", als ein, "wie mach ich es besonders ausgeklügelt", weshalb ich so genau nachhak und mich nicht mit "so funktioniert's"-Lösungen zufrieden geb. Freu mich trotzdem drüber, um andere Sichtweisen zu bekommen... ;))
    - +4 replies
    - rosti
      
      2011-10-04 19:40
      
      User since
      2011-03-19
      3502 Artikel
      BenutzerIn
      
      Arrays in einem Hash? Und das alles in einer Datei? Und frei zu vergebende IDs? Beliebige Datenstrukturen? Juhu, ich mache Dir das mal schmackhaft:
      
      Code (perl): (dl )
      
      1 2 3 4 5 6
      
      my $m = myObjects->new( autostore => 1, file => '/tmp/messwerte.bin', lock => 1 ); $m->insert('2011-10-03', {ort => 'Oppenheim', temp => [12, 13, 25, 19]}) or die $m->errstr; $m->insert('2011-10-04', {ort => 'Oppenheim', temp => [8, 12, 22, 18]}); my $werte = $m->getobject('2011-10-04'); print $werte->{ort}, "\n"; # Oppenheim print join("\n", @{$werte->{temp}});
      
      Alle Daten in einer kompakten Datei, bei 20 tausend Einträgen hat die ungefähr 1 MB. Werte im Array: sieht doch gut aus, oder? Werte als HashRef sind auch nicht schlecht, per Name ansprechbar.... Dazu gibts die Klasse myObjects.pm, mit IO::File und Storable mal eben zusammengetackert ;)
      
      Viele Grüße,
      Rolf
      
      PS: Wenn mehrere Prozesse im Spiel sind, kann auch gelockt werden.
      - +3 replies
      - Sven_123
        
        2011-10-05 10:13
        
        User since
        2010-06-01
        120 Artikel
        BenutzerIn
        
        Aber ich muss gar nicht so viel speichern, dass mir der Arbeitsspeicher knapp würde und ich ne Datenbank bräuchte...? (Dafür sieht es schon interessant aus, ich hatte mal ein kleines Hilfsscript für ein Spiel geschrieben und mich da das erste mal mit so Datenbankkram rumgeschlagen, was weniger elegant war, glaub ich.*g)
        
        Mal eine vereinfachte Struktur von meinem Programm:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10
        
        my (variables); read_param(); create_input(); run_a_program(); read_its_log(); calculate_stuff(); write_output();
        
        Ich will lediglich in calculate_stuff() und write_output() möglichst kurze und leicht zu durchschauende Variablen haben. Also z.B. eine Matrix @grad mir Atomen als "Zeilen" und Koordinaten als "Spalten".
        Bisher hab ich in read_param() immer festgelegt, welchen Gradienten ich auslesen möchte und in read_its_log() nur die zugehörige Ausleseroutine durchgeführt, die dann automatisch @grad beschrieben hat.
        
        Wenn ich jetzt aber mehrere Gradienten zum Vergleich speichern will, brauch ich mehrere Variablen. Um calculate_stuff() trotzdem simpel zu halten, will ich lediglich im Vorfeld festlegen, welche der verschiedenen Variablen in dem bestimmten Durchlauf die "richtige" ist.
        
        Hab nach wie vor nicht verstanden, was eine Klasse da ändern könnte, außer z.B. das Problem die ausgelesenen Daten in einem vorher festgelegten anonymen Array zu speichern, ohne ausversehen die Referenz zu ändern, von der Ausleseroutine in die Methode zum Speichern zu verlegen.
        Last edited: 2011-10-05 10:16:54 +0200 (CEST)
        
        +2 replies
        
        rosti
        
        2011-10-05 19:33
        
        User since
        2011-03-19
        3502 Artikel
        BenutzerIn
        
        Hi,
        
        mein Gedanke, der dahinter steckt, was die Datenhaltung betrifft:
        
        Die kann in einer DB erfolgen oder in Dateien. Die Klasse zur Datenanbindung ist ein Abstraction-Layer (AL). Der Anwendung (App) ist es "egal", wo die Daten herkommen und wo die gespeichert werden. In der App wird nicht mit Dateihandler oder SQL-Statements 'rumgemacht, sondern da werden nur Methoden aufgerufen, welche die Datenstrukturen aus dem AL holen und dorthin zurückschreiben.
        
        Sofern in der App immer die gleichen Datenstukturen vorliegen, gäbe es darüber hinaus auch die Möglichkeit mit Tie zu arbeiten, z.B. um einen Hash oder ein Array an eine Datei oder eine DB zu binden.
        
        In der App hast Du dann den Kopf frei für das Wesentliche, z.B. Deine Berechnungen.
        
        Interessante Frage: Wann Datei, wann DB? Betrachte die Performance, es braucht eine gewisse Zeit, den Connect zur DB herzustellen. Im Beispiel wäre es schneller, 20T Einträge aus einer Datei zu lesen, als die Verbindung zur DB herzustellen. I.d.R. wird bei einer Dateianbindung jedoch immer die gesamte Datenmenge in den RAM gelesen. Bei einer DB-Anbindung hingegen, hast Du nur die Ergebnismenge im RAM (was die DB-Engine an RAM verbraucht ist meistens weniger interessant).
        
        Liegen jedoch 200T Messerte vor und es wird nur das Messergebnis von einem Tag gebraucht, ist die DB-Anbindung besser, vorausgesetzt, die Abfrage ist optimiert und der Index sitzt an der richtigen Stelle (hier das Datum).
        
        Das ist also von Fall zu Fall abzuwägen und DB-Abfragen zu optimieren ist auch keine Hexerei ;)
        
        Nochwas zum Thema, Hashes und Arrays. Beispielsweise liefert der AL ein Objekt, in welchem sowohl Hashes als auch Arrays drin sind. Zum Verbessern der Lesbarkeit in der App, werden einfach die Referenzen kopiert über Methodenaufrufe:
        
        Code (perl): (dl )
        
        1 2 3
        
        my $ob = Foo->new('2011-10-05'); # alles drin für einen Tag my $array_ref = $o->show_temperaturen; my $hash_ref = $o->show_messpunkte;
        
        ... so in Etwa...
        
        --Rolf
        
        Sven_123
        
        2011-10-07 10:22
        
        User since
        2010-06-01
        120 Artikel
        BenutzerIn
        
        Hmm...also erst nochmal ein Danke für deine ausführlichen Erklärungen, wenn ich mal wieder was Datenbankmäßiges brauch, guck ich mir Storable an, und hab hier auch ein paar Schreibansätze.
        Aber ich glaub trotzdem, dass das hier zumindest eine andere Baustelle wäre (sprich, es wär vielleicht übersichtlich Klassen für meine Variablen einzubauen, aber im Endeffekt verlagert es die komplizierten Stellen, z.B. das Befüllen des Hashs auch nur von einer Auslese-Subroutine in die Befüll-Methode).
        
        Egal, ich werd es vermutlich so wie in meinem ursprünglichen, zweiten Beispiel machen - nach dem vielen Schreiben denke ich, dass es da tatsächlich keine Alternative (mehrere Namen für den selben, noch nicht existierenden Array) gibt.
        
        Edit: Andererseits - Klassen würden mir ja erlauben Operatoren zu überladen. Das wär schon sehr nett für so manches...mal sehn, wie weit ich komm. ;D
        
        Edit2: Haha, total cool ^^
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
        
        #!/usr/bin/perl use strict; use warnings; {package Matrix; use overload '+' => \&plus, '""' => \&pm; sub new{ my $class = shift; bless {}, $class; } sub fl{ my $self = shift; my $line = shift; $self->{'mat'}[$line] = [@_]; } sub mat{ return $_[0]->{'mat'}; } sub pm{ for (@{$_[0]->{'mat'}}){ print "@{$_}\n"; } } sub plus{ my $m1 = $_[0]->mat; my $m2 = $_[1]->mat; my @res; for my $i (0..$#{$m1}){ for my $j (0..$#{$m1->[$i]}){ $res[$i][$j] = $m1->[$i][$j]+$m2->[$i][$j]; } } bless {mat => [@res]}, 'Matrix'; } } my $x; $x = Matrix->new(); $x->fl(0,1,2,3); $x->fl(1,6,5,4); $x->fl(2,2,2,2); my $y; $y = Matrix->new(); $y->fl(0,6,7,8); $y->fl(1,4,4,4); $y->fl(2,1,1,1); my $z = $x + $y; print $x,"+\n",$y,"=\n",$z;
        
        Last edited: 2011-10-07 16:41:28 +0200 (CEST)
- +2 replies
- pq
  
  2011-10-01 11:37
  User since
  2003-08-04
  12208 Artikel
  Admin1
  das sieht alles wahnsinnig umständlich und leider auch unleserlich aus.
  
  du soltest deinem code hier und da ein paar leerzeichen gönnen. die kosten nix.
  
  bei deiner referenz-variante benutzt du auch eine referenz zuviel.
  $vars{'gradient'}{$mode} ist schon eine referenz.
  
  und warum erstellst du eine variable $curr_grad, wenn du sie dann nur fürs print benutzt und nicht fürs befüllen?
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
  
  #!/usr/bin/perl use strict; use warnings; use Data::Dumper; # Referenz { my %vars; my $mode = 1; my $curr_grad = $vars{gradient}->{$mode}; # ...tu was... # $vars{gradient}->{1} = [ [1, 1, 1], [1, 2, 3] ]; @$curr_grad = ( [1, 1, 1], [1, 2, 3] ); print $curr_grad->[1]->[1]++, "\n"; print $vars{gradient}->{$mode}->[1]->[1], "\n"; }
  
  habe es mal so formatiert, wie es in meinen augen *viel* leserlicher ist.
  die pfeile zwischen den dereferenzierungen gehören für mich dazu.
  
  zum befüllen habe ich $curr_grad (eine referenz auf ein anonymes array) direkt verwendet und die andere zeile auskommentiert.
  
  edit: falls $vars{gradient}->{$mode} noch nicht existiert, musst du stattdessen schreiben:
  my $curr_grad = $vars{gradient}->{$mode} = [];
  Last edited: 2011-10-01 11:42:27 +0200 (CEST)
  Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
  lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
  - Sven_123
    
    2011-10-04 16:39
    User since
    2010-06-01
    120 Artikel
    BenutzerIn
    
    Mit der zusätzlichen Referenz bin ich halt beim Befüllen des Arrays über den Hash völlig frei, was die Schreibweise angeht. Übernehm ich die Referenz, ginge z.B. ein
    
    Code (perl): (dl )
    
    $vars{gradient}->{1} = [ [1, 1, 1], [1, 2, 3] ];
    
    schon nicht mehr.
    
    Befüllen will ich die einzelnen Hasheinträge in den passenden, fixen Routinen und ohne daran rumzubasteln mal den einen, mal den anderen Modus als tatsächlichen Gradienten benutzen.
    Zu den Pfeilen hab ich grad in meiner Antwort auf Rostis Vorschlag schon recht viel geschrieben. Letztendlich will ich @grad für Rechnungen benutzen, ohne, dass sich jemand, der nur diesen Teil liest damit beschäftigen muss, was dahinter steht.
    
    Danke euch beiden - ich werd den Thread mal als "gelöst" markieren, da ich nicht ganz sicher bin, ob das was ich will überhaupt geht und das ganze eh mehr eine Bitte nach ein paar Vorschlägen ist, als was, wo es eine definitive "Lösung" zu gibt... :)

View all threads created 2011-09-30 11:50.