Lawrence D?Oliveiro pisze:

On Wed, 20 May 2026 10:03:20 +0200, fir wrote:

Lawrence D?Oliveiro pisze:

Radians are the most natural unit for most trig calculations.

i dont know in fact but i dont think so - imo 0...1 has more sense

In radians,

sin x ? x as x ? 0

But only in radians.

i dont see any sense in thsi becouse what you sin is not x its angle
(and your x is not x in fact but y..becouse if sin is close to 0
y get close to 0 x gets close to 1)
and who said d(dangle)/d(y)should be 1? no sense to me (im not scholer
in math though)

for practical cpu reasons imo 0..1 seems much better (and radian seem
maybe most stupider)

if you got angle 0.001 you know its a 1/1000 of full circle..whats wrong
with that


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

David Brown pisze:

On 21/05/2026 03:23, Lawrence D?Oliveiro wrote:

On Wed, 20 May 2026 10:03:20 +0200, fir wrote:

Lawrence D?Oliveiro pisze:

Radians are the most natural unit for most trig calculations.

i dont know in fact but i dont think so - imo 0...1 has more sense

In radians,

ÿÿÿ sin x ? x as x ? 0

But only in radians.

Radians are clearly the most appropriate units of angle from a
mathematical viewpoint.ÿ But in practical use in programming, other
units can often make more sense.ÿ 0..1 floating point is one option, as
are degrees, or scaled integers (0 .. 2 ** n - 1 ranges are common in
motor control systems).ÿ If you are using floating point, then usually
it's a small matter to scale them when you need to - so sticking to
radians makes sense.ÿ And if you are using integers to get maximal efficiency on small systems, then every system will be different
(because of different accuracy / efficiency trade-offs) so there is no reason to pick any one choice.

to pick a best choice has very sense becouse if no it makes "babel
twoer" (if its called in english?)

for example it seems that thos small math functions in c makes smal
babel tower here

for example what chat gpt genereted me of this functions (part of it as
it generates many)

static inline int clampi(int v, int a, int b)
{
return v < a ? a : (v > b ? b : v);
}




static float clampf(float v, float a, float b)
{
if(v < a) return a;
if(v > b) return b;
return v;
}

float randf(float a, float b)
{
return a + (b - a) * (rand() / (float)RAND_MAX);
}



// ------------------------------------------------------
// swap helper
// ------------------------------------------------------
static inline void swap_i(int* a, int* b)
{
int t = *a;
*a = *b;
*b = t;
}


// ------------------------------------------------------
// sort by Y
// ------------------------------------------------------
static inline void sort_by_y(int* x1,int* y1,
int* x2,int* y2,
int* x3,int* y3)
{
if (*y1 > *y2) { swap_i(y1,y2); swap_i(x1,x2); }
if (*y2 > *y3) { swap_i(y2,y3); swap_i(x2,x3); }
if (*y1 > *y2) { swap_i(y1,y2); swap_i(x1,x2); }
}




// =====================
// SORT 3 POINTS BY Y
// =====================
static void sort3(int* x0,int* y0,int* x1,int* y1,int* x2,int* y2)
{
if (*y0 > *y1) { int t;
t=*x0;*x0=*x1;*x1=t;
t=*y0;*y0=*y1;*y1=t;
}
if (*y0 > *y2) { int t;
t=*x0;*x0=*x2;*x2=t;
t=*y0;*y0=*y2;*y2=t;
}
if (*y1 > *y2) { int t;
t=*x1;*x1=*x2;*x2=t;
t=*y1;*y1=*y2;*y2=t;
}
}




// ======================================================
// SORT BY Y (4 vertices)
// ======================================================
static inline void sort4(int* x, int* y)
{
for (int i = 0; i < 3; i++)
for (int j = 0; j < 3 - i; j++)
{
if (y[j] > y[j+1])
{
swap_i(&y[j], &y[j+1]);
swap_i(&x[j], &x[j+1]);
}
}
}


// ======================================================
// LINEAR INTERPOLATION X BETWEEN TWO POINTS
// ======================================================
static inline int lerp_x(int x0,int y0,int x1,int y1,int y)
{
if (y1 == y0) return x0;
return x0 + ((x1 - x0) * (y - y0)) / (y1 - y0);
}


