sin, cos, abs, min, max usw. keine Templates in C++???

[CStoll]

sinus user schrieb:

ich kann mit diesem workaround nun sin mit jedem datentyp ob int, char, float usw. benutzen was ich mit einer deklaration von nur float/double nicht kann.

Nochmal: Klar kannst du die Funktion sin() mit jedem Datentyp verwenden, der eine implizite Konvertierung nach double erlaubt (und das trifft auf jeden Fall für alle eingebauten Zahlentypen von C++ zu). Mit deinem Template ersetzt du lediglich die implizite Konvertierung durch eine explizite Konvertierung.

(und obendrein schneidest du dir selber Rechengenauigkeit ab, indem du runtergehst bis auf float)

[sinus user]

wer sagt denn das ich rechengenauigkeit benötige und nicht nur die zahl die vor dem komma steht? wie schon gesagt: sinus ist nur ein beispiel, bei log kommt das evtl. noch was besser rüber.

aber wenn ich

z. B. folgenden code habe:

int wert = 839245;
wert = sin (wert);

bekomm ich unter dem DevC++ und unter VC++2005 Express eine warnung wegen datenverlust, da der auf float konvertiert (da es eben kein Template für sin gibt). Mit meinem "workaround" bekomme ich dies nicht.

[CStoll]

Erstens: Das hast du selber gesagt;)[quote="sinus user"]ich soll von long double auf float casten damit ichs benutzen kann und somit höhere ungenaugkeit erzielen? ist das nicht schwachsinn?

Zweitens: Das einzige, was du mit deinem 'static_cast' erreicht hast, ist diese Warnung wegzudoktorn. Aber das ändert absolut nichts an dem Problem, auf das dich der Compiler hinweisen wollte. (btw, solange du keine Werte in der Größenordnung von INT_MAX verwenden willst, kannst du die Warnung problemlos ignorieren ;))

[sinus user]

du als Moderator und C++ coder sagst ernsthaft "warnung ignorieren"???????

[CStoll]

Ja, mache ich. Warnungen markieren zwar mögliche Fehlerquellen, aber wenn man weiß, was man da tut, kann man sie auch mal stehen lassen (und wie gesagt, solange sich deine Eingabewerte im überschaubaren Rahmen bewegen, ist dieser mögliche Genauigkeitsverlust auch nicht gefährlich - da sind mögliche Ungenauigkeiten IN der Sinus-Berechnung oft gravierender).

(und dein Cast hat nur eine Auswirkung auf das Programm - er unterdrückt die Warnmeldung des Compilers)

[sinus user]

ich denk mal da bleib ich doch lieber bei meinem workaround als warnings zu ignorieren.

[rüdiger]

sinus user schrieb:

Jester schrieb:

Welchen Vorteil hätte das template denn gegenüber der Überladung

float sin(float);
double sin(double);

wenn ich einfach mal den sinus von nem int haben will und den auch als int wieder haben will?

ROFL

hier

int sin(int) {
  return 0;
}

wenn du es so dringend brauchst

SCNR

[CStoll]

Nochmal: Dein Workaound ist absolut kontraproduktiv - und wenn du ihn unbedingt brauchst, solltest du sowieso nach double casten anstatt nach float. Und du erreichst damit nur eins gegenüber der Standard-Variante: Du verbietest dem Compiler, dich auf mögliche Genauigkeitsverluste aufmerksam zu machen (und das ist effektiv auch nichts anderes als die Compilerwarnung zu ignorieren).

Wenn mich der Compiler mit einer Warnung konfrontiert, habe ich normalerweise zwei Möglichkeiten, damit umzugehen:
a) ich schau mir an, worauf er mich da hinweisen will (viele Warnungen deuten auf syntaktisch korrekte, aber semantisch unsinnige Konstrukte wie if(flag=0)... ) - und korrigiere das Programm
b) ich ignoriere die Warnung, weil ich weiß, daß ich das genau so haben wollte (und in besonders hartnäckigen Fällen schalte ich die Warnung gleich komplett ab).

[.filmor]

rüdiger schrieb:

int sin(int) {
  return 0;
}

Hihi. Das geht dann als Least-Precision-Math-Library in den Standard ein
Ich hab auch noch eine Funktion beizusteuern:

int cos (int x)
{
    return x ? 0 : 1;
}

Und noch ein paar:

int acos (int x)
{
    if (x == 1) return 0;
    if (x == 0) return 1;
    if (x == -1) return 3;
    else return 1/0;
]

int asin (int x)
{
    if (x == 0) return 0;
    else return 1/0;
}

int atan (int x)
{
    if (x > 2) return 1;
    if (x < 2) return -1;
    else return 0;
}

Nur der Tangens ist fieser, aber da darf der sinus-user gerne sein Workaround einsetzen

[sinus user]

@rüdiger
irgendwie bist du dumm oder hast du noch nicht verstanden das ich sinus nur als beispiel genommen habe - wie ich es mehrfach schon erwähnt habe.

