Numerische Werte für Daten aus Textdateien #127
Labels
No Label
Kind/Breaking
Kind/Bug
Kind/Crash
Kind/Documentation
Kind/Enhancement
Kind/Feature
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Priority
Very low
Reviewed
Duplicate
Reviewed
Invalid
Reviewed/Won't Fix
Status
Need More Info
Status
On Hold
Status
Stale
Type/BDS
Type/DSC
Type/Fit
Type/General
Type/NMR
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: IPKM/nmreval#127
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Statt immer die letzte Zahl aus dem Dateinamen als numerischen Wert zu übernehmen, sollte man mehr Freiheiten haben. Mögliche Optionen könnten sein:
beim einlesen mit Regex funktioniert die Auswahl des Matches nicht. Ich möchte Dateien einlesen mit Namen im Format
"blabla_100p0K_01", wobei die letzte Zahl eine Laufnummer ist nach der ich sortieren will.
Der Regex "\d{3}p\dK_(\d{2})" funktioniert aber nicht, den Match index (default Wert 1) kann ich nicht ändern. Auch nicht wenn ich den Regex abändere zu "(\d{3})p\dK_(\d{2})". Lustigerweise darf ich die "1" überschreiben mit "1".
Wenn ich den Regex so wähle, dass nur eine Zahl vorkommt "K_(\d{2})" werden die numerischen Werte wie gewünscht zugewiesen.
Nebenfrage: kann man nach Temperaturen mit Nachkommastelle sortieren wenn das Komma nicht in einen float passt? z.B. wenn ich sortieren will ["100p0K", "100p5K", "101p0K"].
Doch, der regex funktioniert und macht, was er soll. Sinn der Übung ist aber, im Match EINEN numerischen Wert zu finden, nicht zwei, wie du das gerne hättest. Das Problem ist also eher übertriebene Nutzererwartung...
Zur Nebenfrage: sort by name ist immer alphanumerisch, da ist nichts zu mschen, wenn das die Frage war.
Die erste Antwort beantwortet vmtl meine zweite Frage.
Beim Hauptproblem wollte ich nur einen Wert (die Laufnummer) finden. Damit ich nicht ausversehen irgendwas im 'blabla'-Teil matche wollte ich mehr Zeichen in den regex setzen und dann die eingeklammerte Gruppe "(\d{2})" als numerischen Wert verwenden. Um dem Regex zu helfen hatte ich zwischendurch versucht auch die Temperatur einzuklammern, wollte aber nach wie vor nur die Laufnummer benutzen.
Nö, Gruppen bringen dor für die Auswahl gar nichts,. Es wird immer der ganze Ausdruck gematcht und dann darin eine Nummer gesucht. Die Index-Box ist dann relevant, wenn es mehrere Matches gibt und man den Match bestimmen will.
lässt sich das vielleicht umkehren? Falls ich z.B. die Temperatur 100.1K im Dateinamen als 1001 schreibe und das Datum 2023-11-20_1717 (sogar zweimal) ein ähnliches Format hat würde ich gerne um den eigentlichen Wert noch mehr regex drum herum bauen. Das über den Match Index zu machen funktioniert nur wenn sich die Reihenfolge von Temperatur und Datum nie ändert.
Ich sehe da keine zwingende Notwendigkeit, dass zu ändern. Vielleicht ist das unklar, das Index/Position-Dingens bezieht sich auf die Anzahl der gefundenen Matches nicht innerhalb eines Matches
Angenommen, die Datei heißt xyz_1234_2023-12-12_1001 und du willst die 1001 als Wert, dann gibt \d{4} 3 Matches und Position/Index/wieauchimmerdasheisst 3 nimmt dann die 1001.
Und eine gewisse Gleichmäßigkeit im Dateinamen für wiederholbare Ergebnisse braucht es doch unabhängig davon, wie der regex arbeitet...
Ich selbst bin auch hinreichend konsistent in der Benennung, dass das funktionieren würde. Wenn ich aber Dateien von jemand anderem, z.B. einem zu betreuenden Studi, einlesen will, ist das Benennungsschema/Konsistenz evtl anders. Wenn man dann eine Regelmäßgkeit findet die es abzugrenzen gilt fände ich das praktisch wenn man angeben könnte welchen Teil vom Regex man für den numerischen Wert berücksichtigen will.
Da ich bisher, glaube ich, der einzige bin der die Regex Funktion nutzt, kann ich mir aber auch ein Skript schreiben, dass die Dateinamen ggf ändert bevor ich es ins Auswerteprogramm einlese.
Dann als Idee für den Match Index: wenn angezeigt wird welches Match das mit dem Index X ist, wird klarer was das Feld für eine Funktion hat und die Verwechslungsgefahr sinkt.
Es tut mir leid, ich verstehe das Problem irgendwie nicht. Wenn jemand anderes eine konsistente Dateibenennung hat, dann wirst du es doch wohl hinbekommen, einen entsprechenden regulären Ausdruck zu schreiben, der dir die entsprechende Zahl findet. Eventuell ist aber auch gerade ein Problem, dass wir nicht das gleiche Verständnis davon haben, wie Zahlen gesucht und ausgewählt werden.
BTW, wenn die Dateibenennung deiner Studis nicht konsistent ist, dann hilft dir auch ein Skript nicht viel und du solltest dich eher um eine bessere Erziehung kümmern...
Auch die Bezeichung Match index führt offensichtlich zu Verwirrung. Insgesamt muss ich besser kommunizieren, was passiert und welchen Einfluss die Einstellungen haben.
Der gedachte Fall wäre wenn man Dateien enlesen will die aus gemischten, aber in sich konsistenten, Benennungsschemata stammen. Da könnte ich dann aber mit einem eigenen Skript Schema 1 in Schema 2 überführen und dann alles mit dem selben Regex und Match Index im Auswerteprogramm einlesen.
Der Use Case, Werte aus Dateien mit verschiedenen Benennungsschemata auf einmal auszulesen, ist
a. entweder schon abgedeckt oder
b. lässt sich wahrscheinlich absolut nie erfüllen.
Zu a.: Angenommen, du willst die Temperatur aus den Dateien xyz_100p32K_123p456789MHz_2023-01-12_158kg.dat und xyz_123.456789MHz_2023-01-16_158kg_100.3K_meinBetreuerzwingtmichsovielindenDateinamenzuschreiben.dat, dann geht das z.B. über den Ausdruck "\d+[p.]\d+K". Das findet die Temperatur, der Wert wird ausgelesen und alle sind glücklich.
Zu b.: Wenn in den Dateinamen keine Marker, die helfen, sind, z.B. xyz_100p32_123p456789_2023-01-12_158.dat und xyz_123.456789_2023-01-16_158_100.3.dat und man nur über die Position arbeiten kann, dann kann das nur in zwei Schritten geschehen, weil irgendwann irgendwie die Information übergeben werden muss, dass sich die Position geändert hat.
in Fall b könnte ich schreiben "(\d{2,3}[p.]{1}\d{1,2})[ . _ ]" die Suchgruppe findet genau beide Temperaturen, d.h. '100p32' bzw. '100.3'. Der letzte Part '[ . _ ]' wird gebraucht um nicht die Frequenz mitzumatchen. Ohne Gruppe lauten die Matches "100p32_" bzw. "100.3.". Von da in ist es dann eine Frage wie das auswerteprogramm eine Nummer daraus bastelt, das kann ich nicht erkennen.
Da sind meine Beispiele schlecht gewählt (ich habe mir nicht die Mühe gemacht, ein Pattern zu suchen). Dann wäre das auch ein Beispiel für Fall a, weil das über Quantifier wieder eindeutig wird (Warum eigentlich der überflüssige Quantifier {1}?).
Intern wird alles noch einmal mit dem Ausdruck abgeglichen, der als Standard angezeigt wird, der deckt die meisten Zahlenformatierungen ab und würde auch hier funktionieren.
Ein besseres Beispiel für b., wo das nicht funktioniert, und woran ich eher dachte, wäre dann der Dateiname xyz_100p32_123p45_2023-01-12_158.dat, wo halt auch Quantifier nur wenig helfen. Aber bestimmt könnte man auch da etwas finden, das nur einen der beiden Fällen findet, aber das ist nicht der Punkt, den ich eigentlich machen wollte...
Hi! Beim Einlesen von alten .dat Dateien mit Namen wie "300-h" (300K, Heizkurve) wurde das Regex-Feld beim Ausdruck "\d*" rot hinterlegt (siehe Screenshot). Der Ausdruck sollte aber doch gültig sein? Trotz rotem Feld konnte ich die Daten einlesen, die numerischen Werte wurden korrekt zugeordnet. Die Ausdrücke "\d*-" und "\d*-[h,c]" wurden nicht rot hinterlegt.
Kleine Nebenbemerkung: konnte man früher nicht bei Import as->Points auch eine Spalte für DeltaY angeben?
Meine Programmversion ist vom 17.Dez.2023.
Das mit Regex hat schon seine Richtigkeit, weil du nicht so klug bist und nach Null oder mehr Ziffern suchst. Deswegen kommen neben '302' auch '' als gültige Ergebnisse raus. Weil im Programm nur geprüft wird, ob alle Matches Zahlen beinhalten, wird es als rot angezeigt.
Ja, konnte man, muss ich fixen. Fehlerbalken werden aber sowieso überbewertet...