plot 'file.dat' using 6:xtic(1) ti col, '' u 12 ti col, '' u 13 ti col, '' u 14 ti col
Kann sich jemand einen Reim darauf machen, was dieses ti col bedeuten
soll?
Und die Gruppe '' u 12 ti col ?
Mit dieser Gnuplot-Doku komme ich nicht klar und wie man so tolle
Beispiele, wie auf http://gnuplot.sourceforge.net/demo/ machen kann,
ohne auch nur ein Wort der Erläuterung, was das Towuwabohu soll, ist mir
ein Rätsel.
Was dabei rauskommen soll, sieht man im Anhang.
If gnuplot is built with configuration option --enable-datastrings, then
3
the first entry of a column of the input data file can be used as a string
4
to provide the plot title in the key box. The column containing specified
5
is independent of the column[s] used for the plot itself.
6
7
plot 'data' using 1:($2/$3) title column(N)
8
9
In this case the entry in the first row of column N will be used for the
10
key entry of the plot constructed from dividing column 2 by column 3.
11
The entry in the first row of columns 2 and 3 will be ignored.
d.h. es gibt den auszugebenden Text an.
Das u 12... gibt die nächste auszgenden Reihe an.
Das '' kenne ich auch nicht; vielleicht einfach ein Bezug auf die erste
Datei ('file.dat')?
Diese Abkürzeritis ist wirklich ne Pest, vor allem wenn man keine
Hinweise gibt, was wie abgekürzt werden darf.
Das
1
'' u 12 ti col
heißt dann wohl ausgeschrieben:
1
'file.dat' using 12 title columnheader(12)
@Hans:
Danke für den ersten Link - der sieht deutlich freundlicher aus, als
dieser pdf-Krampf.
Einigermaßen brauchbar ist auch die Idiotenpappe
http://www.math.uni-klu.ac.at/Software/cd2/math/gnuplot/gpcard.pdf
@Klaus:
Die Beispiele sind vollständig im demo-Ordner der gnuplot-Distri.
Uhu Uhuhu schrieb:> Hinweise gibt, was wie abgekürzt werden darf.
ich glaub du kanst alles beliebig abkürzen, solange der befehl eindeutig
ist.
dh 'plot' kannst du als 'plo', und als 'pl' aber nicht als 'p' abkürzen,
da es auch 'print' gibt.
was man sich dabei dedacht hat, weiß ich auch nicht, vor allem wenn
irgend wann mal ein neuer Befehl dazu kommt, funktionieren dutzende alte
Scripte nicht mehr.
Wer im Skript die Kurzformen nimmt, gehört an den Pranger.
Interaktiv spart es etwas Tippen, aber in abgespeichertem
Quelltext ist das tabu.
Ich schreibe ja auch keine Programme in der Art:
Vlad Tepesch schrieb:> ich glaub du kanst alles beliebig abkürzen, solange der befehl eindeutig> ist.
Das ist eine klasse Definition - für die, die gnuplot aus dem ff kennen.
Für Leute, die sich erstmals damit befassen, hat sie eher was von Spott
und auf Lehrmaterialien ist es eine Publikumsverhöhnung.
>und auf Lehrmaterialien ist es eine Publikumsverhöhnung.
Und hätten sie es ausgeschrieben, dann hättest Du dich beklagt, dass man
so viel tippen muss. Ja, gnuplot ist nicht ganz einfach, gebe ich ja zu.
Aber was heißt "Lehrmaterialien" -- wenn Du die Lehrmaterialien für
viele hundert Euro bei so einem Seminar-Anbieter gekauft hast, magst Du
dich dort beschweren. Sonst lass das Maulen (Kauderwelsch) usw.
Und nebenbei, Unterforum PC-Programmierung ist ja wohl auch fraglich.
Oder ist das Tippen von ein paar Gnuplot-Anweisungen für dich schon
programmieren?
Gruß
Stefan Salewski
> Und hätten sie es ausgeschrieben, dann hättest Du dich beklagt, dass man> so viel tippen muss.
Und wie kommst du auf den Schmarrn? Ich schreibe si nämlich in meinem
Skript aus.
Pritt, wer hier mault, das bist du.
Ich möchte, daß Texte in utf-8 ausgegeben werden. Dazu habe ich
definiert:
set encoding utf8
Allerdings ändert das an Ausgabe nichts und der Befehl
show encoding
bringt die Ausgabe:
nominal character encoding is utf8
however LC_CTYPE in current locale is C
Hat jemand eine Idee, was man da drehen muß, damits funtioniert?
>Ich möchte, daß Texte in utf-8 ausgegeben werden.
Wahrscheinlich möchtest du eher, dass Texte, die Zeichen in UTF8
Kodierung enthalten, korrekt dargestellt werden.
Soweit ich mich erinnere ist "set encoding utf8" schon richtig. Aber
entweder muss dann dein Script, was gnuplot verarbeiten soll, auch
Zeichen in UTF8 Kodierung enthalten, oder Dein Terminal muss die Eingabe
von UTF8 Zeichen zulassen.
Ich kann es jetzt nicht ausprobieren, und Du hast ja auch nicht
geschrieben was Du genau erreichen willst oder was Dein Problem ist.
Gewöhnlicher ASCII-Text bleibt ja eh unverändert, mit oder ohne UTF8.
Und ich würde mich schon sehr wundern wenn man im Manual oder mit Google
dazu nichts fände.
> Hat jemand eine Idee, was man da drehen muß, damits funtioniert?
Stefan, deine korrekte Antwort auf meine Frage hätte offensichlich
nein heißen müssen und deine Vermutungen haben weder Hand, noch Fuß.
Uhu Uhuhu schrieb:> nominal character encoding is utf8> however LC_CTYPE in current locale is C>> Hat jemand eine Idee, was man da drehen muß, damits funtioniert?
Du möchtest UTF-8, aber Dein Betriebssystem behauptet im beim
Programmaufruf übergebenen Environment, dass es kein UTF-8 versteht
(„C“). Was gnuplot daraus macht, weiß ich nicht, aber es weist Dich auf
diesen offensichtlichen Widerspruch hin.
Du kannst gnuplot so belügen, dass es nichts von diesem Widerspruch
merkt, indem Du es auf einem unixoiden Betriebssystem mit
1
LC_CTYPE=de_DE.utf8 gnuplot
aufrufst. Dann hält es Dein System für UTF-8-fähig.
Wenn aber Dein System wirklich UTF-8 kann, solltest Du das systemweit
auch einstellen. Wo Du Deine systemweiten Locale-Einstellungen machst,
hängt von Deinem (uns unbekannten) System ab.
Ich habe ein US-englisches Ubuntu 10.04. Entsprechend habe ich deinen
Tipp geändert in
LC_CTYPE=en_US.utf8 gnuplot ...
Aber leider hilft auch das nichts, wie man in der angehängten Graphik
sieht. (Dieses verkrüppelte Wort über der Stockente rechts oben soll
Bläßhuhn heißen.)
Wenn ich im SCITE-Editor utf-8 einstelle, dann zeigt der Umlaute und ß
klaglos an, auch mit dem englischen System.
Ein weiteres Problem habe ich mit den xtics. Die Einstellung aus dem
zweiten Histogrammbeispiel von gnuplot richtens nicht. Mal sehen, was da
nicht paßt.
Hans Mayer schrieb:> Wenn Du an einer Uni bist frag doch mal nach ob ihr Origin-Lizenzen> habt, das ist mächtiger und leichter zu bedienen.
Jetzt muss ich mal Gnuplot in Schutz nehmen. Origin ist doch der größte
M... auf dem Markt. Es ist teuer, es heuchelt komplexe Zahlen vor, und
es gefällt mir nicht. Ok, der letzte Punkt war nicht objektiv, aber das
mit den komplexen Zahlen ist entscheidend. Ich kannte zuerst Origin und
bin dann auf gnuplot umgestiegen. Damit bin ich sehr glücklich, gerade
wenn es um große Dateien geht und automatisierte Erzeugung von hunderten
Bildern (z.B. für eine Animation) ist es sehr mächtig.
Kann man eigentlich einzelne Zahlen aus einer Datei auslesen (für Label,
Positionen und andere Variablen), vielleicht so ähnlich wie das
6:xtic(1) in
plot 'file.dat' using 6:xtic(1) ti col, ...
?
Gruß
Silvio
Silvio K. schrieb:> Jetzt muss ich mal Gnuplot in Schutz nehmen.
Das ist eigentlich nicht nötig - das Ding ist unglaublich mächtig und
bringt z.B. in Maxima wirklich tolle Leistung. Das Problem ist die
Dokumentation, die als Einstieg schlicht unbrauchbar ist. Leider ist das
in der Open-Source-Szene ein recht verbreitetes Phänomen.
Ich hatte auch mal einen Bug im png-terminal.
Weiß nicht mehr genau was es war, aber ich glaub, es hatte entweder mit
transparenz zu tun, oder mit komischen quer über das Bild verlaufenden
Linien, beim plotten von Messdaten aus einer Datei.
es gibt noch pngcairo oder so, da ging es