On 22.02.2024 20:39, Lawrence D'Oliveiro wrote:
> On Thu, 22 Feb 2024 11:09:50 +0100, David Brown wrote:
>
>> And while degrees were created by people, rather than something
>> fundamental in the mathematics, the number of divisions was picked
>> carefully for particular properties (lots of divisors).
>
> I know base-360 is supposed to have come from the Babylonians. But
> consider: you get exactly the same range of exact divisors (2, 3, 5, and
> powers and products thereof) with base-30.

Not the range of the unique divisors alone might be relevant but also
the number of duplicate divisors. As integer 30 is not dividable by 4
(which is a very common partition!), for example, but 360 is...

$ factor 360 30
360: 2 2 2 3 3 5 => 2, 3, 4, 5, 6, 8, 9, 10, 12, 15, ...
30: 2 3 5 => 2, 3, 5, 6, 10, 15

Mind that David wrote about "particular properties (lots of divisors)";
and 4 is (while not a prime) yet a [in practice very common] divisor.

Janis

On Thu, 22 Feb 2024 21:25:28 +0100, Janis Papanagnou wrote:

> Not the range of the unique divisors alone might be relevant but also
> the number of duplicate divisors. As integer 30 is not dividable by 4
> (which is a very common partition!), for example, but 360 is...

Doesn’t matter, because a fraction with a divisor that is any power of 2
is exactly representable in base-30.

On Thu, 22 Feb 2024 20:16:25 -0000 (UTC), Steven G. Kargl wrote:

> Apparently, you missed the part about argument reduction. For sinpi(x),
> it is fairly easy to reduce x = n + r with n an integer and r in [0,1).
> For the extended interval, x in [0,2^23], there are roughly 2^23 values
> with r = 0.5; and thus, sinpi(x) = 1 exactly. There are no such values
> for sin(x), and argument reduction for sin(x) is much more involved.

You are working with approximations anyway. That those approximations
happen to exactly equal some random value seems irrelevant.

> As to real-world use, how about any physical phenomena where one is
> interest in resonance frequencies of the system. For a simple example
> see https://www.feynmanlectures.caltech.edu/I_49.html where one might
> write f(x) = sin(kx) = sin(pi * (2*x/L)) with L a length of say a
> clamped string.

I don’t see a formula anything like that anywhere on that page. On the
other hand, I see lots of use of “ω” symbols, representing frequencies in
radians per second.

> There are also uses with computing other functions, e.g., the true gamma
> function via the Euler reflection formula.
>
> gamma(x) * gamma(1 - x) = pi / sin(pi * x) = pi / sinpi(x)

π radians = half a circle. Are there any other examples of the usefulness
of half-circles as an angle unit? As opposed to the dozens or hundreds of
examples of the usefulness of radians as an angle unit?

David Brown <david.brown@hesbynett.no> writes:

> On 22/02/2024 15:28, Ben Bacarisse wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> On Thu, 22 Feb 2024 00:15:47 +0100, fir wrote:
>>>
>>>> if someone knows the reason why "6.28" radians are expected to better
>>>> than "1.0" 'circkles' in both mathemathics and assembly tell me - as i
>>>> dont know the reason
>>>
>>> It’s because trig calculations are most naturally done in radians. E.g.
>>> the approximation
>>>
>>> sin x ≅ tan x ≅ x as x → 0
>>>
>>> works only if x is in radians.
>> No, that applies to lots of angle measures.
>
> The Taylor expansion of sin x near 0 is x + O(x³), as is that of tan x. So
> for any angle measure with a scale factor k (such as k = π/180 for
> degrees), the Taylor expansions for sin(kx) and tan(kx) are both k.x +
> O(x³).

Er, ok...

> Thus as x tends to 0, sin(kx) / tan(kx) tends to 1, but sin(kx)/x tends to
> k. It only tends to 1 if k is 1, i.e., we are working in radians.

.... or you could work from the fact that sin'(kx) = k cos(kx).

> I don't think that this (that sin(x)/x tends to 1 as x tends to 0) is a
> particularly good justification for using radians, however - the calculus
> argument is much better IMHO.

I think it's a very similar argument, but you hid it from yourself with
Taylor series.

--
Ben.

