TAN ohne math-include
-
Ja schön - nur wollte ich TAN-Definition aus Header-Dateien "rausklauen" - aber das ist nicht so einfach und scheinbar unmöglich...
-
Original erstellt von Krösus:
Probier's mal so:
Wenn sin() und cos() klappt, dann ist meines Wissens tan() = sin() / cos()
Verstehe nicht ganz, wo da das Problem liegen soll...Genau, weil:
(sinus / cosinus) = ((gegenkathete / hypotenuse) / (ankathete / hypotenuse)) = ((gegenkathete * hypotenuse) / (ankathete * hypotenuse)) = (gegenkathete / ankathete) = (tangens)
BTW: Warum willst du tan neucoden, es ist doch schon da???
Und: Selbercoden ist lehrreicher als abschreiben[ Dieser Beitrag wurde am 21.03.2003 um 15:25 Uhr von MaSTaH editiert. ]
-
#define tan(x) (sin(x)/cos(x))
-
neeee...
wie ist das in den headern - da steht so eine berechnung nicht... zudem denke ich dass so eine funktion halbsoschnell ist wie "native" - da hier SIN und COS zuerst berechnet werden müssen...
-
Dann include einfach math.h
-
Ne.... ich habe mir ausgedacht eine neue Programmiersprache zu coden. Da ich Compiler wohl ohne ASM-Kenntnisse niemals vernünftig machen könnte - habe ich mir gedacht ich nehme den GCC compiler und schmeiße alle header/includes weg.
So, wenn ich einen Code geschrieben habe, dann wird es in c++ konvertiert. Schlüsselwörter sollen in nativen c++ code umgewandelt werden (das ist der einfachere Teil, weil das ohne große Änderungen möglich ist). Alle andere Befehle sollen aus librarys entnommen werden. Besser gesagt je nach prog soll autom. eine dynamische library erzeugt werden und dann eingebaut werden. Wenn ich jetzt z.B. 1000 funktionen drin habe und 100 funktionen verwende, dann sollen nach möglichkeit 100 funktionen einkompiliert werden...
soweit die theorie - aber ob es machbar ich - da bin ich mir am überlegen...
-
#include <cmath>
is nun wirklich nich teuer
und dass es mit
double tan(double);
gehen sollte, is ja auch nich soo geheim
-
ach man du hast es nicht verstanden - wie soll ich cmath inkludieren, wenn ich alle inkludes rausgeworfen habe und speziell für meine "sprache" KOMPLETT neue mache - also nix mit diesen spaghettiheadern... (k.A. wer die gecodet hat - vielleicht ist es bei VC++ besser - aber scheinbar hat opensource doch nicht so gute qualität)...
-
ähm... du bist blind? double tan(double);
header rausschmeißen? why?
nochmal für langsame:double tan(double);das wars!
und falls das nich geht, füge -lm in die gcc zeile ein.
-
1. nur dadurch das du die header ersetzt kannst du keine neue sprache erzeugen
2. die header können garkeinen spaghetticode enthalten weil sie nur declarationen enthalten d.h. die enthalten keinen code direkt... und wo kein code ist kann auch kein spaghetticode sein...
wobie das hier kommt mir doch eher wie trollerei vor
-
Hier habe ich testweise tan ohne cmath - wie ich mir gedacht habe geht es nicht... was macht -lm????? mal sehen wie man das in DevC++ eintragen kann...
#include <iostream.h>
#include <stdlib.h>double tan(double);
int main()
{
cout<<tan(float(10)/float(20))<<endl;
system("PAUSE");
return 0;
}zu 1: ist mir schon klar - aber da ich halt den c++ compiler verwende, muss ich wohl mit den headern arbeiten...
zu 2: das habe ich auch früher gedacht, befor ich die header angesehen habe *g*
-
-lm geht auch nicht
-
Original erstellt von <TS>:
zu 2: das habe ich auch früher gedacht, befor ich die header angesehen habe *g*Ich denke du solltest nochmal ganz von vorne anfangen... Denn ganz am Anfang wurdest du auf das ungünstigste Gleis umgelenkt, nämlich auf das Gleis der Leute die vorhandene gute Sachen besser machen wollen anstatt sich neuen Problemen zu widmen und irgendwann begreifen, dass sie es doch nicht besser geschafft haben um dann frustriert das programmieren sein zu lassen...
-
Naja jetzt habe ich schon gefunden wie das geht - ich könnte schwören ich habe das min. 2x vorher genau so ausprobiert - aber es ging nicht... naja ist jetzt auch egal...
Neee also meine Idee war etwas neues zu erschaffen... Wenn ich jetzt die header von c++ belasse, dann wird das deutlich unsauberer... ob das überhaupt möglich ist und bei welchen aufwand, das weiß ich noch nicht - das ganze wird erstmal ein Prototyp. Wenn das was wird, dann wird die Bibliothek ausgebaut mit vielen Funktionen, die sich dynamisch zusammensetzen lassen...
Naja ich habe mir bisher noch keine großen C++-Codes gesehen. Aber so wie diese GCC-Header geschrieben sind, das ist glaube ich das Schlimmste was ich jemals im leben gesehen habe... Da ist die Hälfte irgend so ein Kompatibilitätsscheiss drin... Einfacher gesagt: Schlimmer als diese Header kann es nicht mehr werden, sondern nur besser... wenn ich mir dagegen meine neue Header ansehen (von denen ich bisher aber nicht viel habe) - dann sieht es gleich vernünftiger und strukturierter aus...
-
Vielleicht noch eine kleine Randbemerkung:
Grundsätzlich finde ich die Idee gar nicht so falsch, auf den GCC aufzusetzen und von Deiner Sprache erst mal auf C/C++ zu übersetzen. Damit hat man sich den richtig schwiedrigen Teil eines Compilers zum Teil gespart.
Aber nun nochmal zu Deinem "Include-Wahn": Das Du für eigene Funktionen auch Deine eigenen Include-Dateien schreibst ist ja richtig, aber warum willst Du zum Freck auf die "Standard"-Includes verzichten? Vielleicht denkst Du ja, dass Dein Programm kleiner wird, wenn Du nicht (c)math.h einbindest. Grosser Irrtum! Es kommt drauf an, gegen welche Bibliotheken der GCC in Dein Programm linkt. Die Header-Files der einzelnen Bibliotheken machen die Funktionen in Deinem Programm nur "sichtbar", aber der sin, bzw. cos-Code (oder tan-Code) ist ohnehin in Deinem Programm drin, wenn die entsprechende Bibliothek reingelinkt wird, egal ob Du math.h "includest" oder nicht.
-
es ist voellig egal, wie es in den headern aussieht. die haben fuer dich black boxes zu sein. im standard steht, was die machen.
und wenn da so viele kompatibilitaetssachen drin sind sei froh, dann brauchst du das nicht selbst schreiben.
-
Man könnte natürlich auch direkt die Assembler Befehle FSIN und FCOS verwenden, die dann mit asm("..."); eingebunden werden können.
-
Original erstellt von <keymaster>:
Man könnte natürlich auch direkt die Assembler Befehle FSIN und FCOS verwenden, die dann mit asm("..."); eingebunden werden können.Was meinst du was die C-Library-Funktionen machen? Ausserdem geht das nicht mit asm("...") sondern mit __asm ... oder __asm { ... ]
[ Dieser Beitrag wurde am 24.03.2003 um 15:38 Uhr von MaSTaH editiert. ]
-
hmm weil ich mich grad dafür interessiert hab hab mich mir die blackboxes doch mal angeschaut... die math.h ist interessant... zuerst scheint alles wie ich es erwartet hab. ein haufen declarationen... aber dann sind kurioserweise doch ein par funktionen direkt in den headern vorhanden (die genau diese asm statements verwenden).
man könnte natürlich noch auf die idee kommen sich eigene header zu bauen mit oprimierten befehlen sse 3dnow etc. aber das sollte die compiler ja eigentlich können
-
Das mit Include-Wahn wird wohl nicht anders gehen, denke ich - ich glaube das werde ich sowieso paar anderen Leuten überlassen und mich eher auf IDE und Konverter konzentrieren... (hehe)
Naja das math in exe immer eingebaut wird - das ist schon klar... allerdings habe ich bei einigen anderen inkludes gesehen, das schon ein einfaches einbinden ins programm die exe vergrößert, ohne dass ich überhaut eine funktion verwende. z.b. ist die exe dann statt 7 KB irgendwie 35KB groß geworden - naja und das soll halt verhindert werden...
und überhaupt soll das ganze ja etwas anders werden. Z.B. wird es kein cout<<text; geben. Stattdessen gibt es dann funktionen. besser gesagt - alles was an funktionen da ist, wird vom konverter nahezu 1:1 übersetzt. ich muss dann nicht beachten wie den nun ein befehl richtig in nativen c++ code umgewandelt wird und welche inkludes ich dazu benutzten muss - ich weiß dann sofort: inkludiere funktion x - fertig. hat dann zur folge, dass alle inkludes neugeschrieben werden müssen - jedoch gibt es auch vorteile. Z.B. wenn funktion X fehlt, dann einfach c++ code schreiben für funktion coden - und schon soll es als neue funktion erkannt werden und bei bedarf eingebaut werden... dadurch können alle inkludes von allen recht einfach geschrieben werden...