// ======================================================
// LINE INTERPOLATION (fixed-point free, fast int)
// ======================================================
static inline int lerp(int x0,int y0,int x1,int y1,int y)
{
if (y1 == y0) return x0;
return x0 + ( (x1 - x0) * (y - y0) ) / (y1 - y0);
}

it messes with my own functions who i wrot with different names and
slightly other way sometimes

such small functions better be part of clib - may be a source lib..same
need is imo possibly for angle type and its suport in cpu this way

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

Lawrence D?Oliveiro pisze:

On Wed, 20 May 2026 10:03:20 +0200, fir wrote:

Lawrence D?Oliveiro pisze:

Radians are the most natural unit for most trig calculations.

i dont know in fact but i dont think so - imo 0...1 has more sense

In radians,

ÿÿÿ sin x ? x as x ? 0

But only in radians.

i dont see any sense in thsi becouse what you sin is not x its angle
(and your x is not x in fact but y..becouse if sin is close to 0
y get close to 0 x gets close to 1)
and who said d(dangle)/d(y)should be 1? no sense to me (im not scholer
in math though)

for practical cpu reasons imo 0..1 seems much better (and radian seem
maybe most stupider)

if you got angle 0.001 you know its a 1/1000 of full circle..whats wrong with that

it seem that fpu math on such angle type probably would be somewhat
simpler than on real float (im not sure though)

lest ask ai:


What you are describing is actually not a stupid idea at all. In a
sense, it sits somewhere between:

angle-as-turns (0..1 = full rotation),
a fixed-point phase accumulator,
and a specialized cyclic/modular numeric type.

For certain kinds of operations this could genuinely be simpler and
possibly faster:

angle wrapping,
phase interpolation,
sin/cos lookup,
DDS/audio synthesis,
shaders,
2D rotations,
procedural generation.

Traditional angle math is surprisingly awkward for CPUs:

degrees require division by 360,
radians drag around ã everywhere,
wrapping requires fmod() or branches,
normalization requires floor() or conditionals,
trig functions expect radians.

With a type like:

angle a;

where:

0.0 = 0ø
0.25 = 90ø
0.5 = 180ø
0.75 = 270ø

things become much cleaner.

For example:

a += velocity;

and overflow naturally wraps modulo 1.

This is almost ideal for:

audio oscillators,
phase accumulators,
raycasters,
retro renderers,
demoscene code,
DSP.

Historically, very similar ideas already existed:

BAM (Binary Angle Measurement),
fixed-point angle systems in consoles,
phase accumulators in synthesizers,
"turns" as an angle unit,
lookup-table trigonometry.

For example, old engines like Doom or Build effectively used something
close to:

uint16_t angle;

where:

0..65535 = full rotation

Then:

angle += rot_speed;

becomes a single integer add instruction with automatic wraparound ? no
fmod() needed.

From a hardware perspective that is actually beautiful.

However, modern FPUs are already extremely optimized for ordinary float operations. So:

basic addition/multiplication probably would not become faster,
but cyclic/modular operations could become logically simpler,
and integer-based cyclic angles could even outperform float-based ones.

The most "CPU-native" representation would probably look something like:

typedef uint32_t angle32;

where:

0x00000000 = 0ø
0xFFFFFFFF ÷ almost 360ø

Then:

overflow gives free wrapping,
interpolation becomes trivial,
angle differences are cheap,
LUT indexing becomes elegant,
trig lookup tables fit naturally,
ã disappears from most low-level code.

It almost feels like a hybrid between an old Carmack-style engine
architecture and tracker/synthesizer mathematics.

The interesting part is this:

the problem is not really the 0..1 range itself.

The real issue is that IEEE floating-point types have no notion of
cyclicity or periodicity built into the type system.

If something like:

cyclic float angle;

existed, a compiler could theoretically:

perform automatic wrapping,
optimize trig operations,
use specialized instructions,
improve SIMD interpolation,
eliminate some branches.

At that point the discussion starts touching language design and even
CPU ISA design.

And honestly, for graphics/audio/gameplay systems this idea actually
makes a lot of sense.

A huge amount of modern computation is fundamentally:

periodic,
oscillatory,
rotational,
phase-based.

So the idea of a phase-space-native numeric type does not sound
ridiculous at all. It sounds like something that could plausibly appear
in DSP research papers or specialized GPU/engine architectures.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

i asked ai yet

so why its not implemented on x64 pus?