On Thu, 22 Feb 2024 21:04:52 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> On Thu, 22 Feb 2024 20:16:25 -0000 (UTC), Steven G. Kargl wrote:
>
> > Apparently, you missed the part about argument reduction. For
> > sinpi(x), it is fairly easy to reduce x = n + r with n an integer
> > and r in [0,1). For the extended interval, x in [0,2^23], there are
> > roughly 2^23 values with r = 0.5; and thus, sinpi(x) = 1 exactly.
> > There are no such values for sin(x), and argument reduction for
> > sin(x) is much more involved.
>
> You are working with approximations anyway. That those approximations
> happen to exactly equal some random value seems irrelevant.
>
> > As to real-world use, how about any physical phenomena where one is
> > interest in resonance frequencies of the system. For a simple
> > example see https://www.feynmanlectures.caltech.edu/I_49.html where
> > one might write f(x) = sin(kx) = sin(pi * (2*x/L)) with L a length
> > of say a clamped string.
>
> I don’t see a formula anything like that anywhere on that page. On
> the other hand, I see lots of use of “ω” symbols, representing
> frequencies in radians per second.
>
> > There are also uses with computing other functions, e.g., the true
> > gamma function via the Euler reflection formula.
> >
> > gamma(x) * gamma(1 - x) = pi / sin(pi * x) = pi / sinpi(x)
>
> π radians = half a circle. Are there any other examples of the
> usefulness of half-circles as an angle unit? As opposed to the dozens
> or hundreds of examples of the usefulness of radians as an angle unit?

In digital signal processing circle-based units are pretty much always
more natural than radians.
For specific case of 1/2 circle, I can't see where it can be used
directly.
From algorithmic perspective, full circle looks like the most obvious
choice.
From [binary floating point] numerical properties perspective, 1/8th of
the circle (==pi/4 radians = 45 degrees) is probably the best option
for a library routine, because for sin() its derivative at 0 is closest
to 1 among all powers of two which means that loss of precision
near 0 is very similar for input and for output. But this advantage
does not sound like particularly big deal.

On Thu, 22 Feb 2024 23:39:12 +0200, Michael S wrote:

> In digital signal processing circle-based units are pretty much always
> more natural than radians.

You’ll notice that my scheme makes it easy to add support for any kind of
unit you want, just by defining the appropriate multiplier constant.
You’ll see I already included CIRCLE (somebody suggested the alternative
name TURN) in my examples.

On Thu, 22 Feb 2024 21:04:52 +0000, Lawrence D'Oliveiro wrote:

> On Thu, 22 Feb 2024 20:16:25 -0000 (UTC), Steven G. Kargl wrote:
>
>> Apparently, you missed the part about argument reduction. For sinpi(x),
>> it is fairly easy to reduce x = n + r with n an integer and r in [0,1).
>> For the extended interval, x in [0,2^23], there are roughly 2^23 values
>> with r = 0.5; and thus, sinpi(x) = 1 exactly. There are no such values
>> for sin(x), and argument reduction for sin(x) is much more involved.
>
> You are working with approximations anyway. That those approximations
> happen to exactly equal some random value seems irrelevant.
>

These aren't some random values for individuals dealing
with wave propagation and resonances phenomena. Here's
a better example for you, cospi(1234.5) = 0, exactly. The
two closest single precision floating numbers that bracket
this zero are
cos(0x1.e4c96ap+11) = 1.94140221e-03f
cos(0x1.e4c97ap+11) = -1.17215250e-05f

--
steve

On Thu, 22 Feb 2024 22:09:36 -0000 (UTC), Steven G. Kargl wrote:

> On Thu, 22 Feb 2024 21:04:52 +0000, Lawrence D'Oliveiro wrote:
>
>> You are working with approximations anyway. That those approximations
>> happen to exactly equal some random value seems irrelevant.
>>
> These aren't some random values for individuals dealing with wave
> propagation and resonances phenomena. Here's a better example for you,
> cospi(1234.5) = 0, exactly. The two closest single precision floating
> numbers that bracket this zero are cos(0x1.e4c96ap+11) =
> 1.94140221e-03f cos(0x1.e4c97ap+11) = -1.17215250e-05f

Is that in binary or decimal? Remember that IEEE754 has the option for
both.

