On Sun, 25 Feb 2024 23:09:10 +0000, bart wrote:

> 30 can't be evenly divided by 4, 8, 9, 12, 18 or 20 for a start.

Those fractions can be exactly represented in base-30.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sun, 25 Feb 2024 22:29:41 +0000, Ben Bacarisse wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> On Sun, 25 Feb 2024 13:08:53 +0000, Richard Harnden wrote:
>>>> It's 360 because it divides by {lots}, nothing to do with days in a
>>>> year.
>>>
>>> And you can get all those same divisors with 30.
>>
>> You are confusing unique prime factors with divisors.
>
> No, I’m not. Once you have one occurrence of a prime factor, you get the
> ability to exactly represent fractions involving all powers of that
> factor, and all products of that factor with other factors.

It would have saved some time if you had said that in the first place,
rather than claiming that "you can get all those same divisors with 30".

I suppose that you meant that 1/N where N is a divisor of 360 can be
represented in base 30 without repeating. But the obvious meaning of
what you wrote was that all divisors of 360 are divisors of 30, and I'm
not the only one who thought so.

Either way, I'm not sure why you thought it was a point worth making.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 26/02/2024 21:32, Lawrence D'Oliveiro wrote:
> On Sun, 25 Feb 2024 23:09:10 +0000, bart wrote:
>
>> 30 can't be evenly divided by 4, 8, 9, 12, 18 or 20 for a start.
>
> Those fractions can be exactly represented in base-30.

I've no idea how that would work, or how it would be anything other than
100 times harder and more impractical than just using radians instead of
degrees.

On Mon, 26 Feb 2024 13:44:45 -0800, Keith Thompson wrote:

> It would have saved some time if you had said that in the first place,
> rather than claiming that "you can get all those same divisors with 30".

Why, what else could you possibly have thought I meant? Dividing by things
is precisely what fractions are all about.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Mon, 26 Feb 2024 13:44:45 -0800, Keith Thompson wrote:
>> It would have saved some time if you had said that in the first place,
>> rather than claiming that "you can get all those same divisors with 30".
>
> Why, what else could you possibly have thought I meant? Dividing by things
> is precisely what fractions are all about.

I took your statement that "you can get all those same divisors with 30"
to mean that you thought that 30 has all the same divisors that 360 has.
It's obvious that, for example, 180 is a divisor of 360 and not of 30,
but I thought you might have thought that all the divisors of 360 up to
30 are also divisors of 30, which is also wrong but not quite as
obviously so.

You've now clarified that that's not what you meant, but I'm just one of
several people who interpreted your original statement the same way I
did. Given that, consider the possibility that your statement was not
as clear as you thought it was.

Since it wasn't an important or relevant point in the first place, I'm
going to drop it, and I suggest you do the same. Nobody is going to
start using base 30 anyway.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Mon, 26 Feb 2024 16:02:17 -0800, Keith Thompson wrote:

> Since it wasn't an important or relevant point in the first place, I'm
> going to drop it, and I suggest you do the same.

You seem to do that a lot.

On 27/02/2024 00:15, Lawrence D'Oliveiro wrote:
> On Mon, 26 Feb 2024 13:44:45 -0800, Keith Thompson wrote:
>
>> It would have saved some time if you had said that in the first place,
>> rather than claiming that "you can get all those same divisors with 30".
>
> Why, what else could you possibly have thought I meant? Dividing by things
> is precisely what fractions are all about.

I, for one, thought you were mistaken and confused. It seemed to be the
more logical explanation (and less unkind than assuming you are trolling
or intentionally trying to cause confusion), since everyone else was
clearly talking about divisors as the term is used in mathematics. The
"divisors" of an integer "N" are integers that divide wholly into N. 4
is a divisor of 360, but it is not a divisor of 30. It is /that/ simple.

No one is particularly interested in decimals here, much less interested
in some kind of base 30 decimal (which is what you need to make your
claims correct). And the context was historical - why the Babylonians
and Sumerians had 360 degrees in a circle. They did not have radix
points of any kind.

On 27/02/2024 00:01, bart wrote:
> On 26/02/2024 21:32, Lawrence D'Oliveiro wrote:
>> On Sun, 25 Feb 2024 23:09:10 +0000, bart wrote:
>>
>>> 30 can't be evenly divided by 4, 8, 9, 12, 18 or 20 for a start.
>>
>> Those fractions can be exactly represented in base-30.
>
> I've no idea how that would work, or how it would be anything other than
> 100 times harder and more impractical than just using radians instead of
> degrees.