Because general-purpose CPUs are designed around universal arithmetic,
not around mathematically specialized domains like cyclic topology.

Your idea is actually quite reasonable ? but hardware architects
historically optimize for:

maximum generality,
compatibility,
transistor budget,
predictable semantics,
IEEE standardization,
compiler simplicity.

And cyclic numbers are surprisingly "nontrivial" once you try to
formalize them at ISA level.

There are several reasons.

1. Angles Are a Niche Type

Even though angles/phases are everywhere in:

graphics,
DSP,
physics,
games,
shaders,

they are still a minority compared to:

ordinary linear arithmetic,
memory operations,
integer logic,
matrix math,
AI workloads,
database/server workloads.

CPU vendors optimize for the average workload.

Adding:

cyclic float

support at hardware level would consume:

ISA space,
verification effort,
compiler complexity,
silicon area,

for something most software never uses.

2. IEEE Floats Are Linear By Definition

IEEE-754 fundamentally models numbers on the real line:

R

not on compact manifolds like:

S
1

(a circle).

Cyclic arithmetic breaks some assumptions CPUs rely on:

ordering becomes weird,
comparisons become ambiguous,
overflow semantics change,
interpolation semantics become context-dependent.

For example:

0.99 and 0.01

are:

far apart linearly,
but extremely close cyclically.

Now imagine defining:

<

min
clamp
sorting,
hashing,
vector reductions

for such numbers.

It gets philosophically ugly very fast.

3. CPUs Prefer Primitive Building Blocks

Modern CPUs are optimized for:

add,
multiply,
FMA,
SIMD,
bitwise ops.

Architects prefer exposing simple primitives and letting software build abstractions.

And indeed:

DSP engines,
game engines,
synthesizers,
shaders,

already implement cyclic arithmetic extremely efficiently in software.

So hardware vendors see little pressure.

4. SIMD Actually Made This Less Necessary

Ironically, AVX/SSE reduced the need for specialized angle hardware.

Because now software can cheaply do:

vectorized wraps,
LUT indexing,
masked corrections,
branchless normalization.

Example:

angle -= floor(angle);

can already vectorize nicely.

So the performance pain became smaller over time.

5. Hardware Already Quietly Uses Similar Ideas

This is the funny part.

Your idea does exist internally in many places.

Examples:

DDS synthesizers,
GPU texture wrapping,
phase accumulators,
CORDIC units,
PLL hardware,
fixed-function graphics pipelines,
FPGA DSP blocks.

Especially GPUs already contain lots of implicit modular arithmetic.

So the concept absolutely is hardware-natural.

It just never became a general-purpose language-visible primitive type.

6. Language/Compiler Problems Become Difficult

Suppose C had:

cyclic float angle;

Now the compiler must define:

implicit wrap rules,
promotion rules,
casts,
NaN semantics,
infinities?,
modulo behavior,
signedness?,
shortest-path interpolation?,
trig expectations?,
vectorization rules.

This becomes almost an entirely new arithmetic system.

7. Most Scientific Computing Uses Complex Numbers Instead

In quantum mechanics, DSP, electromagnetics, etc., people usually
represent phase indirectly via:

e
i?

rather than storing explicit normalized cyclic scalars.

Complex arithmetic already encodes periodicity naturally:

multiplication = phase addition,
conjugation = phase inversion,
unit circle = normalized phase space.

So mathematically, complex numbers became the dominant abstraction
instead of cyclic scalar primitives.

8. History and Momentum Matter Enormously

This is probably the biggest reason.

CPU ISAs carry decades of compatibility baggage:

x86 still carries instructions from the 1970s,
IEEE-754 became deeply entrenched,
compilers/toolchains assume linear arithmetic.

Changing numeric foundations is extraordinarily difficult.

Even objectively useful ideas often never happen unless:

they solve a massive commercial problem,
or a killer application forces adoption.

Ironically, your idea probably would fit better into:

DSP-oriented ISAs,
shader languages,
future physics-oriented accelerators,
simulation hardware,
functional numeric languages,

than into traditional x86 CPUs.

And mathematically, the idea is actually quite elegant:
you are basically asking for a primitive numeric type whose topology is circular instead of linear.

fir again:
im not sure though if i agree in what ai said..im also not quite sure it
it would not help (speedup) classical trygonometry maybe

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

i asked ai yet

fir again:
im not sure though if i agree in what ai said..im also not quite sure it
it would not help (speedup) classical trygonometry maybe

