Lothar Esser wrote:

>
> 0x00000001200c9b28 in Mesh_Hash_UV(int*, int*, double (**) [2], double*)
> (Number=0x11fffb9b4, Max=0x11fffb9c8, Elements=0x11fffbb50,
>     aPoint=0x11fffbb08) at mesh.cpp:1972
> 1972      hash = (unsigned)((int)(326.0*P[U])^(int)(694.7*P[V])) %
> HASH_SIZE;
> (gdb) where
> #0  0x00000001200c9b28 in Mesh_Hash_UV(int*, int*, double (**) [2],
> double*) (Number=0x11fffb9b4, Max=0x11fffb9c8, Elements=0x11fffbb50,
> aPoint=0x11fffbb08) at mesh.cpp:1972
>

What I found out in the meantime is that apparently absurdly small values are passed
on to Mesh_Hash_UV in form of UV_VECT aPoint. That is

aPoint[U] = 1.0e-311 ; aPoint[V] = 1.0e-322;
The following recasting to int or even multiplication with another double leads to a
SIGFPE. I suspect that somehow these numbers are too small. So I allowed myself to
do:
P[U] = rint(P[U]); P[V] = rint(P[V]); after the Assign_UV_Vect(P, aPoint) statement
and then it worked.
Is this a unique problem of Tru64 or is there a switch or directive that takes care
of numerical underflow issues like these ?
( Ah, the puzzle somehow is now, why is aPoint so small ... this I have no clue about
- something uninitialized maybe ?)

Thanks for any information.

Lothar

Post a reply to this message