I know exactly how it would work, but you are absolutely correct that it
would be harder and far less practical than using 360 degrees, and
without the mathematical features of radians.

On Fri, 23 Feb 2024 11:10:00 +0100
Terje Mathisen <terje.mathisen@tmsw.no> wrote:

> 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.
>

At which cost in tables sizes?

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

The critical point here is definition of what considered exact. If
'exact' is measured only on y side of y=foo(x), disregarding
possible imprecision on the x side then you are very likely to end up
with results that are slower to calculate, but not at all more useful
from point of view of engineer or physicist. Exactly like Payne-Hanek
or Mitch's equivalent of Payne-Hanek.

The definition of 'exact' should be:
For any finite-precision function foo(x) lets designate the same
mathematical function calculated with infinite precision as Foo(x).
Let's designate an operation of rounding of infinite-precision number to
desired finite precision as Rnd(). Rounding is done in to-nearest mode.
Unlike in the case of basic operations, ties are allowed to be broken in
any direction.
The result of y=foo(x) for finite-precision number x considered
exact if *at least one* two conditions is true:
(1=Y-clause) Rnd(Foo(x)) == y
(2=X-clause) There exist an infinite precision number X for which
both Foo(X) == y and Rnd(X) == x.

As follows from the (2), it is possible and not uncommon that more
than one finite-precision number y is accepted exact result of foo(x).

If Committee omits the 2nd clause then the whole proposition will be not
just not useful, but harmful.

Steven G. Kargl wrote:

> sin(x) is not sinpi(x). The conversion factor that you're missing
> is M_PI as in sinpi(x) = sin(M_PI*x).

When I faced this kind of accuracy/precision problem in my HW transcendentals,

To get a sufficiently correct reduced argument I had to multiply the fraction
of x by a 2/pi number selected such that the HoB was aligned to 2 (quadrant)
and the multiplied result had 51+53 bits of precision so that up to 51 leading
bits of the reduced argument (after the quadrant bits) could be skipped if 0.
This required 3 uses of the multiplier tree one produced the leading bits::

Lead bits |/
Middle bits / /
trail bits /|

which were arranged |/ /| into a single 104 bit (minimum) product. My current
implementation uses 128 bits. And my polynomial evaluation uses 58-bit argu-
ments (min, 64-bit current) at each iteration. And I still only get 0.502
(58-bit:: 0.5002 64-bit) precision.

Payne and Hanek argument reduction--because it does not have access to the
intermediate bits, needs 4 multiplies instead of 2 and very careful arithmetic
to preserve accuracy. I can do this in 2 trips through the multiplier array
(patented)

So, I used 159-bits of 2/pi in 2 multiplies over 2 trips through the array
and get perfect argument (DP) reduction in 4 cycles. Payne ad Hanek use 256-
bits of DP FP operands and 30+ instruction to do the same thing.

My multiplier tree is cut into 2 sections (just like one would do for dual SP)
but here I feed the top 2/pi bits into the left hand side and the bottom 2/pi
bits into the right hand side so both get computed simultaneously; the subsequent
cycle multiplies by the middle bits of 2/pi. The 2/pi table is indexed by exponent.

Michael S wrote:

> On Fri, 23 Feb 2024 11:10:00 +0100
> Terje Mathisen <terje.mathisen@tmsw.no> wrote:

>> 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.
>>

> At which cost in tables sizes?

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

> The critical point here is definition of what considered exact. If
> 'exact' is measured only on y side of y=foo(x), disregarding
> possible imprecision on the x side then you are very likely to end up
> with results that are slower to calculate, but not at all more useful
> from point of view of engineer or physicist. Exactly like Payne-Hanek
> or Mitch's equivalent of Payne-Hanek.

> The definition of 'exact' should be:
> For any finite-precision function foo(x) lets designate the same
> mathematical function calculated with infinite precision as Foo(x).
> Let's designate an operation of rounding of infinite-precision number to
> desired finite precision as Rnd(). Rounding is done in to-nearest mode.
> Unlike in the case of basic operations, ties are allowed to be broken in
> any direction.
> The result of y=foo(x) for finite-precision number x considered
> exact if *at least one* two conditions is true:
> (1=Y-clause) Rnd(Foo(x)) == y
> (2=X-clause) There exist an infinite precision number X for which
> both Foo(X) == y and Rnd(X) == x.

