c - mathlib
 

sers @all

ich möchte unter linux in c die mathlib nutzen und schrieb folgendes kleines prog, daß unter visual c++ funzt:


-----------------cut--------------------

#include <stdio.h>
#include <math.h>

int main(int argc, char **argv)
{
int iwerte[100];
int i;
iwerte[0]=0;

for(i=0; i<100; iwerte[i]= pow(++i,2));

for(i=0; i<100; printf("%d\t%d\n", i, iwerte[++i]));
return 0;
}

----------------------cut----------------

beim versuch mit dem gcc, daß ganze zu compilieren erhalte ich folgende fehlermeldung:

/tmp/ccVaXske.o: In function `main':
/tmp/ccVaXske.o(.text+0x4f): undefined reference to `pow'
collect2: ld returned 1 exit status


öhm ... wie kann das?

für hilfe im voraus ein thx.

greetz
artemisia

HI!

Also ich habs grad mit gcc unter windos (mit cygwin) probiert und es hat problemlos funktioniert!
Außer das dein Array um eins zu klein ist. ;)
Meine Version von gcc ist 2.95.3-5

Schau mal ob bei die math.h installiert ist. (find /usr/include/ |grep math.h | less)
Es müsste eigentlich funktionieren...

lg

sers sonic

na, des array is ned zu klein. es enthält die quadratzahlen von 1 - 100.

unter win hab ich ja auch kein prob damit ... des prob entsteht beim compilieren unter linux.

*smile ... sicher ist math.h installiert

greetz
artemisia