On Thu, 22 Feb 2024 22:30:19 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> On Thu, 22 Feb 2024 22:09:36 -0000 (UTC), Steven G. Kargl wrote:
>
> > On Thu, 22 Feb 2024 21:04:52 +0000, Lawrence D'Oliveiro wrote:
> >
> >> You are working with approximations anyway. That those
> >> approximations happen to exactly equal some random value seems
> >> irrelevant.
> > These aren't some random values for individuals dealing with wave
> > propagation and resonances phenomena. Here's a better example for
> > you, cospi(1234.5) = 0, exactly. The two closest single precision
> > floating numbers that bracket this zero are cos(0x1.e4c96ap+11) =
> > 1.94140221e-03f cos(0x1.e4c97ap+11) = -1.17215250e-05f
>
> Is that in binary or decimal? Remember that IEEE754 has the option
> for both.

IIRC, IEEE-754 has no option for *single precision* decimal FP.

Besides, I hope that you were trolling, you should know very well
that nobody uses DFP for science or engineering.

Michael S wrote:

> On Thu, 22 Feb 2024 21:04:52 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

>> On Thu, 22 Feb 2024 20:16:25 -0000 (UTC), Steven G. Kargl wrote:
>>
>> > Apparently, you missed the part about argument reduction. For
>> > sinpi(x), it is fairly easy to reduce x = n + r with n an integer
>> > and r in [0,1).

You are better off with r in [-½,+½]

>> For the extended interval, x in [0,2^23], there are
>> > roughly 2^23 values with r = 0.5; and thus, sinpi(x) = 1 exactly.
>> > There are no such values for sin(x), and argument reduction for
>> > sin(x) is much more involved.

I have a patent on doing argument reduction for sin(x) in 4 cycles...that
is as good as Payne-Haneok argument reduction over -infinity..+infinity
>>
>> You are working with approximations anyway. That those approximations
>> happen to exactly equal some random value seems irrelevant.
>>
>> > As to real-world use, how about any physical phenomena where one is
>> > interest in resonance frequencies of the system. For a simple
>> > example see https://www.feynmanlectures.caltech.edu/I_49.html where
>> > one might write f(x) = sin(kx) = sin(pi * (2*x/L)) with L a length
>> > of say a clamped string.
>>
>> I don’t see a formula anything like that anywhere on that page. On
>> the other hand, I see lots of use of “ω” symbols, representing
>> frequencies in radians per second.
>>
>> > There are also uses with computing other functions, e.g., the true
>> > gamma function via the Euler reflection formula.
>> >
>> > gamma(x) * gamma(1 - x) = pi / sin(pi * x) = pi / sinpi(x)

I would not have expected for the magnitude of gamma(x) * gamma(1 - x)
to be always greater than than pi....but there it is.

>>
>> π radians = half a circle. Are there any other examples of the
>> usefulness of half-circles as an angle unit? As opposed to the dozens
>> or hundreds of examples of the usefulness of radians as an angle unit?

> In digital signal processing circle-based units are pretty much always
> more natural than radians.
> For specific case of 1/2 circle, I can't see where it can be used
> directly.
> From algorithmic perspective, full circle looks like the most obvious
> choice.
> From [binary floating point] numerical properties perspective, 1/8th of
> the circle (==pi/4 radians = 45 degrees) is probably the best option
> for a library routine, because for sin() its derivative at 0 is closest
> to 1 among all powers of two which means that loss of precision
> near 0 is very similar for input and for output. But this advantage
> does not sound like particularly big deal.

I should remind that my patents include methods for calculating sin()
and cos() in 18 cycles, sinpi() and cospi() in 14 cycles while achieving
an accuracy n the 0.5002-bits of error. All of this is in HW, and all
carried out in precision wider than IEEE 754 with a bunch of HW tricks
not available to SW.

At this performance level, let the algorithms wanting pi based trigonometry
have it and those wanting unit based trigonometry have it too. Let program-
mers use what is easiest for them.

On Fri, 23 Feb 2024 00:56:02 +0200, Michael S wrote:

> Besides, I hope that you were trolling, you should know very well that
> nobody uses DFP for science or engineering.

You forget that the last “E” in “IEEE” stands for “engineering”.

On Thu, 22 Feb 2024 22:57:20 +0000, MitchAlsup1 wrote:

> Michael S wrote:
>
>> On Thu, 22 Feb 2024 21:04:52 -0000 (UTC)
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>>> On Thu, 22 Feb 2024 20:16:25 -0000 (UTC), Steven G. Kargl wrote:
>>>
>>> > Apparently, you missed the part about argument reduction. For
>>> > sinpi(x), it is fairly easy to reduce x = n + r with n an integer
>>> > and r in [0,1).
>
> You are better off with r in [-½,+½]