In the second clause:: are we guaranteed that RND(Foo(X))= Y ??

> As follows from the (2), it is possible and not uncommon that more
> than one finite-precision number y is accepted exact result of foo(x).

> If Committee omits the 2nd clause then the whole proposition will be not
> just not useful, but harmful.

An interesting side effect of greater intermediate precision is the lack
of need to round prior to the final result. Thus, my sin(x) over its
entire calculation suffers exactly 1 rounding. Payne & Hanek does not
have this prperty.

And thirdly::

Let us postulate that the reduced argument r is indeed calculated with 0.5ULP
error.

What makes you think you can calculate the polynomial without introducing
any more error ??

On Thu, 14 Mar 2024 17:34:57 +0000, MitchAlsup1 wrote:

> Michael S wrote:
>
>> (2=X-clause) There exist an infinite precision number X for which
>> both Foo(X) == y and Rnd(X) == x.
>
> In the second clause:: are we guaranteed that RND(Foo(X))= Y ??

No idea why that’s relevant. Michael S was talking about “Rnd”, not “RND”.

When you say “RND”, I think of a bad random-number generator found in
various implementations of BASIC.

On 3/14/2024 1:30 PM, Lawrence D'Oliveiro wrote:
> On Thu, 14 Mar 2024 17:34:57 +0000, MitchAlsup1 wrote:
>
>> Michael S wrote:
>>
>>> (2=X-clause) There exist an infinite precision number X for which
>>> both Foo(X) == y and Rnd(X) == x.
>>
>> In the second clause:: are we guaranteed that RND(Foo(X))= Y ??
>
> No idea why that’s relevant. Michael S was talking about “Rnd”, not “RND”.
>
> When you say “RND”, I think of a bad random-number generator found in
> various implementations of BASIC.

PRNG, an LGC? Fwiw, check this shit out:

https://groups.google.com/g/comp.lang.c++/c/7u_rLgQe86k/m/fYU9SnuAFQAJ

;^D

Lawrence D'Oliveiro wrote:

> On Thu, 14 Mar 2024 17:34:57 +0000, MitchAlsup1 wrote:

>> Michael S wrote:
>>
>>> (2=X-clause) There exist an infinite precision number X for which
>>> both Foo(X) == y and Rnd(X) == x.
>>
>> In the second clause:: are we guaranteed that RND(Foo(X))= Y ??

> No idea why that’s relevant. Michael S was talking about “Rnd”, not “RND”.

You have just selected yourself as someone I will never reply to again.

> When you say “RND”, I think of a bad random-number generator found in
> various implementations of BASIC.

On 3/14/2024 3:19 PM, MitchAlsup1 wrote:
> Lawrence D'Oliveiro wrote:
>
>> On Thu, 14 Mar 2024 17:34:57 +0000, MitchAlsup1 wrote:
>
>>> Michael S wrote:
>>>
>>>> (2=X-clause) There exist an infinite precision number X for which
>>>> both Foo(X) == y and Rnd(X) == x.
>>>
>>> In the second clause:: are we guaranteed that RND(Foo(X))= Y ??
>
>> No idea why that’s relevant. Michael S was talking about “Rnd”, not
>> “RND”.
>
> You have just selected yourself as someone I will never reply to again.

It might be an AI? Just have a very strange feeling... Humm...

>
>> When you say “RND”, I think of a bad random-number generator found in
>> various implementations of BASIC.

On 3/14/2024 3:21 PM, Chris M. Thomasson wrote:
> On 3/14/2024 3:19 PM, MitchAlsup1 wrote:
[...]

An AI set on ass mode?

Michael, I for the main part agree with you here, i.e. calculating
sin(x) with x larger than 2^53 or so, is almost certainly stupid.

Actually using and depending upon the result is more stupid.

OTOH, it is and have always been, a core principle of ieee754 that basic
operations (FADD/FSUB/FMUL/FDIV/FSQRT) shall assume that the inputs are
exact (no fractional ulp uncertainty), and that we from that starting
point must deliver a correctly rounded version of the infinitely precise
exact result of the operation.

Given the latter, it is in fact very tempting to see if that basic
result rule could be applied to more of the non-core operations, but I
cannot foresee any situation where I would use it myself: If I find
myself in a situation where the final fractional ulp is important, then
I would far rather switch to doing the operation in fp128.

Terje