a taki typ wbudowany nie przyspieszylby jakos wogole liczenia
trygonometrii? np zredukowal licznie sinusow lub je przyspieszyl?

Potentially yes ? especially historically, and still somewhat today ?
but mostly indirectly.

The key insight is:

for trig functions, a huge amount of work is not the polynomial
approximation itself, but:

argument reduction,
normalization,
handling gigantic inputs,
precision correction,
edge cases.

And cyclic angle types could simplify exactly those parts.

For example, when you call:

sin(x)

modern implementations first need to reduce x into a small canonical
range like:

[?ã/4,ã/4]

because polynomial approximations only work accurately there.

But this reduction step is surprisingly expensive.

Especially for huge inputs:

sin(1e30)

becomes nasty internally because the library must do extremely
high-precision modulo reduction against ã.

Historically, argument reduction was often one of the hardest parts of
trig implementations.

Now imagine a cyclic type:

angle a; // already normalized 0..1

Then:

sin(a)

already guarantees:

bounded input,
periodicity,
normalized phase space.

So internally:

no giant-range reduction,
fewer edge cases,
simpler polynomial selection,
easier LUT indexing,
potentially branchless implementations.

In fact, for many systems you could reduce trig to almost pure table lookup:

return sin_table[(uint32_t)(a * TABLE_SIZE)];

This was historically VERY common:

consoles,
demoscene,
DSP chips,
old game engines,
synthesizers.

And cyclic integer angle spaces fit LUT trig almost perfectly.

Even modern hardware secretly prefers bounded phases.

For example:

GPU shader approximations,
DSP oscillators,
SIMD trig approximations,
FFT kernels,

often internally assume reduced ranges already.

Would this make trig dramatically faster on modern x64?

For high-precision libm-style trig:

maybe somewhat,
mostly by simplifying argument reduction.

But for:

approximate trig,
realtime graphics,
DSP,
oscillators,
procedural systems,

it could potentially help a LOT.

Because then trig becomes fundamentally:

phase -> waveform lookup/interpolation

instead of:

arbitrary real-number transcendental evaluation

There is also a deeper hardware angle here.

Modern CPUs do NOT have true hardware sine/cosine instructions anymore
in the fast path.

Old x87 had:

FSIN
FCOS

but they became relatively unattractive because:

hard to pipeline,
inconsistent precision,
microcoded,
slower than optimized SIMD software in many cases.

Modern systems usually use:

polynomial approximations,
vectorized math libraries,
LUT hybrids,
range reduction tricks.

A cyclic primitive could theoretically make specialized trig hardware
more viable again because:

the input domain becomes bounded and predictable,
periodicity becomes guaranteed,
edge-case explosion disappears.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

i asked yet if ai can value how much speedup would give such cpu builtin
angle type for generel codes if maybe 1% or less?

Realistically: for general-purpose x64 CPUs, it would likely give well
under 1% average performance uplift across typical workloads.

Possibly even:

0.01% ? 0.2%

at the level of the whole ?software ecosystem?.

That?s essentially why no mainstream CPU implements it.

BUT for very specific workloads:

DSP,
audio synthesis,
FFT-heavy systems,
procedural animation,
signal processing,
retro/game engines,
large-scale oscillator simulations,

you could see local gains like:

5?30%

in certain kernels.

And sometimes even more if the original code is very trig-heavy.

Because the key issue is:

sin/cos are a small part of modern CPU cost

On modern CPUs most time is spent on:

memory access,
cache misses,
branch mispredictions,
vector operations,
synchronization,
RAM latency,
GPU bottlenecks.

Not on:

sin()
cos()

Especially since:

trig is often cached,
computed once per object,
or replaced with LUTs.
x64 is already heavily ?general-purpose optimized?

Modern CPUs have:

wide SIMD units,
superscalar execution,
FMA,
branch predictors,
out-of-order execution,
speculative execution.

Adding:

cyclic-angle arithmetic

is a very niche gain compared to the whole architecture.

BUT locally it could be very beneficial

Example:

for(i=0;i<1000000;i++)
out[i]=sin(phase[i]);

If:

phase is always in 0..1,
hardware understands periodicity,
LUT/range reduction becomes simpler,
vectorized phase arithmetic is available,

then you could:

shorten pipelines,
reduce latency,
simplify microcode,
increase SIMD throughput.