Partial implementation details for single precision C code (trying
to keep this on topic for c.l.c) are at
https://cgit.freebsd.org/src/tree/lib/msun/src/s_sinpif.c

One uses sinpi(-|x|) = -sinpi(|x|), which natually gets one to
r = x - floor(x) in [0,1). One then uses kernels for sin() and
cos() to do the actual computation.

r in [0,0.25) is ksin(r).
r in [0.25,0.5) is kcos(0.5-r).
r in [0.5,0.75) is kcos(r - 0.5).
r in [0.75,1) is ksin(1 - r).

>>> For the extended interval, x in [0,2^23], there are
>>> > roughly 2^23 values with r = 0.5; and thus, sinpi(x) = 1 exactly.
>>> > There are no such values for sin(x), and argument reduction for
>>> > sin(x) is much more involved.
>
> I have a patent on doing argument reduction for sin(x) in 4 cycles...that
> is as good as Payne-Haneok argument reduction over -infinity..+infinity

By a strange coincidence, I have the Payn-Hanek paper on the
top of stack of papers on my desk. Still need to internalize
the details.

(much trimmed for brevity)

>> In digital signal processing circle-based units are pretty much always
>> more natural than radians.
>> For specific case of 1/2 circle, I can't see where it can be used
>> directly.
>> From algorithmic perspective, full circle looks like the most obvious
>> choice.
>> From [binary floating point] numerical properties perspective, 1/8th of
>> the circle (==pi/4 radians = 45 degrees) is probably the best option
>> for a library routine, because for sin() its derivative at 0 is closest
>> to 1 among all powers of two which means that loss of precision
>> near 0 is very similar for input and for output. But this advantage
>> does not sound like particularly big deal.
>
> I should remind that my patents include methods for calculating sin()
> and cos() in 18 cycles, sinpi() and cospi() in 14 cycles while achieving
> an accuracy n the 0.5002-bits of error. All of this is in HW, and all
> carried out in precision wider than IEEE 754 with a bunch of HW tricks
> not available to SW.
>
> At this performance level, let the algorithms wanting pi based trigonometry
> have it and those wanting unit based trigonometry have it too. Let program-
> mers use what is easiest for them.

Agreed a programmer should use what is required by the problem
that they are solving. I'll note that SW implementations have
their sets of tricks (e.g., use of double-double arithmetic to
achieve double precision).

--
steve

On 2/22/2024 4:13 PM, Steven G. Kargl wrote:
> On Thu, 22 Feb 2024 22:57:20 +0000, MitchAlsup1 wrote:
>
>> Michael S wrote:
>>
>>> On Thu, 22 Feb 2024 21:04:52 -0000 (UTC)
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>>> On Thu, 22 Feb 2024 20:16:25 -0000 (UTC), Steven G. Kargl wrote:
>>>>
>>>>> Apparently, you missed the part about argument reduction. For
>>>>> sinpi(x), it is fairly easy to reduce x = n + r with n an integer
>>>>> and r in [0,1).
>>
>> You are better off with r in [-½,+½]
>
> Partial implementation details for single precision C code (trying
> to keep this on topic for c.l.c) are at
> https://cgit.freebsd.org/src/tree/lib/msun/src/s_sinpif.c
>
> One uses sinpi(-|x|) = -sinpi(|x|), which natually gets one to
> r = x - floor(x) in [0,1). One then uses kernels for sin() and
> cos() to do the actual computation.
>
> r in [0,0.25) is ksin(r).
> r in [0.25,0.5) is kcos(0.5-r).
> r in [0.5,0.75) is kcos(r - 0.5).
> r in [0.75,1) is ksin(1 - r).
>
>>>> For the extended interval, x in [0,2^23], there are
>>>>> roughly 2^23 values with r = 0.5; and thus, sinpi(x) = 1 exactly.
>>>>> There are no such values for sin(x), and argument reduction for
>>>>> sin(x) is much more involved.
>>
>> I have a patent on doing argument reduction for sin(x) in 4 cycles...that
>> is as good as Payne-Haneok argument reduction over -infinity..+infinity
>
> By a strange coincidence, I have the Payn-Hanek paper on the
> top of stack of papers on my desk. Still need to internalize
> the details.
>
> (much trimmed for brevity)
>
>
>>> In digital signal processing circle-based units are pretty much always
>>> more natural than radians.
>>> For specific case of 1/2 circle, I can't see where it can be used
>>> directly.
>>> From algorithmic perspective, full circle looks like the most obvious
>>> choice.
>>> From [binary floating point] numerical properties perspective, 1/8th of
>>> the circle (==pi/4 radians = 45 degrees) is probably the best option
>>> for a library routine, because for sin() its derivative at 0 is closest
>>> to 1 among all powers of two which means that loss of precision
>>> near 0 is very similar for input and for output. But this advantage
>>> does not sound like particularly big deal.
>>
>> I should remind that my patents include methods for calculating sin()
>> and cos() in 18 cycles, sinpi() and cospi() in 14 cycles while achieving
>> an accuracy n the 0.5002-bits of error. All of this is in HW, and all
>> carried out in precision wider than IEEE 754 with a bunch of HW tricks
>> not available to SW.
>>
>> At this performance level, let the algorithms wanting pi based trigonometry
>> have it and those wanting unit based trigonometry have it too. Let program-
>> mers use what is easiest for them.
>
> Agreed a programmer should use what is required by the problem
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Indeed! :^)

