Beiträge von jeuneS2

    Für Sachen die größer sind, bzw. bei denen es auf die Geschwindigkeit ankommt C (in Verbindung mit lex/yacc, wenns passt). Für quick-and-dirty Sachen nehm ich gern Shellscript in Verbindung mit sed, awk und Konsorten. In letzter Zeit bin ich bei Lisp und Scheme gelandet, ist auch ganz lustig.
    Unter ferner liefen: Java, C++, VHDL und Assembler

    Zitat von stormcrow

    hmm, also ich kenn file guards eigentlich nur mit

    Code
    #endif // HEADER_H


    am ende. mag grad ned nachdenkn obs bei der einen oder andren variante probleme gebn koennt, sondern wollts nur anmerkn.


    Diese Variante ist richtig, erstere ist a) syntaktisch nicht korrekt und b) sinnlos, weil beim nächsten Mal includen der Guard ja wieder nicht definiert ist.

    Aufgestachelt von kampis Begeisterung über die vi'sche LaTeX-Suite hab ich einen neuen LaTeX-Mode für den Emacs gebastelt: den LaTeX Sweet Mode

    Installation erfolgt durch ein load-file in der .emacs, also z.B. (load-file "~/lisp/latex-sweet-mode.el").

    Kommentare, Verbesserungsvorschläge etc. sind natürlich sehr willkommen.

    Zitat von \LaTeX

    D.h. die konkrete Frage, die ich mir hier stelle ist, ob "if (*(a+x+1) < cur_a)" teurer ist als "if (my_array[z*xdim*ydim + y*xdim + x] < cur_a)"? Also auf der einen Seite [Zwei Additionen und ein Derefenzieren] und auf der anderen Seite [3 Multiplikationen und zwei Additionen]. Oder anders ausgedrueckt: dauert das Dereferenzieren eines Pointers laenger als wenn man 3 uint Werte multipliziert (wenn man die Ermittlung des Pointers a mal auszer Acht laeszt)?


    Gute Compiler sollten x als Induktionsvariable erkennen und z*xdim*ydim+y*xdim als innerhalb der innersten Schleife konstanten Ausdruck und dementsprechend zweitere Form in erstere Überführen (irgendwo in den Unterlagen zur LVA Optimierende übersetzer findet sich ein schönes Beispiel dafür). Im Zweifelsfall würde ich aber Benchmarks vornehmen, nicht jeder Compiler macht auch immer das, was möglich wäre.

    PS: "dereferenzieren" ist quasi kostenlos, in der internen Darstellung der meisten Compiler ist a[i] das gleiche wie *(a+i) - sofern die Elemente des Arrays die Größe 1 haben, versteht sich.

    Zitat von LaTeXler

    ich hab n kleines Problem in LaTeX und zwar will ich die beiden Pluszeichen und das Sharp-Zeichen nach dem "C" etwas kleiner und näher an den Buchstaben "C" hinbekommen. Das soll aber in/an jeder Umgebung/Stelle "mitwandern", sprich es soll sich immer relativ zum umgebenden Text verhalten. Z.B. in einer \section{...} soll das ganze größer werden, in einer \footnote{...} kleiner usw. Leider hab ich da überhaupt keinen Ansatzpunkt wie ich das lösen könnte. Wäre toll, wenn mir da jemand helfen würde, sitz schon ne ganze Weile dran komm aber auf keinen grünen Zweig.


    Ich denke du suchst so etwas in der Art (aus diversen Dateien aus der Distribution zusammengeklaubt):


    \kern ... näher zum C
    \raise ... sonst pickts so unten drin
    \hbox ... will TeX so haben
    \smaller ... aus dem Package relsize, macht überraschenderweise kleiner ;)
    \spacefactor1000 ... weiß nicht genau was es macht, ist aber bei der Definition von \TeX auch dabei
    \ifmonospace ... schaut sonst zutiefst hässlich aus

    Zitat von arved

    Du solltest noch dazu das komplette Kommando schreiben, bei dem der Fehler passiert.
    Es schaut so aus als ob aus irgendeinem Grund der falsche Assembler verwendet wird.
    Hast du wirklich die avr binutils verwendet?


    Seh ich auch so; der gcc verwendet - zumindest wenn er als Cross-Compiler konfiguriert ist - defaultmäßig den Assembler und Linker der sich in /usr/local/<arch>/bin (in diesem Fall also /usr/local/avr/bin) befindet um die für das Target notwendigen Libraries zu kompilieren. Findet er dort nichts, verwendet der den Assembler und Linker des Host-Systems. Soll ein anderer Assembler/Linker verwendet werden, so kann man das mittels --with-as= bzw. --with-ld= beim ./configure angeben, es kann aber - wenn ich das richtig in Erinnerung habe - Probleme geben, weil ar/ranlib evtl. nicht korrekt gefunden werden.

    Zitat von gelbasack
    Code
    mkfifo tmpfifo

    Das würd ich lieber bleiben lassen, wenns kein Pfusch sein soll ;)

    Und damit ich net nur herumsuder meine Version:

    Code
    #! /bin/bash
    for d in $@; do
        for f in `ls $d/*.wma`; do
    	mplayer -quiet $f -ao pcm -aofile /dev/stdout |
    	sed ':x /^RIFF/ bz; d; :z n; bz' |
    	lame -h - `basename $f .wma`.mp3
        done
    done
    Zitat von LordoftheRings

    Hätte noch eine kleine Frage:

    Weiss jemand wie es mit den Copyright Rechten aussieht unter der Benutzung von Bison?

    Folgender Fall: Ich lasse mir mit hilfe von Bison ja c code compilieren. Muss ich den offenlegen oder kann ich den einfach gewerblich uneingeschränkt nutzen?!


    Was du durch Bison durchschickst ist vollkommen egal; zu den Teilen die Bison selbst in den Parser hineinkopiert findet sich folgendes im Lizenz-Abschnitt einer mit Bison erzeugten Datei:

    Code
    /* As a special exception, when this file is copied by Bison into a
       Bison output file, you may use that output file without restriction.
       This special exception was added by the Free Software Foundation
       in version 1.24 of Bison.  */
    Zitat von a9bejo

    Ich würde für so eine aufgabe keine statisch getypte sprache wie java oder c# empfehlen, sondern eine 'scriptsprache' (was immer dieses wort auch bedeuten mag)

    Grund dafür ist einfach, dass solche sprachen von haus aus über starke möglichkeiten zur textverarbeitung verfügen und die entwicklungszeit wesentlich kürzer wird.


    Sehe ich ziemlich ähnlich, obwohl ein handgeschriebener Parser in C auch seine schönen - wenn auch unlesbaren - Seiten hat.

    Zitat von a9bejo

    ein grober ansatz, um in ruby doppelte zeilen rauszufiltern (ohne leere columns zu berücksichtigenb usw.) sähe z.b so aus:

    Code
    lines = []
    IO.readlines("t.csv").each do |line|
      unless lines.include? line 
        print line 
        lines << line
      end
    end

    oder in python:

    Code
    lines = []
    for line in open('t.csv'):
        if not line in lines:
            print line
            lines.append(line)

    das allein währe in java oder c# schon um einiges aufwendiger und unübersichtlicher zu implementieren.


    Der gepflegte Unix-Mensch würde dafür ja einfach

    Code
    sort | uniq

    schreiben ;)

    Ansonsten erscheint mir "awk" recht gut für solche Aufgaben geeignet zu sein. Obwohl klassisches Unix-Tool, gibt es auch einen Windows-Ports dafür. In wie weit das aber der geforderten simplen Installation widerspricht will ich nicht beurteilen.

    Zitat von MacOS X

    Ok, man kann die Sachen natürlich auch im Labor machen


    Für Signale und Systeme 2 - und ich bin mir ziemlich sicher, dass sich das erste Posting darauf bezieht - gibts aber eben kein Labor.

    Doblinger, Signale und Systeme 2. Er hat erwähnt, dass man auch alternative Software wie z.B. Octave einsetzen kann. Hat jemand Erfahrung damit und kann sagen, in wie weit solche Alternativen als Matlab-Ersatz geeignet sind?

    Alternativ kann man in LaTeX auch Verweise auf ein Fußnote und den Text dazu voneinander trennen, wodurch das Ganze dann so aussehen könnte:

    Code
    Hans\footnotemark, Franz\footnotemark[\value{footnote}], Uwe\\
    bla, bla\\
    \footnotetext[\value{footnote}]{Member des Informatik Forums}


    Wie das in Lyx aussieht weiß ich allerdings auch nicht.

    Zitat von Lord Binary


    Denn Disc-I/O ist hier das entscheidende Bottleneck.
    Die wesentliche Optimierung ist daher, daß Indizes mit nur einem Eintrag nicht weiter verfolgt werden.
    Die gibt's genauso bei dieser Variante. (und nicht mehr)
    Ob die reine CPU Zeit jetzt 3 Sek oder 1.78 Sek ist, ist wohl schnurz.

    Jedefalls dürfte Deine Lösung ziemlich optimal sein :thumb:


    Dein Lob freut mich :)

    Den Punkt der Performance muss ich allerdings ergänzen: die Optimierung des Tabellenzugriffs (mittels struct access_pair) ist nicht unerheblich, weil die Tabellen recht groß sind und sich eine normale lineare Suche deutlich bemerkbar macht (da hält dann sogar NFS vom Durchsatz locker mit). Zur I/O-Performance sein noch angemerkt, dass sich durch eine größere Anzahl gleichzeitig geöffneter Dateien auch noch einiges gewinnen ließe; da leider garantierterweise nur 16 Dateien (incl. stdio, stderr und stdin) gleichzeitig geöffnet sein können, hab ich die Sache aber nicht ausgereizt (Fehlermeldungen gibts auf meinem System erst ab ca. 1000 Dateien, theoretischerweise könnte es aber schon an der 17. scheitern).

    Jo, der Sourcecode is halt so wie es sich in C gehört: jenseits jeder Lesbarkeit ;)

    So funktionierts: es wird von allen Dateien das erste Word eingelesen, mit dem als Index werden die Dateien in eine Tabelle eingetragen (->classify()). Indizes mit nur einer Datei werden gestrichen (->cleanup_table()) und die restlichen Indizes der Tabelle werden rekursiv weiter gelesen und in Tabellen einsortiert (->find_duplicates()). "EOF" hat einen eigenen Index in der Tabelle, wenn sich dort mehrere Einträge finden, hat man Duplikate gefunden.
    Dazu kommen noch Optimierungen wie dass das ganze nicht rekursiv sondern iterativ passiert, wenn nur noch ein Index in einer Tabelle übrig ist, dass das Lesen der Dateien gepuffert erfolgt (->read_chunk(), ->add_file()) usw.

    Ich hab oben eine neue Version angefügt, Dateigrößen über 4GB sollten jetzt funktionieren; die maximale Anzahl der Dateien die verglichen werden können liegt irgendwo unter 4 Millionen. Die neue Version ist außerdem merklich schneller und schafft den 2.6.10er Kernel-Sourcetree in ca. 1 1/2 Minuten, wobei die effektive Rechenzeit bei unter 3 Sekunden liegt.

    Falls noch Bedarf besteht... basiert auf einer Art rekursivem Bucket-Sort mit ein paar Abkürzungen und schmutzigen Tricks. Kompiliert und läuft unter Linux auf x86, obs portabel ist weiß ich nicht.