Arrays zusammenführen/mergen (gelöst) (Allgemeines zu Perl) - Perl-Community.de

Start · Board · Anwendungen/Programme/Skripte in Perl · Allgemeines zu Perl

2024-04-23 12:41:56
Europe/Berlin
Einloggen (Registrieren)
- Einstellungen
- Statistics
Jemand zu Hause?
0 Benutzer online
1 Gast

[thread]20755[/thread]

submit to reddit

Arrays zusammenführen/mergen [gelöst]

[gelöst]

Tags: perl5 Array merge zusammenführen Ähnliche Threads

Leser: 17

Articles: hide open all | hide show old branches

+17 replies
styx-cc

2020-03-13 21:20
User since
2006-05-20
533 Artikel
BenutzerIn
Hallo Forum!

Irgendwie stehe ich bei einer eigentlich trivialen Aufgabe seit einigen Stunden auf dem Schlauch, und bevor ich noch 3x spazieren gehe, frag ich einfach mal was ich falsch mache.

Ziel ist es die referenzierte (Hashkey) Arrayreferenz an die andere anzuhängen und die nun nicht mehr benötigte zu löschen.
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

#!/usr/bin/perl use strict; use warnings; use Data::Dumper; my $ranges = { 1282 => [ 25, 40, 5, undef ], 1283 => [ 300, 400, 25, 1282 ], 1284 => [ 20, 30, 5, undef ], 1285 => [ 250, 260, 10, 1284 ], 1286 => [ 25, 30, 5, undef ], 1287 => [ "0.003", "0.005", "0.001", 1286 ], }; for my $range (keys %$ranges) { my $related_r = @{ $ranges->{$range} }[3]; if ( defined $related_r ) { my @merge_range; @merge_range = ( @{$ranges->{$range}}[0..2], @{$ranges->{$related_r}}[0..2] ); delete $ranges->{$related_r}; $ranges->{$range} = \@merge_range; } } print "EDITED RANGES:\n"; print Dumper $ranges;
Ausgabe:
Code: (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

EDITED RANGES: $VAR1 = { '1283' => [ 300, 400, 25, 25, 40, 5 ], '1287' => [ '0.003', '0.005', '0.001', 25, 30, 5 ], '1282' => [], '1285' => [ 250, 260, 10, 20, 30, 5 ], '1284' => [] };
Das Zusammenführen klappt ja soweit, aber warum löscht er '1284' => [] und '1282' => [] nicht, jedoch die 1286?

Ich bin für Erlösung sehr dankbar!

Lieben Gruß
Last edited: 2020-03-13 21:56:05 +0100 (CET)
Pörl.
- Linuxer
  
  2020-03-13 22:21
  User since
  2006-01-27
  3870 Artikel
  HausmeisterIn
  Er scheint schon mal variabel beim Löschen zu sein; zweimal ausgeführt, bekomme ich zwei verschiedene Ergebnisse:
  
  Vergleiche
  
  Code: (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
  
  perl code_191508_1.pl EDITED RANGES: $VAR1 = { '1282' => [], '1283' => [ 300, 400, 25, 25, 40, 5 ], '1285' => [ 250, 260, 10, 20, 30, 5 ], '1286' => [], '1287' => [ '0.003', '0.005', '0.001', 25, 30, 5 ] };
  
  mit
  
  Code: (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
  
  $ perl code_191508_1.pl EDITED RANGES: $VAR1 = { '1282' => [], '1283' => [ 300, 400, 25, 25, 40, 5 ], '1285' => [ 250, 260, 10, 20, 30, 5 ], '1287' => [ '0.003', '0.005', '0.001', 25, 30, 5 ] };
  
  meine Beiträge: I.d.R. alle Angaben ohne Gewähr und auf Linux abgestimmt!
  Die Sprache heisst Perl, nicht PERL. - Bitte Crossposts als solche kenntlich machen!
- Linuxer
  
  2020-03-13 22:24
  
  User since
  2006-01-27
  3870 Artikel
  HausmeisterIn
  
  Ich denke, es hängt damit zusammen, dass Hashes nicht sortiert sind.
  Daher ist die Reihenfolge, in der die enthaltenen Referenzen verarbeitet werden, zufällig => unterschiedliche Ergebnisse.
  
  Probier es mal mit sortierten Keys in der for-Schleife.
  meine Beiträge: I.d.R. alle Angaben ohne Gewähr und auf Linux abgestimmt!
  Die Sprache heisst Perl, nicht PERL. - Bitte Crossposts als solche kenntlich machen!
- haj
  
  2020-03-13 22:27
  User since
  2015-01-07
  527 Artikel
  BenutzerIn
  Bei genauem Hinsehen wird Dir auffallen, dass es nicht jedesmal die gleichen Dinge sind, die gelöscht werden. Und eigentlich sollte der Schlüssel
  1284 nach Abarbeitung der 1285 gelöscht sein und nicht ein leeres Array.
  
  Die Ursache: Die Reihenfolge, in der von keys %ranges abgearbeitet wird, ist zufällig. Wenn also zum Beispiel 1283 vor 1282 abgearbeitet wird, dann löscht diese Bearbeitung den Key 1282. Danach kommt irgendwann der Key 1282 dran, dessen Daten schon weg sind. Du greifst dann direkt mit my $related_r = @{ $ranges->{$range} }[3]; in den Hash rein - und dadurch entsteht die leere Liste. Das Phänomen heißt bei Perl "autovivication".
  
  Die Abhilfe: Wenn die Einträge mit "related" immer höhere Schlüsselwerte haben als die, auf die sie sich beziehen, dann sortiere die Liste:
  
  Code (perl): (dl )
  
  1 2 3
  
  #... for my $range (sort { $a <=> $b } keys %$ranges) { ...
  
  Robuster, weil unabhängig von der Reihenfolge: Prüfe, ob der Schlüssel, den Du suchst, noch existiert:
  
  Code (perl): (dl )
  
  1 2 3 4
  
  for my $range (keys %$ranges) { next unless exists $ranges->{$range} my $related_r = @{ $ranges->{$range} }[3]; # ...
- +6 replies
- styx-cc
  
  2020-03-13 22:44
  
  User since
  2006-05-20
  533 Artikel
  BenutzerIn
  
  Ich hab schon geahnt dass es mit der Sortierung der Hashkeys zu tun haben muss,
  was wie schon angemerkt wurde aber nur bedingt richtig ist.
  Aber auf die Lösung wäre ich so schnell nicht gekommen.
  
  Ich werde künftig mit exists prüfen.
  
  Super gut, danke euch beiden!
  Pörl.
  - +5 replies
  - Raubtier
    
    2020-03-14 10:31
    
    User since
    2012-05-04
    1054 Artikel
    BenutzerIn
    
    2020-03-13T21:44:35 styx-cc
    Ich werde künftig mit exists prüfen.
    
    Aber ob das immer richtig ist? Können die zu mergenden Arrays auch mehrfach reingemerget werden?
    
    Generell würde ich immer dringend davon abraten (!) ein einer Loop über ein Objekt dieses auch (strukturell) zu verändern. Das führt nur zu Problemen und Unklarheiten. Also in einer Loop über ein Array nie Elemente in diesem Array löschen oder in dieses Array hinzufügen (Werte ändern ist ok) und bei einer Loop über einen Hash ebenfalls in der Loop keine Keys (in diesem Hash) löschen oder hinzufügen.
    
    Stattdessen merk dir einfach die zu löschenden Keys und lösche diese, nachdem die Loop beendet ist. Oder bau dir stattdessen eine Funktion, die einen neuen Hash zurückgibt, in dem die zu entfernenden Dinge nicht enthalten sind.
    
    Es mag Ausnahmen geben, die sollten aber gut begründet und kommentiert sein - und vor allem sollte dann extrem stark getestet/sichergestellt sein, dass alles funktioniert. Generell kann sich Hash-Looporder auch mit Perl-Versionen ändern. Nie darauf bauen!
    
    (In (neueren) Pythons ist die dict-Looporder garantiert, d.h. man hat sortierte dictionaries. Von Perl kommend, habe ich mich schon das ein oder andere mal gewundert, warum Python-Code korrekt funktioniert, der darauf aufbaut. Für mich immer noch ein merkwürdiges Konzept, dass die Key-Reihenfolge dort erhalten bleibt)
    Last edited: 2020-03-14 10:39:07 +0100 (CET)
    - rosti
      
      2020-03-14 10:58
      
      User since
      2011-03-19
      3194 Artikel
      BenutzerIn
      
      Full Ack! Also wenn man diese unglücklichen Datenstruktur nicht anders bekommt, würde ich die auch neu aufsetzen. Und zwar so daß die Einzelwerte namentlich adressierbar sind.
      
      MFG
    - +3 replies
    - haj
      
      2020-03-14 13:14
      
      User since
      2015-01-07
      527 Artikel
      BenutzerIn
      
      2020-03-14T09:31:57 Raubtier
      Generell würde ich immer dringend davon abraten (!) ein einer Loop über ein Objekt dieses auch (strukturell) zu verändern.
      
      Das ist zwar richtig, aaaber: Nicht schuldig, Euer Ehren! Das macht nämlich der Code von styx-cc gar nicht.
      
      Mit keys %$ranges wird ein Array erzeugt, das den Zustand des Hash zu Beginn der Schleife darstellt, und über dieses Array läuft die Schleife. Wenn dann in der Schleife Keys aus dem Hash verschwinden können, dann ist exists absolut robust. Der Hash und das Array, über das die Schleife läuft, sind voneinander unabhängig.
      
      Man könnte sich auf zwei Wegen in dieses Knie schießen:
      
      Indem man mit while (my ($key,$value) = each %ranges) über den Hash iteriert oder
      Indem man die Datenstruktur als Array anlegt und dann über dieses Array schleift.
      
      In diesen beiden Fällen iteriert man tatsächlich über die Struktur, die geändert werden soll und... richtig, das sollte man nicht tun.
      - +2 replies
      - Raubtier
        
        2020-03-14 15:06
        
        User since
        2012-05-04
        1054 Artikel
        BenutzerIn
        
        Das ist ein bisschen Nitpicking, finde ich. Natürlich loope ich über diesen Hash. Zwar mit Hilfmittel des Schlüsselarrays, aber das macht das Prinzip nicht wesentlich besser. Ja, der Code läuft dann durch. Aber ich weiß nicht einmal, in welcher Reihenfolge ich hier durchlaufe, d.h. vielleicht loope ich erst über einen Eintrag, bevor er gelöscht wird - vielleicht wird er aber erst gelöscht und dann finde ich ihn mit exists nicht.
        
        Ich bleibe dabei, dass das hier sehr fehleranfällig ist, auch wenn man sich einmal am Anfang alle zu dem Zeitpunkt existierenden Keys holt.
        
        Außerdem stimmt das nur, solange keys auch wirklich ein echtes Array zurückgibt und nicht vielleicht einen versteckten Iterator. Das heißt, man muss zusätzlich wieder nachdenken, was genau keys in Perl genau macht (gut, ist vielleicht nicht das beste Argument, wo ich sonst immer sage, dass man ruhig alle Features einer Sprache nutzen soll).
        
        haj
        
        2020-03-14 18:21
        
        User since
        2015-01-07
        527 Artikel
        BenutzerIn
        
        2020-03-14T14:06:18 Raubtier
        (gut, ist vielleicht nicht das beste Argument, wo ich sonst immer sage, dass man ruhig alle Features einer Sprache nutzen soll).
        Eben. Man darf durchaus drauf vertrauen, was in perlfunc keys steht:
        
        Quote
        Called in list context, returns a list consisting of all the keys of the named hash...
        und weiter unten:
        Quote
        The returned values are copies of the original keys in the hash...
        Die Liste ist also robust gegenüber allem, was mit dem Hash hintherher passiert.
        
        Bei perlfunc each (each ist ein Iterator) wird genau beschrieben, unter welchen begrenzten Bedingungen man während des Schleifendurchlaufs Elemente löschen kann. Im Beispiel von styx-cc sind diese Bedingungen nicht erfüllt. Er befolgt aber den Hinweis:
        Quote
        To avoid these problems, use a "foreach" loop rather than "while"-"each".
        
        Der Code von styx-cc hält sich an dokumentierte Schnittstellen und folgt beim Hash der Empfehlung. Mit der Prüfung mit exists ist er auch unabhängig von der Reihenfolge der Keys. Es ist ja weitgehend Geschmackssache, was man für fehleranfällig hält, aber "dringend abraten" wegen etwas, was der Code gar nicht tut, ging mir zu weit.
- +5 replies
- rosti
  
  2020-03-14 09:20
  
  User since
  2011-03-19
  3194 Artikel
  BenutzerIn
  
  Quote
  frag ich einfach mal was ich falsch mache.
  
  Deine Datenstruktur ist unzweckmäßig. Damit ergibt sich ein sog. Einweg-Code der schlecht skalierbar und wartungsunfreundlich ist.
  
  Die Daten kann man bestimmt auch so erfassen daß sie besser verarbeitet werden können.
  
  MF
  - +4 replies
  - hlubenow
    
    2020-03-14 16:16
    
    User since
    2009-02-22
    875 Artikel
    BenutzerIn
    
    2020-03-14T08:20:25 rosti
    Deine Datenstruktur ist unzweckmäßig.
    
    Ich denke, wir kennen die Daten, um die es geht, nicht genau genug, um so eine Aussage zu treffen.
    Last edited: 2020-03-14 16:18:13 +0100 (CET)
    - +3 replies
    - rosti
      
      2020-03-14 16:23
      
      User since
      2011-03-19
      3194 Artikel
      BenutzerIn
      
      2020-03-14T15:16:45 hlubenow
      2020-03-14T08:20:25 rosti
      Deine Datenstruktur ist unzweckmäßig.
      
      Ich denke, wir kennen die Daten, um die es geht, nicht genau genug, um so eine Aussage zu treffen.
      
      Doch kennen wir. Unzweckmäßig deswegen weil die Werte in den Array's nicht namentlich addressierbar sind sondern nur über den Index. Das macht den Code zu einem Einwegcode.
      
      MFG
      - +2 replies
      - hlubenow
        
        2020-03-14 16:24
        
        User since
        2009-02-22
        875 Artikel
        BenutzerIn
        
        Aber er hat da (in den Arrays und in dem umliegenden Hash) soweit ersichtlich doch nur Zahlen (und undef). Vielleicht kann man für die Zahlen ja keine Namen finden.
        Last edited: 2020-03-14 16:25:31 +0100 (CET)
        
        rosti
        
        2020-03-14 16:35
        
        User since
        2011-03-19
        3194 Artikel
        BenutzerIn
        
        Die Zahlen haben mit Sicherheit irgendeine Bedeutung. Auf [3] z.B. related_r.
        
        Mit benamsten Werten wird übrigens auch die Fehlersuche einfacher. Und der ganze Algorithmus auch verständlicher. Das macht einen Code reproduzierbar.
        
        MFG
        
        PS: Also ich würde gucken daß ich das Problem schon bei der Datenerfassung löse. Denn so wie es aussieht, steckt im referenzierten Array die ID des Vorgängers (verkettete Liste):
        
        Code (perl): (dl )
        
        1 2 3 4 5 6
        
        1283 => [ 300, 400, 25, 1282 ],
        
        Und wenn diese fehlt ist da bei der Datenerfassung offensichtlich was schiefgegangen. Nurmalso als Idee.
        
        .
        Last edited: 2020-03-15 07:35:31 +0100 (CET)
- hlubenow
  
  2020-03-14 16:13
  User since
  2009-02-22
  875 Artikel
  BenutzerIn
  Wie Raubtier schon sagte, ist es keine gute Idee, in einer Schleife Elemente aus einer Struktur zu löschen, über die man gerade die Schleife laufen läßt.
  
  In diesem Fall solltest Du mit einer Kopie der Struktur (Liste, Hash, usw.) arbeiten:
  
  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
  
  #!/usr/bin/perl use warnings; use strict; use Data::Dumper; use Clone qw(clone); my $ranges = { 1282 => [25, 40, 5, undef], 1283 => [300, 400, 25, 1282], 1284 => [20, 30, 5, undef], 1285 => [250, 260, 10, 1284], 1286 => [25, 30, 5, undef], 1287 => ["0.003", "0.005", "0.001", 1286]}; my $ranges_clone = clone($ranges); for my $range (keys %$ranges) { my $related_r = @{ $ranges->{$range} }[3]; if ( defined $related_r ) { my @merge_range; @merge_range = ( @{$ranges->{$range}}[0..2], @{$ranges->{$related_r}}[0..2] ); delete $ranges_clone->{$related_r}; $ranges_clone->{$range} = \@merge_range; } } print "EDITED RANGES:\n"; print Dumper $ranges_clone;
  
  Last edited: 2020-03-16 12:08:27 +0100 (CET)
- haj
  
  2020-03-14 18:43
  User since
  2015-01-07
  527 Artikel
  BenutzerIn
  Nur zum Vergnügen: Auch das ist eine Aufgabe, die man in Perl mit den Funktionen perlfunc map und perlfunc grep erschlagen kann.
  
  Mit grep fischt man sich die Schlüssel raus, die erhalten bleiben, und danach baut man deren Inhalt mit map zusammen.
  
  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
  
  #!/usr/bin/perl use strict; use warnings; use Data::Dumper; my $ranges = { 1282 => [ 25, 40, 5, undef ], 1283 => [ 300, 400, 25, 1282 ], 1284 => [ 20, 30, 5, undef ], 1285 => [ 250, 260, 10, 1284 ], 1286 => [ 25, 30, 5, undef ], 1287 => [ 0.003, 0.005, 0.001, 1286 ], }; my %merged = map { $_ => [@{$ranges->{$_}}[0..2], @{$ranges->{$ranges->{$_}[3]}}[0..2]] } grep { defined $ranges->{$_}->[3] } keys %$ranges; print "EDITED RANGES:\n"; print Dumper \%merged;

View all threads created 2020-03-13 21:20.