Zakum

:upps Wow, da kann ich nichts anderes sagen, extrem blöder Fehler... Daran hät ich denken müssen! Vielen Dank, Pointerman

Sry. für Doppelposting, konnte nicht mehr editieren: Das Problem habe ich umgangen, indem ich die Bedingung auf (Xpos>3) geändert habe. Dann passiert der Fehler nicht... Interesannt auch: Wenn ich die Bedingung (Ypos>=G) auf ((Ypos>G) || (Ypos=G)) ändere, dann fängt Ypos an zu spinnen und überspingt die 1... OO Sehr komischer Fehler, würde eigentlich auf die zu kleinen Felder hinweisen, die Guybrush angesprochen hat, aber mMn stimmt das alle!

Deine Idee klang so unsinnig, dass ich den betreffenden Bereich sofort auskommentiert habe, und siehe da, ohne diese Zeile läuft es so, wie es soll! Wenn ich jetzt noch dahinter steige, WARUM die Zeile böse ist... *grübel* Aber auf jeden Fall danke für den kreativen Tipp

Hallo! Ich war gerade dabei, beim Debuggen meines Programms zu verzweifeln, als mir ein höchst seltsames Benehmen seitens der Zählschleife auffiel. Ich hab eine ganz normale for-Schleife, mit einer inkremmentierung der Laufvariable (XPos) um 1 nach jedem durchlauf, solange gilt: XPos<5. Das klappt bis 2 auch ziemlich gut. Allerdings wird dann die 3 einfach übersprungen und nach XPos=2 kommt sofort XPos=4. Ich muss zugeben, dass mich dieser Fehler ziemlich verwirrt. Der Quelltextausschnitt sieht so aus: for(Ypos=0;Ypos<5;++Ypos) { if ((y_lauf+(PI/2)<PI) && (Ypos>G)) y_lauf=y_lauf+(PI/2); //Änderung von y_lauf erfolgt hier, da y_lauf in jeder Zeile konstant bleibt for [B](Xpos=0; Xpos<5; Xpos=Xpos+1)[/B] { if (Xpos>=G) { if (x_lauf+(PI/2)<PI) x_lauf=x_lauf+(PI/2); test=(cos(x_lauf)*0.5+0.5); graustufe[Ypos*5+Xpos]=graustufe[Ypos*5+Xpos]*test; if (Xpos=4) x_lauf=0; } if (Ypos>=G) { graustufe[Ypos*5+Xpos]=graustufe[Ypos*5+Xpos]*(cos(y_lauf)*0.5+0.5); //kein Nullsetzen von y_lauf nötig } } } Kann sich vlt. jemand denken, woran es scheitert? Ciao Zakum

Tut mir Leid, dass ich so lange gebraucht habe, ziemlich viel zu tun! Danke auf jeden Fall für die ganzen Antworten, dass -I klingt ganz nach der Lösung meiner Wahl, ich hoffe ich kann bald positives berichten. Danke auch übrigens für den hinweis auf Unterschied: HeaderFile -> Bilbliothek, dass muss ich mir unbedingt genauer anschauen.

Interesannt ist nebenbei, dass alle Beispiele, die ich im Netz gefunden habe, die malloc erläutern, auch das gecaste enthalten. Nun gut, wieder etwas schlauer! Habe jetzt übeigens den Code mal fremdcompiliert, hat wunderbar geklappt... Nach neuaufsetzen des eigenen Compilers gings dann auch bei mir... Am WE test ich dann, ob die Array-Referenzen auch funktionieren. *hoff*

Hi, ich muss mich erst einmal entschuldigen, ich weiß nicht genau, ob linken der richtige begriff ist. *rotwerd* Auf jeden Fall besteht folgendes Problem: Ich möchte mit meinem gcc Compiler ein Programm compilieren (soweit klingt ja noch alles ganz logisch ) Dabei muss ich eine C Bibliothek, die ich per #include im Quelltext eingebunden habe, und die nicht zum Standart-Zeug gehört, dem compiler per -lNameDerBibo mitteilen (erfüllt das den Tatbestand des Linkens? *verwirrt bin*) Nun, leider ist aber die Bibliothek meiner Wahl (COMPLEX.H) eine, die nicht installiert wird, wie andere, sondern einfach "rumliegt". Weiß vlt. jemand mit welchem Befehl ich die einbinden kann? Wenn ich es auf gewohnte weise versuche, dann wird mir nur mitgeteilt, dass der compiler complex.h nicht in /usr/bin/ld finden kann.

Oh, vielen Dank für die Antwort, ich hab unter der Woche wohl keine Zeit, aber am WE werd' ich mich mal an diese malloc Sache ransetzen, sehr mysteriös. Das das Array gleich als Referenz übergeben wird, ist natürlich sehr angenehm, hätte ich gar nicht gedacht, wird am WE auch umgesetzt. Und mal eine kleine Frage hinterher: Was genau heißt "malloc casten"? Ich muss gestehen, Zeiger an und für sich sind für mich programmistisches Neuland, noch mehr als C, insofern hatte ich mich bisher strickt an diverse Beispiele im Netz gehalten. :eek

Mhhh, Ok, nach diversen ausschreitungen meinerseits habe ich bemerkt, dass graustufe auch ein Zeiger sein sollte, wenn ich die Adresse übergeben will. int * graustufe; (Warum eigentlich, kann ich etwa nicht die Adresse einer einfachen Variable übergeben? *verwirrt bin*) Allerdings bekomme ich statt dessen einen anderen schönen Fehler: unverträgliche implizite Deklaration der eingebauten Funtion >>malloc<< wenn ich den Zeiger initialisieren will. int main() { ... int * graustufe; graustufe = (int*) malloc(65536*sizeof(int)); Schlagt mich, aber knapp 5 Zeilen drunter steht EXAKT das gleiche für einen anderen Zeiger, und der Compiler schluckt es: fftw_complex *fftArray; ... fftArray = (fftw_complex*) malloc(/*Ny*Nx*/256*256*sizeof(fftw_complex)); :eek

Hi, ich habe gerade eben erfahren müssen, dass es in C leider keine Referenzparameter gibt, sondern dass statt dessen Zeiger verwendet werden müssen. Nun habe ich das als C Anfänger auch umgesetzt, allerdings schimpft mein Compiler (gcc) dass ich eine "Übergabe von inkomptiblen Zeigertyp" habe, was meiner einer nun gar nicht einesehen kann. Wäre schön, wenn jemand mir da weiter helfen könnte void load([B]int* grauwert[])[/B] { int count,tmp_int,zahler; char c,tmp[3]; FILE *f1; f1=fopen("256*256.txt","r"); count=0; zahler=0; while (zahler<65536){ c=getc(f1); if ((c!='\t')&&(c!= '\n')) { count++; tmp[count-1]=c; } else { switch (count) { case 3:tmp_int=(tmp[0]-'0')*100+(tmp[1]-'0')*10+(tmp[2]-'0');break; case 2:tmp_int=(tmp[0]-'0')*10+(tmp[1]-'0');break; case 1:tmp_int=(tmp[0]-'0');break; } tmp[0]=0; tmp[1]=0; tmp[2]=0; [B](*grauwert[zahler])=tmp_int;[/B] count=0; ++zahler; } } fclose(f1); } int main() { int Nx, Ny; int graustufe[/*Nx*Ny*/256*256]; fftw_complex *fftArray; fftw_plan forw, backw; fftArray = (fftw_complex*) fftw_malloc(Ny*Nx*sizeof(fftw_complex)); [B] load(&graustufe); [/B] // Übergabe des Argumentes 1 von load von inkompatiblem zeigertyp ...

*arg* Mea culpa! Du hast natürlich völlig recht @Klotzkopp. Danke, daran lags auch. Hatte den Inhalt von Crushs post wohl nur zur Hälfte realisiert! Muss mal schaun, atoi hatte nichts in den Integer geschrieben, ich gugg mal was da los war. @Crush: Nun Delphi hat im ggs zu C sehr angenehme Strings, die gerne auch dynamisch sein können. Außerdem ist die Indizierung der Arrays etwas anders... Beginnt z.B. mit 1 Im Allgemeinen aber schon intersannt! Bis auf das 0-te Element hatte alles wie am Schnürchen geklappt, und das trotz völlig falscher Indizierung. :eek Nochmal danke euch beiden, ich wär am Ende noch völlig verzweifelt!

Mhh, mir ist gestern aufgefallen, wie ich das umgehe. Atoi hat leider nicht geklappt, da ich mit C programmieren MUSS und atoi hat da leider versagt. Ich bin jetzt soweit, dass ich über einen sehr unfeinen Trick (manuelles umrechnen von tmp in eine Zahl) die Daten in meine Matrix bekomme. Allerdings bin ich jetzt einem mysteriösen Problem aufgessesen. Das 0-te Array Element wird ganz brav befüllt. Der Zyklus wird wiederholt, und während das 1-te Element befüllt wird, überschreibt irgendetwas wieder das 0-te Element mit einer 9. Der Rest des Arrays wird problemlos befüllt. #include <stdio.h> int main () { FILE *f1; f1=fopen("256*256.txt","r"); int grauwert[256*256]; int Xpos,Ypos,count,tmp_int,zahler; char c[1],tmp[3]; count=0; Xpos=0; // Ypos=0; zahler=0; grauwert[0]=0; while (zahler<10/*256*256*/){ printf("\nGrauwert/tmp_int: %u / %u\n",grauwert[0], tmp_int); c[1]=getc(f1); printf("\nwhilezahler= %u\n",zahler); //Prüfe ob in While-Schleife if (c[1]!='\t') { count++; tmp[count]=c[1]; printf("tmp[1][2][3]= %c ",tmp[1]); printf("%c ",tmp[2]); printf("%c\n",tmp[3]); //Prüfe was in tmp ist } else { tmp_int=(tmp[1]-'0')*100+(tmp[2]-'0')*10+tmp[3]-'0'; tmp[1]=0; tmp[2]=0; tmp[3]=0; grauwert[zahler]=tmp_int; printf("\nGrauwert/tmp_int: %u / %u\n",grauwert[0], tmp_int); //Prüfe ab welchem Durchgang grauwert[0]=9 ist printf("\nelsezahler %u\n",zahler); //Prüfe ob in Else count=0; ++zahler; } } /*for(Ypos=0;Ypos<5;++Ypos) { for(Xpos=0;Xpos<5;++Xpos) { if (Xpos!=4) printf("%d ", grauwert[Ypos*256+Xpos]); else printf("%d\n", grauwert[Ypos*256+Xpos]); } }*/ for (Xpos=0;Xpos<10;++Xpos)printf("%d ",grauwert[Xpos]); return 0; } Ich weiß nicht, wird das 0-te Element eines Arrays eventuel dafür verwendet, dass das "System" (?) irgendwas speichert. Wäre mir neu.

Ok, ein Problem beseitigt, neues erscheint: Fehler lag an der (ja, man glaubt es kaum ) Segmentierung... bei einer 256*256 Matric kann ich nicht mit for(Ypos=1;Ypos<257;++Ypos) { befüllenn sondern natürlich for(Ypos=0;Ypos<256;++Ypos) { verwenden. Doch wenn ich nun testen will, ob die Matrix korrekt befüllt wurde, stelle ich fest: Nein, da sind überall 0 drin Ich versteh die Welt nicht mehr!

Generell stimmt das. Es wird jedoch kein kontinuierlicher Bildfluss werden. Am Anfang wird ein Bild aufgenommen und ausgewertet. Danach wird die jeweils entsprechende Abfolge von Aktionen ausgeführt. Anschließend wird wieder ein Bild aufgenommen, usw. Damit die Rechenlast für den armen Robo nicht so groß ist

Nun habe ich mir folgendes Gedacht: Ich gehe mit getc Zeile für Zeile, Buchstabe für Buchstabe durch, und fülle jedes Zeichen in eine Variable, bis ein Tabulator oder Zeilenumbruch kommt. Sobald der Umbruch da ist, wird der Inhalt der Variable genommen, und in die entsprechende Zelle der Matrix gehaun. Anschließend die Variable geleert, und das Spiel geht von vorne los. Leider bekomme ich zwei Warnungen und nach erfolgreichem compilieren und generieren mit gcc beium ausführen die Meldung: segmentation fault Der Quelltext sieht so aus: #include <stdio.h> int main () { FILE *f1; f1=fopen("256*256.txt","r"); int grauwert[256*256]; int Xpos,Ypos,count; int i,j; char c[1],tmp[3]; count=0; for(Ypos=1;Ypos<257;++Ypos) { for(Xpos=1;Xpos<257;++Xpos) { c[1]=getc(f1); if (c[1]!='\t') { count++; if (count==1) tmp[1]=c[1]; else strcat(tmp,c); } else { grauwert[Ypos*256+Xpos]=tmp; count=0; } } } ... Momentan bin ich ziemlich verwirrt, da der gleiche Ansatz mir in Delphi bisher immer gelungen ist. :confused: Weiß vlt. jemand, was ich falsch mache?

Es ist mir sogar ein bisschen Peinlich, aber momentan scheitere ich an einer Aufgabe, die ich für relativ einfach erachtet habe: Gegeben habe ich eine Datei, die nach eine bestimmsten Muster aufgebaut ist: 1 Zeile entspricht: 255 mal (Zahl, Tabulator) und 1 mal (Zahl, Zeilenumbruch) und von diesen Zeilen hab ich 256 Stück. 255 255 255 249 ... 249 167 76 25 ... 165 17 0 0 ... 31 4 0 0 ... ... Und das Ding will ich in eine 1d Matrix (passt der begriff Vektor? *grübel*) überführen. (zur Übersichlichkeit: siehe nächsten Post)

Es hat sich bei mir gerade wieder eine Frage ergeben... Ich habe bei FFTW die Auswahl zwischen der Transformation von Complexen oder aber von Reelen Daten. Die Graustufen sind Reel, das scheint mir zumindest logisch. Aber wenn man es recht bedenkt, dann hat das optische Ausgangssignal doch bestimmt auch negative Anteile, die ich in diesem Falle verliere? Aber das würde ja dann heißen, dass der gesammte Ansatz über die Graustufen zu gehen falsch ist!

Wow, danke, das hat suchtfaktor Allerdings steck momentan auf Level 8 fest und bin verwirrt ^^

Hmm, ich kann nur sagen, dass ich diesen Fehler regelmäßig hatte, bevor ich SP II aufgesetzt hab. Hat aber wohl nichts mit deinem Programm zu tun, sondern ist ein relativ verbreiteter OS - Fehler...

So, und Wochenends grüßt das Zakum-Tier! Ich hab im Netz was sehr schönes gefunden, nennt sich imageJ und kann so Sachen machen wie FFT und iFFT sowie diverse Filter und Bandpässe. (*hehe*) Hab natürlich gleich mal mit rumgespielt, auch wenn es mir direkt nicht weiterhilft, aber wenigstens um die FT etwas besser zu verstehen. *brr* so richtig logisch kommt mir das noch nicht vor. Ich hab mal ein paar Bilder transformiert um zu sehen wie die FT aussieht, im Anhang sind 2 screens gspeichert, ist ne ziemlich interesannte Sache! Hat auf jeden Fall dafür gereicht, um mich vom programmieren abzuhalten ^^

Stimmt natürlich! Ich sollte das nächste mal wohl nicht nur das lesen, was mir direkt unter die Augen kommt. *rotwerd* Zumal die Umsetzung so und so irgendwo einen fehler aufweisen muss, die Warnungen bleiben und es klappt nicht... Nun gut, also doch das 1d Feld

Hmm, anscheinend doch nicht... Folgende Quelle hab ich zu rate gezogen: 6.4 Dynamische Felder mittels Zeigervariablen Allerdings klappt der Quellcode so nicht int zeile, spalte, i; double **b; [B] b=new (double*[zeile]); [/B] // Allocate row pointers for (i = 0; i < zeile; i++) { [I][B] b[i]=new double[spalte]; [/B] [/I] // Allocate rows } Der Compiler gibt mir den Fehler: "syntax error bevor double" bei den fett markierten Zeilen sowie die Warnung "Zuweisung von inkompatiblen Zeigertyp" bei der kursiv markierten Zeile. Obwohl der Code für mich eigentlich ziemlich einleuchtend klang! //Edit: Hmm, ok, das könnte man auch nehmen, ich spiel mal n kleines Programm durch um zu schauen, ob ich das auch wirklich verstanden hab! *grübel* //Edit 2: Ahhh, ich hatte nicht beachtet, dass der Code in C++ war. In C sieht das ganze dann also so aus: int zeile, spalte, i; double **b; b= (double*) malloc(zeile*sizeof(double)); // Allocate row pointers for (i = 0; i < zeile; i++) { b[i]=(double*) malloc(spalte*sizeof(double)); // Allocate rows [Hier sind die Warnungen] } Gibt allerdings immernoch die Warnung: "Zuweisung von inkompatiblen Zeigertyp" und "unverträgliche implizite Deklaration der eingebauten Funktion <malloc>"

Ahh, danke, das ging ja richtig schnell! Oo Mal sehen ob ich das auch mit 2D hinbekomme

So, jetzt mal ne dumme frage! Ich hab vorher noch nie mit dynamischer Speicherverwaltung gearbeitet... fftw_complex *in, *out; in = (fftw_complex*) fftw_malloc(sizeof(fftw_complex) * N); Heißt das soviel wie, das ein Feld erstellt wird, vom Typ fftw_complex, mit N speicherbaren Werten? Kann ich dieses N im Verlauf des Programms verändern, so dass sich die Speicherreservierung sofort ändert? Oder muss ich es vor der deklaration mit malloc bestimmen?

Mhh, ich muss gestehen, das ich wieder beim Anfang des Threades angekommen bin... Zwar bin ich mit der FFTW jetzt vertraut, allerdings musste ich zwischendurch auf Linux und den gcc 4.0 Compiler umsteigen. Und damit kann ich leider kein OpenVC nutzen und, un ehrlich zu sein, ich hab beim Überfliegen der Anleitung nicht wirklich verstanden, wie mir das Open VC momentan helfen würde *rotwerd* Hätte vlt. jemand nen Tipp für eine Bibiliotek die mir ermöglichen würde Graustufenbilder in (gerne auch dynamische) 2D Felder einzulesen? Bisher konnte mir Onkel Google da nämlich auch nicht weiterhelfen