> >
> > w danym momencie zalezy mi na treningu asma a nie wynikach
> > kompilacji, do sse jeszcze nie dojechalem
> > =A0- bardzo zle napisana procedura, nie ma sprawdzenia czy nie
> > ma dzielenie przez 0 (co prawda takie podejscie jest
> > wydajniejsze bo np w moim raytracerku zerowe wektory sie
>
> Dzielenie przez zero oznacza, =BFe wektor jest zerowy.
> Normalizacja takiego jest zadaniem nieokre=B6lonym
> a wynikiem mojego programu jest tr=F3jka "nan",
> jak najbardziej poprawny wynik:)
>

to fajnie tylko,

1) raz ze nie wiem jak jest z tymi wyjatkami
fpu i czy nawet jak to nie leci (a u mnie w kompilatorze
jak podziele przez zero to leci po prostu blad aplikacji)
czy nie powoduje to jakichs opoznien w stosunku do
operacji na nie NANach (a o ile pamietam to costam czytalem
ze jest wtedy wolniej)

2) nawet jakby bylo ok (no byloby fajnie) to chyba w c nie
ma mozliwosci sprawdzenia

(f(f==NAN) costam ...

tak ze z takim wynikiem nie wiadomo co zrobic :O
(faktycznie bład c trzebaby to wbudować)







>
> > akurat nie trafia=B3y) i nie pisz4e sie trzech dzielen tylko
> > cos w stylu
> >
> > =A0double inv_d =3D 1.0/sqrt(a*a+b*b+c*c);
> > =A0a*=3Dinv_d;
> > =A0b*=3Dinv_d;
> > =A0c*=3Dinv_d;
>
> A to =B6wi=EAta prawda. Zapomnia=B3em o --fast-math
> (normalnie siedz=EA w VS).
>
> Po tej zmienie divsd zamienie si=EA na mulsd.
>
> > gcc jak widac tego zreszta nie zoptymalizowal i wstawil
> > te trzy dzielenia, w sumie fajnie popatrzec na
>
> Bez --fast-math mu nie wolno, bo zmienia to wynik.
>
>
> pzdr
> bartekltg
>


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/