> that they are solving. I'll note that SW implementations have
> their sets of tricks (e.g., use of double-double arithmetic to
> achieve double precision).
>

Use some form of arbitrary precision if you want to get to:

A 10^4141 zoom mset zoom!? It must took many hours to render... ;^)

https://youtu.be/Xjy_HSUujaw

On 2/22/2024 4:49 PM, Chris M. Thomasson wrote:
[...]> Use some form of arbitrary precision if you want to get to:
>
> A 10^4141 zoom mset zoom!? It must took many hours to render... ;^)
>
> https://youtu.be/Xjy_HSUujaw

A 10^275 zoom:

https://youtu.be/0jGaio87u3A

David Brown wrote:

> On 22/02/2024 16:29, Blue-Maned_Hawk wrote:
>> David Brown wrote:
>>
>>> On 22/02/2024 09:27, Blue-Maned_Hawk wrote:
>>>>
>>>> Radians is the only angle unit which is not arbitrary.
>>>>
>>>>
>>>>
>>> No, it is not. "Turns" are also not arbitrary, and are also
>>> mathematically fundamental.
>>
>> That is a good point that i had not thought about. Thank you.
>>
>>> And while degrees were created by people, rather than something
>>> fundamental in the mathematics, the number of divisions was picked
>>> carefully for particular properties (lots of divisors). And since
>>> degrees are a well-established and commonly known angle unit, using
>>> them is not arbitrary. Even gradians were defined that way for good
>>> reasons.
>>> So these units are not arbitrary - even though they were defined by
>>> humans and not mathematics.
>>
>> I do not see how this is not still completely arbitrary.
>>
>>
> "Arbitrary" means that you picked something without any particular
> reason, and could just as well have picked something else. We use base
> ten - that is not arbitrary, it is based on the number of fingers we
> have. The Babylonians and Sumerians liked 5, 12 and 60 - also not
> arbitrary, but picked as numbers with a lot of convenient factors. The
> French revolutionists picked 400 for gradians, because 100 parts in a
> right angle fit well with their new metric system, which fit well with
> our standard number base. And one gradian of arc on a map corresponds
> almost exactly to 100 km in distance - also very intentional, and not
> arbitrary.
>
> From a purely mathematical viewpoint, these units are arbitrary - but
> from a human and historical viewpoint, they are not.

Then in that case, it sounds like they are either irrationally natural-
human-centric or irrationally steeped in tradition.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
Tradition is the reason for doing something there's no longer any good
reason for doing.

On Thu, 22 Feb 2024 20:02:30 +0100, David Brown wrote:

> The French revolutionists picked 400 for gradians, because 100 parts in
> a right angle fit well with their new metric system, which fit well with
> our standard number base.

I wondered where they came from. But that reinforces my point, that
supporting even little-known units like these are very easy with my
scheme, requiring only the definition of a single conversion factor.

Steven G. Kargl wrote:

> On Thu, 22 Feb 2024 22:57:20 +0000, MitchAlsup1 wrote:

>> Michael S wrote:
>>
>>> On Thu, 22 Feb 2024 21:04:52 -0000 (UTC)
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>>> On Thu, 22 Feb 2024 20:16:25 -0000 (UTC), Steven G. Kargl wrote:
>>>>
>>>> > Apparently, you missed the part about argument reduction. For
>>>> > sinpi(x), it is fairly easy to reduce x = n + r with n an integer
>>>> > and r in [0,1).
>>
>> You are better off with r in [-½,+½]