And then the difference could be significant.

Historically it would have mattered much more

In the:

80s,
90s,
early 2000s,

this could have been extremely valuable.

Because back then:

trig was expensive,
FPUs were weak,
caches were small,
LUTs were critical.

That?s why systems used:

BAM,
fixed-point angles,
lookup tables,
CORDIC,
precomputed rotations.

In a sense, hardware simply became so powerful that the problem stopped
being important.

Where the real potential is today

Not x64.

But:

DSP chips,
GPU shader cores,
embedded simulation hardware,
physics accelerators,
neuromorphic/signal processors,
FPGA DSP pipelines.

There, periodicity is fundamental.

One more interesting point

If such a type existed at the language + compiler level rather than just
ISA level, much larger optimizations could appear globally.

For example, the compiler would know:

this value is periodic

and could:

eliminate normalization code,
fold trig chains,
apply recurrence transformations,
detect oscillator patterns,
use specialized SIMD kernels.

In that case, gains could be larger than hardware-only support alone.

Summary:
For the whole software ecosystem:

essentially negligible.

For phase-heavy kernels:

potentially very noticeable.

For DSP/audio/simulation:

a genuinely meaningful idea.

Historically:

it could have been quite powerful.

Mathematically:

it is a very elegant concept.

Architecturally:

the problem is too niche for mainstream x64 ISA support.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

Summary:
For the whole software ecosystem:

essentially negligible.

For phase-heavy kernels:

potentially very noticeable.

For DSP/audio/simulation:

a genuinely meaningful idea.

Historically:

it could have been quite powerful.

Mathematically:

it is a very elegant concept.

Architecturally:

the problem is too niche for mainstream x64 ISA support.