btw: ls /usr/include/* | egrep "math.h" zeigt mir auch meine header

Die zweite for-Schleife enthält einen typischen Anfängerfehler, sonic hat recht, daß das Array unterdimensioniert ist.

@ Sonic und kikakater:

array ist nicht zu klein definiert, lediglich das printf - statement ist buggy:

for(i=0; i<100; printf("%d\t%d\n", i, iwerte[i++]));

wäre korrekt! Alles klar?

Zum kompilieren (hab schon längere Zeit nix mehr unter Linux gemacht *g*): die Library-Angabe beim Aufruf hast nicht vergessen (irgendwas a la '-lmath.so' oder so ähnlich ...) - der Meldung nach kann nämlich der Linker die Referenz nicht auflösen, was typischerweise auf eine nicht angegebene Bibliothek hinweist ...

lg
Belgarath

@sonic und kikakater

die "unterdimensionierung" hab ich noch einmal überprüft ...
das feld war schon richtig dimensioniert, nur der index war um eins zu hoch gesetzt.
hab zwei änderungen in den forschleifen vorgenommen:
for(i=0; i<100; iwerte[i++]= pow(i+1,2));
for (i=0; i<100; printf("%d\t%d\n", (i++)+1, iwerte[i]));

aber das erklärt trotzdem nicht, warum es unter win funzt und unter linux nicht.


greetz
artemisias

@belgarath

wow ... merci du

hast mir auf die sprünge geholfen ...
die genaue linker anweisung ist:
-lm
damit funzt es :-))

apropos forschleife: hier sollten nur die werte von 1 bis 100 und die entsprechenden quadratzahlen berechnet, gespeichert und ausgegeben werden.
das ganze war eh nur ein testprog.

greetz
artemisias

ohne es jetzt prüfen zu können (arbeite in der fa. auf ibm-mainframe): ich glaube, Dein 2. Ansatz ist jetzt 'richtig falsch' *g*

Warum?

erster Durchlauf:
also konkret:
in weiterer Folge:
usw.

erster Durchlauf:
Ausgabe:
usw.

Bei i=99 (also letzter Schleifendurchlauf) würde das Prog versuchen, auf iwerte[100] zu zu greifen, was entweder einen Zufallswert oder (hängt von Compiler und Einstellung ab) einen Absturz (segmentation fault) zu Folge haben müßte.

korrekt wäre IMHO (wie prinzipiell auch schon in meinem letzten Posting angegeben) :
Aber einfach ausprobieren, wenn Du mir nicht glauben solltest ...

lg
Belgarath

mathe-library dazulinken !!
 

Hi,
abgesehen von moeglicherweise falschen indizes
(dem augenschein nach, hab nicht drueber nachgedacht):
die fehlermeldung kommt, weil man beim gcc die
math-library explizit dazulinken muss:

gcc bla.c -o bla -lm
^^^^
...undefined reference to `pow'
sollte dann weg sein.

l.g.
andi

*smile, belgarath ....

nett gesagt: richtig falsch ;-)
was is nu falsch falsch?

also zu meinen schleifen:

sie funzen.

warum?

darum:

erster durchlauf:
iwerte[0] = pow(0+1,2);

also konkret:
iwerte[0] = 1;

in weiterer folge:
iwerte[1] = 4;
iwerte[2] = 9;

ich glaube, das kommt daher, weil der ausdruck von rechts nach links verarbeitet wird, meinst du nicht auch, daß das bei zuweisungen gewöhnlich der fall ist?

greetz
artemisias

@andi
merci ... hab es schon gefunden ... siehe posting oben

ok, erste for-schleife war ein blindgänger *schämundindieeckeverkriech* (obwohl ich mir einbilde, daß der C-Compiler auf der Micro-VAX in den späten 80ern genau dieses Verhalten gezeigt hat ... läßt sich jetzt natürlich besonders gut und leicht beweisen *g*), aber die 2. müßte stimmen, da dort von links nach rechts abgearbeitet wird, gelle ;)

lg
Belgarath

P.S.: bei der 2. Schleife wären dann natürlich die Ausgabe-Werte anders:
1 4
2 9
...

öhm ....

du .... hab gerad deinen vorschlag ausprobiert:


hab folgende ausgabe (natürlich ohne dots):

2....0
3....1
4....4
5....9
....

99.....9409
100....9604
101....9801

mh ... also ich mein, meine gefällt mir besser ;-)

greetz
artemisias

Die zweite for-Schleife enthält einen typischen Anfängerfehler, sonic hat recht, daß das Array unterdimensioniert ist.

Das sind zwei Feststellungen:
1. ein Anfängerfehler ---> [++i], hochzählen der Variable i um 1 vor dem Verwenden von i
2. INSOFERN: Array unterdimensioniert

Punkt 2 soll lediglich ausdrücken, daß, wer so "programmiert", sich nicht wundern braucht.


Fehler: for(i=0; i<100; printf("%d\t%d\n", i, iwerte[++i]));

Korrekt: for(i=0; i<100; i++) printf("%d\t%d\n", i, iwerte[i]);

Eine Schleife besteht nicht zu unrecht aus Initialisierungsteil,
Abbruchbedingung und Increment/Decrement.

Wer eine SCHLEIFENVARIABLE mitten in einer Schleife hochzählt, erzeugt damit einen Mischmasch aus Durchlauf n und Durchlauf n + 1.

ok, ich werd daheim meinen kobel damit füttern, daß ich nicht blind herumtasten muß ... allerdings: wenn i mit 0 initialisiert wird, dürfte in der 2. Schleife die Ausgabe nicht mit
2 ... 0
beginnen ... außer der Compiler arbeitet alles von rechts ab, was aber imho nicht korrekt wäre, da hier ja keine Zuweisung erfolgt.

Wie gesagt, ich werde es daheim ausprobieren ... *ascheaufmeinhaupt*

lg
Belgarath

mh .... mag ja gar nix mehr schreiben ... sonst kommst heut nimma mehr aus der *schämeecke ;-)

auch deine zweite forschleife hat nen leichten bug ...weil hier nämlich von rechts nach links ausgewertet wird.

korrekt müsste es heißen (und ist damit zugegebenermaßen einfacher als meine):


for ( i = 0; i < 100; printf( "%d\t%d\n", i, iwerte[i++] ) )

und dann funzt es auch mit der schleife *smile

greetz
artemisia

@kikakater:

wenn wir schon um des kaisers neue kleider streiten wollen *gg*:

wenn ich 100 werte erzeugen und in einem array ablegen will und mir dazu ein array mit 100 elementen anlege, habe ich genau richtig dimensioniert!

wenn ich dann allerdings mit falschen indizes arbeite, fliege ich irgendwann auf die schnauze ...

lg
Belgarath

allerdings gebe ich dir mit der (korrekten) trennung in initialisierung, abbruchbedingung, incr/decr _und_ eigentlich zu wiederholenden statement-teil recht. aber c läßt nun mal so einige schweinereien zu *fg*

lg
Belgarath

@kikakater

mh ... es ist mir im prinzip schnurz, was die lehrbücher erzählen ...

ich bin im mom am testen, was frau in forschleifen alles anstellen kann und in welcher reihenfolge der compiler das auswertet.
.... und wie du siehst (oder vielleicht auch nicht ;-) ) gibt es immer interessante seiteneffekte *ggg

c ist eben doch der geländewagen ....

greetz
artemisias

btw: ich finde, es gibt nichts faderes, als sich immer nur an vorgaben zu orientieren ... wo bleibt die progressivität?

ist eine gute lesbarkeit und leichte verständlichkeit auch nach mehr als 1 Woche Abstand zum eigenen Machwerk nicht progressiv *scnr*? Aber das Compilerverhalten (von rechts auflösen) ist schon recht heftig, und bei solchen Konstruktionen ist das nicht mehr trivial lesbar, selbst wenn man's weiß!

lg
Belgarath

for ( i = 0; i < 100; printf( "%d\t%d\n", i, iwerte[i++] ) )

Was soll das ?

.) Da fehlt das Semikolon am Schluß, Nummer 1.
.) Zweitens: i wird mit 0 ausgegeben, richtig wäre i + 1, iwerte[i] und
.) Drittens: i sollte und MUSS im Increment/Decrement Teil verändert werden, alles andere als das, ist ein Programmierfehler, es ist so, Ende der Diskussion, nichts für ungut.

for(i = 0; i < 100; i++)
printf("%d\t%d\n", i + 1, iwerte[i]);

Bis zum nächsten Lapsus, linken mit der Mathematik Bibliothek ist auch klar :)

@kikakater

*lol .... worüber reden wir hier eigentlich?

... mein stil ist meine sache ... mich interessiert es überhaupt ned, ob irgendetwas deinen prinzipien genügt ... sondern wie der compiler bestimmte ausdrücke auswertet und wie frau das kreativ einsetzen kann.
ein fehler liegt dann vor, wenn das prog etwas ausgibt, was es nicht ausgeben soll. wenn es genau das macht was es soll, liegt kein fehler vor.
wenn du aus einer anweisung zwei, drei oder eine halbe machen möchst, ist es deine sache ...ich wäre die letzte, die dich davon abhalten würd', schließlich tmtowtdi

und btw: ich hab noch ein säckchen ; für dich ;-)

@belgarath

bin im mom, wie schon gesagt dabei, die fähigkeiten und grenzen des compilers für mich auszureizen.
und dabei ist die lesbarkeit sekundär, ich schreib schließlich kein modul mit tausend vorgegebenen schnittstellen ... *smile

greetz
artmisias

@kikakater:

um nun endgültig den flamewar zum ausbruch zu bringen *fg*:

.) lies das erste (original-source-ausschnitt) posting: dort ist ein strichpunkt!
.) der compiler löst von rechts auf, daher hat i zum zeitpunkt der 'eigendarstellung' bereits den wert 1 (beim ersten durchlauf) - auch wenn ich es anders erwarten würde *g*
.) i wird (und das eindeutig!) im inc/dec-teil verändert - nur wird halt noch zusätzlich noch ein weiteres (ausgabe-)statement ausgeführt; was die sprach-definition und der compiler nicht verbieten, ist erlaubt! ob sinnvoll oder nicht (genau so wie die frage der lesbarkeit) ist ein anderes thema.

lg
Belgarath

p.s.: trotzdem stelle ich mir die frage, ob alle c-compiler in dieser reihenfolge auflösen ...

*ggg ... ich würd sagen: testen, testen, testen

greetz
artemisias

ps: öhm .... was ist flamewar?

@artemisias1:

mein hinweis auf die lesbarkeit als merkmal von progressivität war ein kleiner seitenhieb auf die tatsache, daß mir in meiner programmiertätigkeit schon zu hauf (schreibt man das in der neuen deutschen rechtschreibung überhaupt so?) sourcecodes von gegangenen kollegen untergekommen sind, deren lesbarkeit eigentlich <0 war! aus meiner sicht wäre also genau diese schier unglaublich progressiv!!!

lg
Belgarath

p.s.: von wegen wartbarkeit und so ...

mh.....

hast ja recht du ... von wegen lesbarkeit und so ...

aber schau, im mom bin ich im urlaub und teste halt so vor mich hin ... @work hab ich da scho ne andere haltung ...*kopfkratz ...na gut, zugegeben ... meistens jedenfalls (*lol ... ich hör jetzt schon das gemurre vom kollegen am montag ... frei nach dem motto: schön wäre es ... aber werd mich bessern ... versprochen ;-) )

greetz
artemisia

@artemisias1:

der begriff flamewar stammt noch aus der schönen zeit der 'echten' newsgroups (nix forum oder web-interface oder sonstigen neumodigen firlefanz *ggg*), und bezeichnet zum teil sehr heftige (manchmal leider auch persönlich werdende) 'glaubenskriege' - dazu gibt es dann noch den begriff des flame-bait, also des dazugehörigen köders (der vor allem schon altbekannte gegensätze wieder hinter dem ofen hervorholt - wie z.b. in diesem forum die intel-amd oder die via/nicht-via diskussionen ...)

alles klar?
dann kannst ja bei gelegenheit wieder einen bait auswerfen, wir beißen sicher alle gerne an *fg*

lg
Belgarath

*smile ...

also im prinzip des, was ich so ab und an im linux forum versuch?

... mh ...

leider funzt des da ned mehr so ... mein kismet is scho arg zahm geworden ... aber wer weiß ... vielleicht kann ich ja mich noch a bissl mit der programmierung auseinandersetzen ;-)

greetz
arte

merkwürdig ... irgendwie enden meine threads immer arg off topic

Bin zwar nicht arte, aber stellvertretend:

Die einzig wahre Kombination (tm) ist ja bekanntlich:
Linux
exim
emacs
GNOME

SCNR,
citizen428

*schmunzelt