normalize and vlen are slightly inconsistent.

[divVerent]

In FTEQW, looking at the implementations of PF_normalize and PF_vlen, it seems like the following property is true:

normalize(v) == v * (1.0 / vlen(v))

using the MUL_VF and DIV_F instructions.

Non compiler specific test case:

normalize(v) * '1 0 0' == v_x * (1.0 / vlen(v))

In DarkPlaces, this is not entirely true as the intermediate value f, storing vlen(v), is taken the reciprocal of while a double, not while a float (the square root is computed as a double in both engines for both builtins).

I suggest changing https://github.com/DarkPlacesEngine/DarkPlaces/blob/master/prvm_cmds.c#L528 from double f to prvm_vec_t f, so the two functions become consistent with each other, and to document this relationship in a comment. Also, possibly the 1.0 used for computing the reciprocal also needs to be cast to (prvm_vec_t).

[uis246]

So normalize has higher precision than vlen. Why is it bad?

[divVerent]

Primarily because it differs from FTEQW. Secondarily because them differing leads to people writing v / vlen(v) to match Q3A.

…

On Sun, Jan 26, 2025 at 3:45 PM uis246 ***@***.***> wrote: So normalize has higher precision than vlen. Why is it bad? — Reply to this email directly, view it on GitHub <#244 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB5NMHA6YC524LOC5AK6QT2MVCQHAVCNFSM6AAAAABVOVHRXSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJUGU4DINRZGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[divVerent]

Actually a third reason: the existing code hardcodes the assumption that double >= prvm_vec_t. That's true on all current platforms, but not guaranteed to stay that way.

[uis246]

typedef prvm_vec_t double double?