tp rechnet nicht richtig bei berechnungen in funktionen

also folgendes problem
ich brauche für ein programm den arcsin (berechnungen im 3eck)
soweit so gut

http://www.midnightbeach.com/jon/pubs/clp-faq.htm#arctan

in eine function gebastelt

function asin(x:real):real;
begin
asin:=arctan(x/sqrt(1-sqr(x)));
end;

erste frage fehlt da netnoch was?
es ist doch auch denkbar 1 an diese function zu übergeben so nen kreis im bogenmas geht doch von 0 bis 2 pi aber bei 1 hab ich ne division/0 ich hab also erstmal noch einen sonderfall eingebastelt

beim testen eben dessen kam ich dann zu einem interresanten phänomen ne invalid floting point operation
nach einiger suche war auch klar warum eine negative zahl unter der wurzel

ich habe die testeingeben mit denen ich dies schaffte dann mal in ein statisches programm geschrieben

var a,b,c,h,x,s:real;

begin
a:=sqrt(50);
b:=5;
c:=5;
s:=(a+b+c)/2;
x:=2/((b*c))*sqrt(s*(s-a)*(s-b)*(s-c));
h:=1-sqr(x);
writeln('x= ',x, ' 1-x²= ',h);
readln;
end.

die bildschirmausgabe dazu

x= 1.0000000000E+00 1-x²= -1.8189894035E-11

1-1²=-1,8^*10-11

compiliert unter turbopascal 6.0 (welches ich leider verwenden muß)


testweise hab ich das ganze dann mal unter devpascal mit freepascal compiler compiliert mit folgendem ergebniss

x= 1.000000000000000E+000 1-x²= 0.000000000000000E+000


da das net tragbar ist (die gefahr komplexe wurzeln zu bekommen die das programm abstürzen lassen ist mir einfach zu hoch)
wüßte ich gern ob jemand sagen kann woran das liegt (evtl ein bekannter tp6 bug ähnlich dem der unit crt in 7.0 auf schnellen rechnern)
und wie man ihn evtl umgehen kann
evtl irgendwelche compilerschalter

Vielleicht hilft es schon statt real einen genaueren Datentyp zu verwenden, wie zB double oder extended.

thx das hat geholfen ich wußte das ich irgendwie den numerischen coprozessor noch mit einbinden kann nur net wie
in der help zu den datentypen stand es dann
ein einfaches {$N+}
und schon klappts auch mir real