> Partial implementation details for single precision C code (trying
> to keep this on topic for c.l.c) are at
> https://cgit.freebsd.org/src/tree/lib/msun/src/s_sinpif.c

> One uses sinpi(-|x|) = -sinpi(|x|), which natually gets one to
> r = x - floor(x) in [0,1). One then uses kernels for sin() and
> cos() to do the actual computation.

> r in [0,0.25) is ksin(r).
> r in [0.25,0.5) is kcos(0.5-r).
> r in [0.5,0.75) is kcos(r - 0.5).
> r in [0.75,1) is ksin(1 - r).

By "better off" I mean you have ½-bit of greater reduced argument precision
when the reduced argument is centered on zero.

>>>> For the extended interval, x in [0,2^23], there are
>>>> > roughly 2^23 values with r = 0.5; and thus, sinpi(x) = 1 exactly.
>>>> > There are no such values for sin(x), and argument reduction for
>>>> > sin(x) is much more involved.
>>
>> I have a patent on doing argument reduction for sin(x) in 4 cycles...that
>> is as good as Payne-Haneok argument reduction over -infinity..+infinity

> By a strange coincidence, I have the Payn-Hanek paper on the
> top of stack of papers on my desk. Still need to internalize
> the details.

Here is the version found in the SUN transcendentals::

static void ReduceFull(double *xp, int *a, double x)
{ Double X = { x };
int ec = X.s.exponent - (1023+33);
int k = (ec + 26) * (607*4) >> 16;
int m = 27*k - ec;
int offset = m >> 3;
x *= 0x1p-400;
double xDekker = x * (0x1p27 + 1);
double x0 = xDekker - (xDekker - x);
double x1 = x - x0;
const double *p0 = &TwoOverPiWithOffset[offset][k]; // 180 DP FP numbers
const double fp0 = p0[0];
const double fp1 = p0[1];
const double fp2 = p0[2];
const double fp3 = p0[3];
const double f0 = x1 * fp0 + fp1 * x0;
double f = x1 * fp1 + fp2 * x0;
const double fi = f0 + f;
static const double IntegerBias = 0x1.8p52;
Double Fi = { fi + IntegerBias };
*a = Fi.s.significand2;
double fint = Fi.d - IntegerBias;
const double fp4 = p0[4];
const double fp5 = p0[5];
const double fp6 = p0[6];
f = f0 - fint + f;
f += x1 * fp2 + fp3 * x0;
f += x1 * fp3 + fp4 * x0;
f += x1 * fp4 + fp5 * x0;
f += x1 * fp5 + fp6 * x0;
*xp = f * 0x3.243F6A8885A3p-1;
}

Which I can do in 4 cycles in HW !! {{I happen to have this on hand to explain how
I can do this in HW in 4 cycles......}}

I should also note that the conversion of f back into *xp looses ¼-bit of precision.

> (much trimmed for brevity)

>>> In digital signal processing circle-based units are pretty much always
>>> more natural than radians.
>>> For specific case of 1/2 circle, I can't see where it can be used
>>> directly.
>>> From algorithmic perspective, full circle looks like the most obvious
>>> choice.
>>> From [binary floating point] numerical properties perspective, 1/8th of
>>> the circle (==pi/4 radians = 45 degrees) is probably the best option
>>> for a library routine, because for sin() its derivative at 0 is closest
>>> to 1 among all powers of two which means that loss of precision
>>> near 0 is very similar for input and for output. But this advantage
>>> does not sound like particularly big deal.
>>
>> I should remind that my patents include methods for calculating sin()
>> and cos() in 18 cycles, sinpi() and cospi() in 14 cycles while achieving
>> an accuracy n the 0.5002-bits of error. All of this is in HW, and all
>> carried out in precision wider than IEEE 754 with a bunch of HW tricks
>> not available to SW.
>>
>> At this performance level, let the algorithms wanting pi based trigonometry
>> have it and those wanting unit based trigonometry have it too. Let program-
>> mers use what is easiest for them.

> Agreed a programmer should use what is required by the problem
> that they are solving. I'll note that SW implementations have
> their sets of tricks (e.g., use of double-double arithmetic to
> achieve double precision).

To get near IEEE desired precision, one HAS TO use more than 754 precision.

Chris M. Thomasson wrote:

