Grundsatzfrage bzgl. der Eignung für die Programmierung
-
Damit bin ich schon zufrieden.
Ich wollte nur dieses Alles-oder-gar-nichts-Ding ausräumen.Um jetzt tatsächlich wissenschaftlich drüber reden zu können, was "mehr" ausmacht, müsste man halt erstmal irgendeine Funktion haben, die diese beiden unterschiedlichen Größen (wenn man sie überhaupt auf eine Dimension reduziert bekommt) miteinander vergleichen kann. Sowas könnte man dann vielleicht an irgendwelchen Durchschnitten und Standardabweichungen festmachen. Ohne ist die Frage nach "Was macht mehr aus?" für mich etwas ähnlich wie die Frage, ob der Widerstand eines Leiters oder die anliegende Spannung entscheidender für die Stromstärke, die letztlich fließt, ist. Und bei unserem Thema kommt es auch noch drauf an, wie weit man die Begriffe fasst. Wenn man beispielsweise die Anzahl der Hände auch noch zur Veranlagung dazuzählt, wird die wichtiger als wenn nicht, usw.
Deine Schiffsschraubenanalogie ist nicht so mein Ding, weil sie einen additiven Zusammenhang impliziert. Ich seh da eher etwas (wenn überhaupt) multiplikatives. Meinetwegen Leistung des antreibenden Motors und Form/Größe usw. der Schriffsschraube.

Rein gefühlsmäßig würde ich aber auch sagen, dass auf Alltags-Niveau die Leistungsunterschiede wesentlich "stärker" durchs Training als durch die Veranlagung beeinflusst werden.
Um das dann mathematisch zu modellieren gäbs bestimmt mehrere Möglichkeiten. Man könnte dem Trainingwert zb einfach eine Zahl zwischen 0 und 100 zuordnen, und dem Talentwert nur eine Zahl zwischen 40 und 60, und schon hat man ein Ergebnis (Produkt), bei dem Training viel entscheidender ist. ^^
-
Dobi schrieb:
Man könnte dem Trainingwert zb einfach eine Zahl zwischen 0 und 100 zuordnen, und dem Talentwert nur eine Zahl zwischen 40 und 60, und schon hat man ein Ergebnis (Produkt), bei dem Training viel entscheidender ist.
double DobiFunction() { double ergebnis, schwachsinn = 100.00; ergebnis = pow(schwachsinn, 3); result ergebnis; }
daddeldu! :p
-
Dir ist schon klar, dass ich damit die Willkür, mit der solche Maßzahlen oft bestimmt werden, parodiert hab?
Man kann bei solchen nicht-natürlichen Sachen halt immer eine Skala erfinden, die einem gefällt. IQ ist ja auch einfach als Normalverteilung mit 100 als Mitte, x% unterhalb von 70 und x% oberhalb von 130 definiert, und die Testantworten werden halt so gewichtet, dass über die Normierungsgruppe genau das rauskommt. Jemand der bei so einem Test 120 Punkte bekommt ist ja auch nur in dieser beliebig gewählten Skala genau 1.2 mal so "gut" wie jemand, der 100 Punkte hat. Mein Kernpunkt ist also: Es gibt kein eindeutiges Maß, mit dem man Sachen wie Talent, Training, Intelligenz, Schönheit oder sonstwas in eine Zahl pratschen kann, weswegen man auch nicht objektiv sagen kann, was denn nun mehr ausmacht, sondern nur sein Gefühl dazu äußern kann.
-
berniebutt schrieb:
double DobiFunction() { double ergebnis, schwachsinn = 100.00; ergebnis = pow(schwachsinn, 3); result ergebnis; }
daddeldu! :pAuch Spaß-Code sollte kompilierbar sein!

-
_matze schrieb:
Auch Spaß-Code sollte kompilierbar sein!

Und effizient.
Ich wette meinen Linken Daumen,schwachsinn * schwachsinn * schwachsinnist schneller als die Schleife inpow(ganz zu schweigen vonstd::pow).
-
Sone schrieb:
Und effizient.
Ich wette meinen Linken Daumen,schwachsinn * schwachsinn * schwachsinnist schneller als die Schleife inpow(ganz zu schweigen vonstd::pow).Ich würde jetzt gerne meinen rechten Ringfinger dagegen wetten, aber vermutlich hast du Recht.

-
_matze schrieb:
Sone schrieb:
Und effizient.
Ich wette meinen Linken Daumen,schwachsinn * schwachsinn * schwachsinnist schneller als die Schleife inpow(ganz zu schweigen vonstd::pow).Ich würde jetzt gerne meinen rechten Ringfinger dagegen wetten, aber vermutlich hast du Recht.

#include <iostream> #include <ctime> #include <cmath> int main() { int prime = 7; clock_t secs = clock(); for(unsigned ct = 0;ct < 1e8;++ct) volatile int tmp = prime * prime * prime; std::cout << clock() - secs << '\n'; secs = clock(); for(unsigned ct = 0;ct < 1e8;++ct) volatile int tmp = pow(prime, 3); std::cout << clock() - secs << '\n'; }
Bei mir ist das im Durchschnitt einige Millisekunden langsamer, bei Ideone anscheinend nicht!
Und ein paar mal warpowschneller!
Wie ist das möglich!?
Ideone
-
ideone für Performancemessungen in Sekunden - ja ne, is klar.
#include <cmath> #include <chrono> #include <random> #include <iostream> #include <windows.h> int main() { std::mt19937 mt; mt.seed( static_cast< long unsigned >( std::chrono::system_clock().now().time_since_epoch().count() ) ); double x = 0.; double volatile y = 0.; LARGE_INTEGER t1 = {}; LARGE_INTEGER t2 = {}; QueryPerformanceCounter( &t1 ); for( unsigned ct = 0; ct < 1e8; ++ct ) { x = static_cast< double >( mt() ) / mt(); y = x * x * x; } QueryPerformanceCounter( &t2 ); std::cout << "***: " << ( t2.QuadPart - t1.QuadPart ) << '\n'; QueryPerformanceCounter( &t1 ); for( unsigned ct = 0; ct < 1e8; ++ct ) { x = static_cast< double >( mt() ) / mt(); y = pow( x, 3. ); } QueryPerformanceCounter( &t2 ); std::cout << "pow: " << ( t2.QuadPart - t1.QuadPart ) << '\n'; }***: 5373502 pow: 22601891
-
glühnase schrieb:
redrew99 schrieb:
Ja, wobei es für Anfänger vielleicht besser ist, wenn Strings eher als Klasse wahrgenommen werden und nicht als eigener Datentyp.
Ah, und Klassen sind keine Datentypen?
Ne, für Anfänger ist es besser, wenn sie die Begriffe richtig lernen.
<:xmas2:>
Ich würde eine Klasse als Anfänger eher als Datenstruktur denn als Datentyp sehen.
-
kk-in-hh schrieb:
Wie meinst du das und was wäre schlecht daran?
Auf was beziehst du dich da? String-Literale?
Ja und? Es ist doch völlig egal, ob std::string ein eingebauter oder ein benutzerdefinierter Typ ist.Viele Anfänger (bin ja selber einer), denken, wenn sie das erste Mal mit Strings zu tun haben, damit genau das gleiche machen können wie z.B. mit einem Char, Int, etc.
Daß string aber eine Klasse ist, weiß man als Anfänger oftmals nicht. Und demzufolge natürlich auch nicht, warum man z.B. strings addieren kann.
Weil dem TE dieses Hintergrundwissen fehlt, funktioniert auch sein Programm nicht.