Michael S wrote:
> On Fri, 23 Feb 2024 11:10:00 +0100
> Terje Mathisen <terje.mathisen@tmsw.no> wrote:
>
>> 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.
>>
>
> At which cost in tables sizes?
>
>
>> There is a suggestion on the table to make that a (probably optional
>> imho) feature for an upcoming ieee754 revision.
>>
>> Terje
>>
>
> The critical point here is definition of what considered exact. If
> 'exact' is measured only on y side of y=foo(x), disregarding
> possible imprecision on the x side then you are very likely to end up
> with results that are slower to calculate, but not at all more useful
> from point of view of engineer or physicist. Exactly like Payne-Hanek
> or Mitch's equivalent of Payne-Hanek.
>
> The definition of 'exact' should be:
> For any finite-precision function foo(x) lets designate the same
> mathematical function calculated with infinite precision as Foo(x).
> Let's designate an operation of rounding of infinite-precision number to
> desired finite precision as Rnd(). Rounding is done in to-nearest mode.
> Unlike in the case of basic operations, ties are allowed to be broken in
> any direction.
> The result of y=foo(x) for finite-precision number x considered
> exact if *at least one* two conditions is true:
> (1=Y-clause) Rnd(Foo(x)) == y
> (2=X-clause) There exist an infinite precision number X for which
> both Foo(X) == y and Rnd(X) == x.
>
> As follows from the (2), it is possible and not uncommon that more
> than one finite-precision number y is accepted exact result of foo(x).
>
> If Committee omits the 2nd clause then the whole proposition will be not
> just not useful, but harmful.
>

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

MitchAlsup1 wrote:
> And thirdly::
>
> Let us postulate that the reduced argument r is indeed calculated with
> 0.5ULP
> error.
>
> What makes you think you can calculate the polynomial without introducing
> any more error ??

It should be obvious that any argument reduction step must return a
value with significantly higher precision than the input(s), and that
this higher precision value is then used in any polynomial evaluation.

With careful setup, it is very often possible to reduce the amount of
extended-procision work needed to just one or two steps, i.e. for the
classic Taylor sin(x) series, with x fairly small, the x^3 and higher
terms can make do with double precision, so that the final step is to
add the two parts of the leading x term: First the trailing part and
then when adding the upper 53 bits of x you get a single rounding at
this stage.

This is easier and better when done with 64-bit fixed-point values,
augemented with a few 128-bit operations.

Terje

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

On Thu, 14 Mar 2024 17:34:57 +0000
mitchalsup@aol.com (MitchAlsup1) wrote:

> Michael S wrote:
>
> > (2=X-clause) There exist an infinite precision number X for which
> > both Foo(X) == y and Rnd(X) == x.
>
> In the second clause:: are we guaranteed that RND(Foo(X))= Y ??
>

No, we are not.

> > As follows from the (2), it is possible and not uncommon that more
> > than one finite-precision number y is accepted exact result of
> > foo(x).
>
> > If Committee omits the 2nd clause then the whole proposition will
> > be not just not useful, but harmful.
>
> An interesting side effect of greater intermediate precision is the
> lack of need to round prior to the final result. Thus, my sin(x) over
> its entire calculation suffers exactly 1 rounding. Payne & Hanek does
> not have this prperty.

Which does not help to recover precision lost during rounding of x
that happened before your wonderful instruction.

On Fri, 15 Mar 2024 11:23:45 +0100
Terje Mathisen <terje.mathisen@tmsw.no> wrote:

> Michael, I for the main part agree with you here, i.e. calculating
> sin(x) with x larger than 2^53 or so, is almost certainly stupid.
>
> Actually using and depending upon the result is more stupid.
>
> OTOH, it is and have always been, a core principle of ieee754 that
> basic operations (FADD/FSUB/FMUL/FDIV/FSQRT) shall assume that the
> inputs are exact (no fractional ulp uncertainty), and that we from
> that starting point must deliver a correctly rounded version of the
> infinitely precise exact result of the operation.
>
> Given the latter, it is in fact very tempting to see if that basic
> result rule could be applied to more of the non-core operations, but
> I cannot foresee any situation where I would use it myself: If I find
> myself in a situation where the final fractional ulp is important,
> then I would far rather switch to doing the operation in fp128.
>
> Terje
>

To make it less tempting, you could try to push for inclusion of
rsqrt() into basic set. Long overdue, IMHO.

Right now, I can't think of any other transcendental that I really want
to elevate to higher status. It seems to me that elevation of log2(x)
and of 2**x will do no harm, but I am not sure about usefulness.