> On 2/22/2024 4:49 PM, Chris M. Thomasson wrote:
> [...]> Use some form of arbitrary precision if you want to get to:
>>
>> A 10^4141 zoom mset zoom!? It must took many hours to render... ;^)
>>
>> https://youtu.be/Xjy_HSUujaw

> A 10^275 zoom:

> https://youtu.be/0jGaio87u3A

Argument reduction zoom::

COS( 6381956970095103×2^797) = -4.68716592425462761112×10-19

You can argue all you want about whether this has any significance, but
it happens to be the value closest to that radian argument when performed
with infinite precision.

On 22/02/2024 22:30, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 22/02/2024 15:28, Ben Bacarisse wrote:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>>> On Thu, 22 Feb 2024 00:15:47 +0100, fir wrote:
>>>>
>>>>> if someone knows the reason why "6.28" radians are expected to better
>>>>> than "1.0" 'circkles' in both mathemathics and assembly tell me - as i
>>>>> dont know the reason
>>>>
>>>> It’s because trig calculations are most naturally done in radians. E.g.
>>>> the approximation
>>>>
>>>> sin x ≅ tan x ≅ x as x → 0
>>>>
>>>> works only if x is in radians.
>>> No, that applies to lots of angle measures.
>>
>> The Taylor expansion of sin x near 0 is x + O(x³), as is that of tan x. So
>> for any angle measure with a scale factor k (such as k = π/180 for
>> degrees), the Taylor expansions for sin(kx) and tan(kx) are both k.x +
>> O(x³).
>
> Er, ok...
>
>> Thus as x tends to 0, sin(kx) / tan(kx) tends to 1, but sin(kx)/x tends to
>> k. It only tends to 1 if k is 1, i.e., we are working in radians.
>
> ... or you could work from the fact that sin'(kx) = k cos(kx).
>
>> I don't think that this (that sin(x)/x tends to 1 as x tends to 0) is a
>> particularly good justification for using radians, however - the calculus
>> argument is much better IMHO.
>
> I think it's a very similar argument, but you hid it from yourself with
> Taylor series.
>

There are many ways to see these things. Personally I think it's quite
clear and easy to understand that if you have a polynomial (finite or
infinite and converging), then its behaviour as you approach zero will
be that of the lowest order terms. But I really can't say what might be
the simplest viewpoint for others.

On 23/02/2024 03:24, Lawrence D'Oliveiro wrote:
> On Thu, 22 Feb 2024 20:02:30 +0100, David Brown wrote:
>
>> The French revolutionists picked 400 for gradians, because 100 parts in
>> a right angle fit well with their new metric system, which fit well with
>> our standard number base.
>
> I wondered where they came from. But that reinforces my point, that
> supporting even little-known units like these are very easy with my
> scheme, requiring only the definition of a single conversion factor.

I agree with your approach - with the proviso that implementations that
are specialised for a particular angle measurement might be more
efficient, more accurate, or have greater range than simply scaling the
argument to radians and using radian-based trig functions. Numerical
floating point calculations on finite systems do not quite follow the
simple rules of real number mathematics, unfortunately.

But your approach (which is what most people use if they want trig in
degrees) gives a lot of flexibility for very little cost.

On 22/02/2024 21:58, Lawrence D'Oliveiro wrote:
> On Thu, 22 Feb 2024 21:25:28 +0100, Janis Papanagnou wrote:
>
>> Not the range of the unique divisors alone might be relevant but also
>> the number of duplicate divisors. As integer 30 is not dividable by 4
>> (which is a very common partition!), for example, but 360 is...
>
> Doesn’t matter, because a fraction with a divisor that is any power of 2
> is exactly representable in base-30.

That's true, but the Sumerians and Babylonians did not have decimal (or
rather trigesimal for base 30 - or sexagesimal for base 60) points. I
don't think they made much use of fractions at all, but moved on to
smaller units (dividing a degree into 60 minutes, and minutes into 60
seconds). That kept everything in integers.

It's not just the Babylonians that prefer integers - so does everyone
else. Would you rather that right-angled isosceles triangles had 45°
angles, or 3.75° angles?