@CStoll
Okay ich caste nach double.

@.filmor
Auch wenn dein Post eigentlich nur Kontraproduktiv sein sollte, stelle ich dir jedoch mal trotzdem eine Frage: Warum sollte man z. B. acos oder atan nie als int haben wollen oder für einen anderen Datentypen? Nur weil genauigkeit drauf geht? so what?

Mir würd da schon auf anhieb ein Beispiel für logs einfallen wo man schon mal auf die dezimalstellen pfeifen kann.

[dot]

EDIT: ne, ich misch mich doch net ein, sry

[Bashar]

sinus user: Hier liegt doch überhaupt kein Fall von parametrischem Polymorphismus vor. Der Algorithmus, der den Sinus berechnet, sieht für jeden Datentyp anders aus. Du müsstest alle Instanziierungen durch explizite Spezialisierung herstellen. Es mag da subtile Unterschiede geben, aber eigentlich ist für solche Fälle Überladung gedacht. Falls dir das klar ist, würde ich gerne wissen, warum genau du das so haben willst.

[.filmor]

sinus user schrieb:

@rüdiger
irgendwie bist du dumm oder hast du noch nicht verstanden das ich sinus nur als beispiel genommen habe - wie ich es mehrfach schon erwähnt habe.

... was aber völlig irrelevant ist. Die trigonometrischen Funktionen machen ausnahmslos alle keinen Sinn auf Ganzzahlen.

sinus user schrieb:

Auch wenn dein Post eigentlich nur Kontraproduktiv sein sollte, stelle ich dir jedoch mal trotzdem eine Frage: Warum sollte man z. B. acos oder atan nie als int haben wollen oder für einen anderen Datentypen? Nur weil genauigkeit drauf geht? so what?

Wie gesagt, keine der trigonometrischen Funktionen ist über |Z sinnvoll.

sinus user schrieb:

Mir würd da schon auf anhieb ein Beispiel für logs einfallen wo man schon mal auf die dezimalstellen pfeifen kann.

In der Tat, der Logarithmus kann auf unsigned(!) int sinnvoll sein. Aber nicht auf allen oder einem großen Anteil der Datentypen. Und deshalb macht man aus ihm kein Template, sondern überlädt.

[rüdiger]

sinus user schrieb:

@rüdiger
irgendwie bist du dumm oder hast du noch nicht verstanden das ich sinus nur als beispiel genommen habe - wie ich es mehrfach schon erwähnt habe.

Wenn ich mir ein sin für Integer gewünscht hätte, wäre ich vorsichtig damit andere Leute als dumm zu bezeichnen :p

[sinus user]

.filmor schrieb:

sinus user schrieb:

Mir würd da schon auf anhieb ein Beispiel für logs einfallen wo man schon mal auf die dezimalstellen pfeifen kann.

In der Tat, der Logarithmus kann auf unsigned(!) int sinnvoll sein. Aber nicht auf allen oder einem großen Anteil der Datentypen. Und deshalb macht man aus ihm kein Template, sondern überlädt.

gibt es dafür nicht template spezialisierung?

@rüdiger:
Du bist dumm, da du dich noch immer an dem Beispiel von sinus festklammerst.

[cosinus user]

sinus user: du bist dumm.

[.filmor]

sinus user schrieb:

.filmor schrieb:

sinus user schrieb:

Mir würd da schon auf anhieb ein Beispiel für logs einfallen wo man schon mal auf die dezimalstellen pfeifen kann.

In der Tat, der Logarithmus kann auf unsigned(!) int sinnvoll sein. Aber nicht auf allen oder einem großen Anteil der Datentypen. Und deshalb macht man aus ihm kein Template, sondern überlädt.

gibt es dafür nicht template spezialisierung?

Nein. Die Template-Spezialisierung ist dafür da, in einigen wenigen Spezialfällen unter vielen allgemeinen etwas angepasst durchzuführen. Mathematische Funktionen funktionieren aber generell nur auf Zahlentypen und bei denen auch meistens nur auf "reellen" Zahlen (denen double und float noch am nächsten kommen). Also hast du eben nicht viele allgemeine Fälle sondern nur 3 (oder 6, wenn du die komplexen Zahlen noch hinzunimmst), nämlich die Fließkommatypen float, double und long double.

[pale dog]

.filmor schrieb:

Die trigonometrischen Funktionen machen ausnahmslos alle
keinen Sinn auf Ganzzahlen.

machen sie wohl.
z.b. wenn man keine foating point hardware hat und emulierte floats zu lahm sind.
--> http://www.allegro.cc/manual/api/fixed-point-math-routines/

[hustbaer]

@pale dog: fixkommazahlen sind keine integers. sie werden bloss als integers dargestellt.

[.filmor]

Lies dir meinen Satz durch. Ich schrieb bewusst Ganzzahlen und |Z und nicht Integer-Typen.