On 3/15/2024 3:23 AM, Terje Mathisen wrote:
> Michael, I for the main part agree with you here, i.e. calculating
> sin(x) with x larger than 2^53 or so, is almost certainly stupid.
[...]

;^D tooooooo big. :^)

Now, wrt the results, arbitrary precision for trig is useful, in say...
Deep fractal zooms...

Zooming in really deep in say something like this, well the precision of
trig can become an issue:

https://paulbourke.net/fractals/multijulia/

Trig would be used, say, in rectangular to-from polar forms wrt getting
the n-ary roots of a complex number?

On 3/15/2024 1:59 PM, Chris M. Thomasson wrote:
> On 3/15/2024 3:23 AM, Terje Mathisen wrote:
>> Michael, I for the main part agree with you here, i.e. calculating
>> sin(x) with x larger than 2^53 or so, is almost certainly stupid.
> [...]
>
> ;^D tooooooo big. :^)
>
> Now, wrt the results, arbitrary precision for trig is useful, in say...
> Deep fractal zooms...

Say I want at least 30 digits of precision for a certain calculation of
complex numbers at a certain zoom level. Along the lines of trying to
match convergents of continued fractions, take pi:

3.1415926535897932384...

two digits of decimal precision:

22/7 = 3.14_28571428571428571428571428571

three digits of decimal precision:

333/106 = 3.1415_094339622641509433962264151

six digits of decimal precision:

355/113 = 3.141592_9203539823008849557522124

On and on...

Well...

>
> Zooming in really deep in say something like this, well the precision of
> trig can become an issue:
>
> https://paulbourke.net/fractals/multijulia/
>
> Trig would be used, say, in rectangular to-from polar forms wrt getting
> the n-ary roots of a complex number?
>

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 3/15/2024 3:23 AM, Terje Mathisen wrote:
>> Michael, I for the main part agree with you here, i.e. calculating
>> sin(x) with x larger than 2^53 or so, is almost certainly stupid.
> [...]
>
> ;^D tooooooo big. :^)
>
> Now, wrt the results, arbitrary precision for trig is useful, in
> say... Deep fractal zooms...
>
> Zooming in really deep in say something like this, well the precision
> of trig can become an issue:
>
> https://paulbourke.net/fractals/multijulia/
>
> Trig would be used, say, in rectangular to-from polar forms wrt
> getting the n-ary roots of a complex number?

I can see how computing sin(x) with high precision for "reasonable"
values of x would be useful, but does any of that benefit from being
able to compute sin(2^53) accurately? (Since I'm posting to
comp.lang.c, I'll mention that "^" is meant to be exponentation, not
bitwise xor.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 3/15/2024 2:16 PM, Keith Thompson wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 3/15/2024 3:23 AM, Terje Mathisen wrote:
>>> Michael, I for the main part agree with you here, i.e. calculating
>>> sin(x) with x larger than 2^53 or so, is almost certainly stupid.
>> [...]
>>
>> ;^D tooooooo big. :^)
>>
>> Now, wrt the results, arbitrary precision for trig is useful, in
>> say... Deep fractal zooms...
>>
>> Zooming in really deep in say something like this, well the precision
>> of trig can become an issue:
>>
>> https://paulbourke.net/fractals/multijulia/
>>
>> Trig would be used, say, in rectangular to-from polar forms wrt
>> getting the n-ary roots of a complex number?
>
> I can see how computing sin(x) with high precision for "reasonable"
> values of x would be useful, but does any of that benefit from being
> able to compute sin(2^53) accurately?

Nope. :^) Fwiw, my fractals deal with zooming in and the numbers
comprising their initial state is tiny compared to 2^53. For instance
take these initial states for my multijulia fractal:

____________
c0 = {0.5,0.0}, c1 = {-5.5,0.0}

c0 = {0.0,1.0}, c1 = {0.0,-1.0}

c0 = {0.726514,0.240242}, c1 = {0.171039,0.235043}

c0 = {-1.444991,0.139179}, c1 = {-0.063294,-1.401774}

c0 = {1,0}, c1 = {-1,0}

c0 = {-.75, .06 }, c1 = {-.45, .6 }

c0 = {-1,0}, c1 = {1,0}, c2 = {0,-1}, c3 = {0,1}
____________

Notice how the numbers are small? However, if we zoom in enough, then
2^53 might become an issue..

> (Since I'm posting to
> comp.lang.c, I'll mention that "^" is meant to be exponentation, not
> bitwise xor.)
>

Indeed.