Michael S wrote:
> On Thu, 22 Feb 2024 21:04:52 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>> π radians = half a circle. Are there any other examples of the
>> usefulness of half-circles as an angle unit? As opposed to the dozens
>> or hundreds of examples of the usefulness of radians as an angle unit?
>
> In digital signal processing circle-based units are pretty much always
> more natural than radians.
> For specific case of 1/2 circle, I can't see where it can be used
> directly.
> From algorithmic perspective, full circle looks like the most obvious
> choice.
> From [binary floating point] numerical properties perspective, 1/8th of
> the circle (==pi/4 radians = 45 degrees) is probably the best option
> for a library routine, because for sin() its derivative at 0 is closest
> to 1 among all powers of two which means that loss of precision
> near 0 is very similar for input and for output. But this advantage
> does not sound like particularly big deal.

ieee754 defines sinpi() and siblings, but imho it really doesn't matter
if you use circles, half-circles (i.e. sinpi) or some other binary
fraction of a circle: Argument reduction for huge inputs are just as
easy, you might just have to multiply by the corresponding power of two
(i.e. adjust the exponent) before extracting the fractional term.

For sinpi(x) I could do it like this:

if (abs(x) >= two_to_52nd_power) error("Zero significant bits.");
ix = int(x);
x_reduced = x - (double) (ix & ~1);
if (x_reduced < 0.0) x_reduced += 2.0;

but it is probably better to return a value in the [-1.0 .. 1.0> range?

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

MitchAlsup1 wrote:
> Steven G. Kargl wrote:
>> Agreed a programmer should use what is required by the problem
>> that they are solving.  I'll note that SW implementations have
>> their sets of tricks (e.g., use of double-double arithmetic to
>> achieve double precision).
>
> To get near IEEE desired precision, one HAS TO use more than 754 precision.

There are groups who have shown that exactly rounded trancendental
functions are in fact achievable with maybe 3X reduced performance.

There is a suggestion on the table to make that a (probably optional
imho) feature for an upcoming ieee754 revision.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 23.02.2024 09:33, David Brown wrote:
> On 22/02/2024 21:58, Lawrence D'Oliveiro wrote:
>> On Thu, 22 Feb 2024 21:25:28 +0100, Janis Papanagnou wrote:
>>
>>> Not the range of the unique divisors alone might be relevant but also
>>> the number of duplicate divisors. As integer 30 is not dividable by 4
>>> (which is a very common partition!), for example, but 360 is...
>>
>> Doesn’t matter, because a fraction with a divisor that is any power of 2
>> is exactly representable in base-30.

I don't understand what you mean by "exactly representable", where
the analogon of the numeric e.g. "7.5" is concerned. (I thought we
were talking about the origins, how the choice of 360 came about.)

>
> That's true, but the Sumerians and Babylonians did not have decimal (or
> rather trigesimal for base 30 - or sexagesimal for base 60) points. I
> don't think they made much use of fractions at all, but moved on to
> smaller units (dividing a degree into 60 minutes, and minutes into 60
> seconds). That kept everything in integers.
>
> It's not just the Babylonians that prefer integers - so does everyone
> else. Would you rather that right-angled isosceles triangles had 45°
> angles, or 3.75° angles?
>

The old Greeks certainly didn't have a concept of fractional numbers;
fractions appeared as geometrical partitions (cf. e.g. the problem
of angle trisections); they handled mathematical and physical problems
by geometry (and by integral counting for the more mundane things).

Janis

On Fri, 23 Feb 2024 00:13:02 -0000 (UTC)
"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> wrote:

> On Thu, 22 Feb 2024 22:57:20 +0000, MitchAlsup1 wrote:
>
> >
> > I have a patent on doing argument reduction for sin(x) in 4
> > cycles...that is as good as Payne-Haneok argument reduction over
> > -infinity..+infinity
>
> By a strange coincidence, I have the Payn-Hanek paper on the
> top of stack of papers on my desk. Still need to internalize
> the details.
>

Payne-Hanek is a right answer to a wrong question.
In science/engineering floating-point number x represents a range
[x-ULP:x+ULP] with hopefully much higher probability of being in range
[x-ULP/2:x+ULP/2]. However in this reduced range probability is flat,
an "exact" x is no worse and no better than any other point within this
range.
Which means that when we look for y=sin(x) then for
scientific/engineering purposes any answer in range*
[sin(x-ULP/2):sin(x+ULP/2)] is as "right" as any other answer. The
right answer to the question "What is a sin() of IEEE-754 binary64
number 1e17?" is "Anything in range [-1:1]". The wise and useful answer
to the same question is "You're holding it wrong".

* in paragraph Sin(x) designates result calculated with infinite
precision.