sorry for talkin with ai (i uset to talk with myself (its a joke, i was
not talking with myself really just adding thoughts) so now i can talk
withm myself and ai ;c but as this group is not big and in some topic is
not a biger chance for indepth discussion i can post some ai answers
which in turn trigges many f smaller potential points of dicussion if
someone is interested (and if no may skip/ignore..still for me most
important is if subject is good and thoughts are reasonable)

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, 21 May 2026 22:01:18 +0200, fir wrote:

to pick a best choice has very sense becouse if no it makes "babel
twoer" (if its called in english?)

You mean, having to convert between a whole lot of different angle
units?

I have no problem with supporting different angle units. Let the user
input angles in whatever units they want, and get back answers in
whatever units they want. Internally, all angles get converted to
radians, the calculations are done, and the results converted back
again.

What annoys me just a bit is seeing these little functions like
?degrees to radians? and ?radians to degrees? -- so you need two
conversion functions (converting to and from radians) for every angle
unit you want to support.

It?s simpler to just offer a single conversion factor, which can be
used like this:

®angle-in-units-X¯ ? ®conversion-factor-for-units-X¯ ? ®angle-in-radians¯

and going the other way:

®angle-in-radians¯ ö ®conversion-factor-for-units-X¯ ? ®angle-in-units-X¯

So for example if you want angles in degrees, then the conversion
factor is ã/180; if you want to work in units of full circles, then
the conversion factor is 2ã. All nice and simple, and scalable, too.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, 21 May 2026 21:42:08 +0200, fir wrote:

Lawrence D?Oliveiro pisze:

In radians,

sin x ? x as x ? 0

But only in radians.

i dont see any sense in thsi becouse what you sin is not x its angle

What is an angle? It?s just a ratio of two lengths, the arc
circumference to the arc radius. Distance ö distance = a ratio which
is a pure number, with no units.

Start with the Euler identity:

$$e^{ix} = \cos x + i \sin x$$

and, from the well-known expansion for $e^{x}$, you get

$$\sin x = x - {x^3 \over 3!} + {x^5 \over 5!} - {x^7 \over 7!} ...$$
$$\cos x = 1 - {x^2 \over 2!} + {x^4 \over 4!} - {x^6 \over 6!} ...$$

But again, all this works only in radians.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-22 02:00, Lawrence D?Oliveiro wrote:

[...]

I have no problem with supporting different angle units. Let the user
input angles in whatever units they want, and get back answers in
whatever units they want. Internally, all angles get converted to
radians, the calculations are done, and the results converted back
again.

What annoys me just a bit is seeing these little functions like
?degrees to radians? and ?radians to degrees? -- so you need two
conversion functions (converting to and from radians) for every angle
unit you want to support.

Hmm.. - if looking for example into the Genie math preludes you'll
find another (annoying?) variant; that such functions exist in two
variants ("fun" and "fun_dg"). - May look better to the programmer
to not have a separate conversion step. But it blows up the number
of entries in the namespace extremely.

It?s simpler to just offer a single conversion factor, which can be
used like this:

®angle-in-units-X¯ ? ®conversion-factor-for-units-X¯ ? ®angle-in-radians¯

and going the other way:

®angle-in-radians¯ ö ®conversion-factor-for-units-X¯ ? ®angle-in-units-X¯

So for example if you want angles in degrees, then the conversion
factor is ã/180; if you want to work in units of full circles, then
the conversion factor is 2ã. All nice and simple, and scalable, too.

Hmm..

Janis


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Lawrence D?Oliveiro pisze:

On Thu, 21 May 2026 21:42:08 +0200, fir wrote:

Lawrence D?Oliveiro pisze:

In radians,

sin x ? x as x ? 0

But only in radians.

i dont see any sense in thsi becouse what you sin is not x its angle

What is an angle? It?s just a ratio of two lengths, the arc
circumference to the arc radius. Distance ö distance = a ratio which
is a pure number, with no units.

Start with the Euler identity:

$$e^{ix} = \cos x + i \sin x$$

and, from the well-known expansion for $e^{x}$, you get

$$\sin x = x - {x^3 \over 3!} + {x^5 \over 5!} - {x^7 \over 7!} ...$$
$$\cos x = 1 - {x^2 \over 2!} + {x^4 \over 4!} - {x^6 \over 6!} ...$$

But again, all this works only in radians.

ai said that with radians d(sin(x)) / dx =cos(x)

but i dont get it - im not sure it should.. for example in c
programming i used many sin cos but not calculated d sin(x)/ dx
so i dont need it anyway in this 0..1 angle you have d sin(x)/dx =
2*pi*cos(x) so you can multiply and then you need to use this 2*pi much
more rare which seems fortunate

c coding is not exactly midlle school book mathematics

but t

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

Lawrence D?Oliveiro pisze:

On Thu, 21 May 2026 21:42:08 +0200, fir wrote:

Lawrence D?Oliveiro pisze:

In radians,

ÿÿÿÿ sin x ? x as x ? 0

But only in radians.

i dont see any sense in thsi becouse what you sin is not x its angle

What is an angle? It?s just a ratio of two lengths, the arc
circumference to the arc radius. Distance ö distance = a ratio which
is a pure number, with no units.

Start with the Euler identity:

ÿÿÿÿ $$e^{ix} = \cos x + i \sin x$$

and, from the well-known expansion for $e^{x}$, you get

ÿÿÿÿ $$\sin x = x - {x^3 \over 3!} + {x^5 \over 5!} - {x^7 \over 7!}
...$$
ÿÿÿÿ $$\cos x = 1 - {x^2 \over 2!} + {x^4 \over 4!} - {x^6 \over 6!}
...$$

But again, all this works only in radians.

ai said that with radians d(sin(x)) / dx =cos(x)

but i dont get it - im not sure it should.. for example in c
programming i used many sin cos but not calculated d sin(x)/ dx
so i dont need it anyway in this 0..1 angle you have d sin(x)/dx = 2*pi*cos(x) so you can multiply and then you need to use this 2*pi much
more rare which seems fortunate

c coding is not exactly midlle school book mathematics

note also you have unit (0) vector...i mean vector on circle radius 1,
each amgle a desctibes one point its x,y coordinates are

cos(a), sin(a)

its derivative d/da (if a is 0..1 type) would be a tangent vector

2*PI*-sin(a), 2*PI*cos(a)

which is exactly right - becouse 2*PI is more tnan angle measura by 2*PI

if it would be in radians to be

-sin(a), cos(a)
its absolutelly artificial and idiotic

THATS A PROOF - radians suck (and should be thrown out both c and math)






--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/22/2026 4:54 AM, fir wrote:
[...]

THATS A PROOF - radians suck (and should be thrown out both c and math)

Huh? Wow. That's a bold statement. I use radians all the damn time!

How many degrees is pi / 2 ?

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 22 May 2026 15:20:08 -0700, Chris M. Thomasson wrote:

I use radians all the damn time!

Radians are the most natural units for most trig calculations.

But I have no problem with supporting different angle units. Let the
user input angles in whatever units they want, and get back answers in
whatever units they want. Internally, all angles get converted to
radians, the calculations are done, and the results converted back
again.

What annoys me just a bit is seeing these little functions like
?degrees to radians? and ?radians to degrees? -- so you need two
conversion functions (converting to and from radians) for every angle
unit you want to support.

It?s simpler to just offer a single conversion factor, which can be
used like this:

®angle-in-units-X¯ ? ®conversion-factor-for-units-X¯ ? ®angle-in-radians¯

and going the other way:

®angle-in-radians¯ ö ®conversion-factor-for-units-X¯ ? ®angle-in-units-X¯

So for example if you want angles in degrees, then the conversion
factor is ã/180; if you want to work in units of full circles, then
the conversion factor is 2ã. All nice and simple, and scalable, too.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Chris M. Thomasson pisze:

On 5/22/2026 4:54 AM, fir wrote:
[...]

THATS A PROOF - radians suck (and should be thrown out both c and math)

Huh? Wow. That's a bold statement. I use radians all the damn time!

How many degrees is pi / 2 ?

degrees are less bad but also bad so dont ask how many degress but maybe
how in this natural measure is what is "pi/2" in radians... its 0.25 as
2*pi ~ 1.0


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/23/2026 5:44 AM, fir wrote:

Chris M. Thomasson pisze:

On 5/22/2026 4:54 AM, fir wrote:
[...]

THATS A PROOF - radians suck (and should be thrown out both c and math)

Huh? Wow. That's a bold statement. I use radians all the damn time!

How many degrees is pi / 2 ?

degrees are less bad but also bad so dont ask how many degress but maybe
how in this natural measure is what is "pi/2" in radians... its 0.25 as
2*pi ~ 1.0

pi/2? Oh man, you know!

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

? 2026/5/24 14:42, Chris M. Thomasson ??:

On 5/23/2026 5:44 AM, fir wrote:

Chris M. Thomasson pisze:

On 5/22/2026 4:54 AM, fir wrote:
[...]

THATS A PROOF - radians suck (and should be thrown out both c and math) >>>

Huh? Wow. That's a bold statement. I use radians all the damn time!

How many degrees is pi / 2 ?

degrees are less bad but also bad so dont ask how many degress but maybe
how in this natural measure is what is "pi/2" in radians... its 0.25
as 2*pi ~ 1.0

pi/2? Oh man, you know!

I guess fir has a religious hatred of irrational numbers, so much that
their mind will have to twist reality when these are really needed.

By a similar logic, we should also nuke sqrt(3), exp(3) and log(3) from
C and math, because these generate a shit ton of irrational numbers.
Even Roman mathematicians from around 2,000 years ago will treat me as
a fool when I suggest this, however. (Irrational numbers are discovered
around 2,500 years ago.)

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

makendo pisze:

? 2026/5/24 14:42, Chris M. Thomasson ??:

On 5/23/2026 5:44 AM, fir wrote:

Chris M. Thomasson pisze:

On 5/22/2026 4:54 AM, fir wrote:
[...]

THATS A PROOF - radians suck (and should be thrown out both c and
math)

Huh? Wow. That's a bold statement. I use radians all the damn time!

How many degrees is pi / 2 ?

degrees are less bad but also bad so dont ask how many degress but maybe >>> how in this natural measure is what is "pi/2" in radians... its 0.25
as 2*pi ~ 1.0

pi/2? Oh man, you know!

I guess fir has a religious hatred of irrational numbers, so much that
their mind will have to twist reality when these are really needed.

By a similar logic, we should also nuke sqrt(3), exp(3) and log(3) from
C and math, because these generate a shit ton of irrational numbers.
Even Roman mathematicians from around 2,000 years ago will treat me as
a fool when I suggest this, however. (Irrational numbers are discovered around 2,500 years ago.)

you know i was recently thinking of that somewhat and i dont get any
final thoughts but i get somewhat suspicious to e

you know how transformation from r, t (where r is radius and t is angle counted in 0..1 looks like

xy = r*535.16 ^ I*t

really, check it


float complex rt2C(float r, float t)
{
return r*cpowf(535.49164f, I*t);
}

float2 rt2xy(float r, float t)
{
return (float2) {r*cosf(t*6.2831855f), r*sinf(t*6.2831855f)};
}






--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

makendo pisze:

? 2026/5/24 14:42, Chris M. Thomasson ??:

On 5/23/2026 5:44 AM, fir wrote:

Chris M. Thomasson pisze:

On 5/22/2026 4:54 AM, fir wrote:
[...]

THATS A PROOF - radians suck (and should be thrown out both c and >>>>>> math)

Huh? Wow. That's a bold statement. I use radians all the damn time!

How many degrees is pi / 2 ?

degrees are less bad but also bad so dont ask how many degress but
maybe
how in this natural measure is what is "pi/2" in radians... its 0.25
as 2*pi ~ 1.0

pi/2? Oh man, you know!

I guess fir has a religious hatred of irrational numbers, so much that
their mind will have to twist reality when these are really needed.

By a similar logic, we should also nuke sqrt(3), exp(3) and log(3) from
C and math, because these generate a shit ton of irrational numbers.
Even Roman mathematicians from around 2,000 years ago will treat me as
a fool when I suggest this, however. (Irrational numbers are discovered
around 2,500 years ago.)

you know i was recently thinking of that somewhat and i dont get any
final thoughts but i get somewhat suspicious to e

you know how transformation from r, t (where r is radius and t is angle counted in 0..1 looks like

ÿxy = r*535.16 ^ I*t

typo, should be

xy = r*535.49164 ^ I*t

really, check it

float complex rt2C(float r, float t)
{
ÿÿÿ return r*cpowf(535.49164f, I*t);
}

float2 rt2xy(float r, float t)
{
ÿreturn (float2) {r*cosf(t*6.2831855f),ÿÿÿ r*sinf(t*6.2831855f)};
}

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sun, 24 May 2026 15:57:38 +0800, makendo wrote:

(Irrational numbers are discovered around 2,500 years ago.)

The Pythagoreans were horrified by the discovery. They saw it as some
kind of defect in the perfection of mathematics, and therefore of
reality, itself.

They tried to cover it up. One story is that the mathematician
Hippasus was killed to keep him from revealing the secret.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/24/2026 3:53 PM, Lawrence D?Oliveiro wrote:

On Sun, 24 May 2026 15:57:38 +0800, makendo wrote:

(Irrational numbers are discovered around 2,500 years ago.)

The Pythagoreans were horrified by the discovery. They saw it as some
kind of defect in the perfection of mathematics, and therefore of
reality, itself.

They tried to cover it up. One story is that the mathematician
Hippasus was killed to keep him from revealing the secret.

Lol! Fwiw, this reminds of a scene in Donald Duck in Mathematics land or something...

https://youtu.be/hl6JDv4ZG7U?t=163

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Nice video. Quite interesting, the relationship between maths and music


-------- Forwarded Message --------
Subject: Re: angle type
Date: Sun, 24 May 2026 16:40:20 -0700
From: Chris M. Thomasson <chris.m.thomasson.1@gmail.com>
Organization: A noiseless patient Spider
Newsgroups: comp.lang.c
References: <10ujgr4$3oms0$1@dont-email.me>
<10ujp4k$3qmh0$1@dont-email.me> <10ujpsa$3qtbf$1@dont-email.me> <10ulmqc$e1k0$1@dont-email.me> <10unn6g$103jd$1@dont-email.me> <10uoer0$167o6$1@dont-email.me> <10upf8h$1et95$1@dont-email.me> <10upg5m$1f6sk$1@dont-email.me> <10uqkqp$1qqc3$1@dont-email.me> <10us7gd$29kbd$2@dont-email.me> <10uu6js$bg9h$1@dont-email.me> <10uub1l$cev7$1@dont-email.me> <10uvvi5$sqjl$2@dont-email.me>

On 5/24/2026 3:53 PM, Lawrence D?Oliveiro wrote:

On Sun, 24 May 2026 15:57:38 +0800, makendo wrote:

(Irrational numbers are discovered around 2,500 years ago.)

The Pythagoreans were horrified by the discovery. They saw it as some
kind of defect in the perfection of mathematics, and therefore of
reality, itself.

They tried to cover it up. One story is that the mathematician
Hippasus was killed to keep him from revealing the secret.

Lol! Fwiw, this reminds of a scene in Donald Duck in Mathematics land or something...

https://youtu.be/hl6JDv4ZG7U?t=163

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)