On 22/02/2024 14: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. Radians are the natural
> angle measure because we want sin' x = cos x and cos' x = -sin x. sin
> and cos are the unique solution to that pair of differential equations
> (with initial conditions sin 0 = 0 and cos 0 = 1).
>
>> Also the Euler identity
>>
>> ix
>> e = cos x + i sin x
>>
>> only holds if x is in radians. And so on and so on.
>
> Yes, and there's another nod to the calculus here because just as sin an
> cos are (with a minus sign) derivatives of each other, e^x is the
> derivative of itself.
>

And that has the dubious honour of being that last article to make it
onto google-groups.

Congratulations, I guess.

On 2/23/2024 5:57 AM, Richard Harnden wrote:
> On 22/02/2024 14: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.  Radians are the natural
>> angle measure because we want sin' x = cos x and cos' x = -sin x.  sin
>> and cos are the unique solution to that pair of differential equations
>> (with initial conditions sin 0 = 0 and cos 0 = 1).
>>
>>> Also the Euler identity
>>>
>>>       ix
>>>      e   = cos x + i sin x
>>>
>>> only holds if x is in radians. And so on and so on.
>>
>> Yes, and there's another nod to the calculus here because just as sin an
>> cos are (with a minus sign) derivatives of each other, e^x is the
>> derivative of itself.
>>
>
> And that has the dubious honour of being that last article to make it
> onto google-groups.

No shit? wow.

>
> Congratulations, I guess.
>

:^D

On 23/02/2024 19:15, Chris M. Thomasson wrote:
> On 2/23/2024 5:57 AM, Richard Harnden wrote:
>> On 22/02/2024 14: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.  Radians are the natural
>>> angle measure because we want sin' x = cos x and cos' x = -sin x.  sin
>>> and cos are the unique solution to that pair of differential equations
>>> (with initial conditions sin 0 = 0 and cos 0 = 1).
>>>
>>>> Also the Euler identity
>>>>
>>>>       ix
>>>>      e   = cos x + i sin x
>>>>
>>>> only holds if x is in radians. And so on and so on.
>>>
>>> Yes, and there's another nod to the calculus here because just as sin an
>>> cos are (with a minus sign) derivatives of each other, e^x is the
>>> derivative of itself.
>>>
>>
>> And that has the dubious honour of being that last article to make it
>> onto google-groups.
>
> No shit? wow.

For clc, I mean.

Michael S wrote:

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

If someone looking for fast sin(x) you are correct, for a person looking
for the best possible (correctly rounded) result, you are not. In any
event I have driven that monstrosity down from 50-odd cycles to 4--
making it at least palatable.

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

There are verification tests that know the exact value of both x and sin(x).
For these uses you argument is not valid--however I am willing to grant
that outside of verification, and in actual use, your argument holds as
well ad the noise in the data provides.

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

On Fri, 23 Feb 2024 12:53:49 +0100, Janis Papanagnou 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.

E.g. using “a” .. “t” to represent the digits with (decimal) values 10 ..
29 in base-30:

1 / 2 = 0.f
1 / 2² = 0.7f
1 / 2³ = 0.3mf
1 / 3 = 0.a
1 / 3² = 0.3a
1 / 3³ = 0.13a
1 / 5 = 0.6
1 / 6 = 0.5

All those fractions are exact.

(And all worked out in my head, for better or for worse.)

On 2/22/2024 6:42 PM, MitchAlsup1 wrote:
> 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.

Well, I use a lot of trig wrt my work. One example is getting at the
roots of complex numbers, polar form to rectangular form, ect... So
zooming in "deep" on say, something like my MultiJulia IFS work is going
to require arbitrary precision trig...

https://paulbourke.net/fractals/multijulia

Btw, my friend Paul took the time to create this nice write up and all
of the renders of my MultiJulia IFS experiment.

On Fri, 23 Feb 2024 20:02:00 +0000, MitchAlsup1 wrote:

> Michael S wrote:
>
>> 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.
>
> If someone looking for fast sin(x) you are correct, for a person looking
> for the best possible (correctly rounded) result, you are not. In any
> event I have driven that monstrosity down from 50-odd cycles to 4--
> making it at least palatable.
>
>> 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".
>
> There are verification tests that know the exact value of both x and
> sin(x).
> For these uses you argument is not valid--however I am willing to grant
> that outside of verification, and in actual use, your argument holds as
> well ad the noise in the data provides.

Fortunately, for 32-bit single precision floating point, one can
exhaustively test single-argument functions. For the SW implementation
on FreeBSD, exhaustive testing shows

% tlibm sinpi -fPED -x 0 -X 0x1p23 -s 0
Interval tested for sinpif: [0,8.38861e+06]
1000000 calls, 0.015453 secs, 0.01545 usecs/call
ulp <= 0.5: 99.842% 1253631604 | 99.842% 1253631604
0.5 < ulp < 0.6: 0.158% 1989420 | 100.000% 1255621024
Max ulp: 0.583666 at 6.07950642e-05

% tlibm sin -fPED -x 0 -X 0x1p23 -s 0
Interval tested for sinf: [0,8.38861e+06]
1000000 calls, 0.019520 secs, 0.01952 usecs/call
ulp <= 0.5: 99.995% 1249842491 | 99.995% 1249842491
0.5 < ulp < 0.6: 0.005% 60102 | 100.000% 1249902593
Max ulp: 0.500900 at 3.68277281e+05

The speed test is for 1M values evenly distributed over
the interval. The difference in speed for sinpi vs sin
is due to the argument reduction.

Note 1: libm built with clang/llvm with only -O2 on a
AMD Phenom II X2 560 Processor (3300.14-MHz K8-class CPU).

Note 2: subnormal values for x are test not included in
the count as subnormal are tested with a different approach.

--
steve

Steven G. Kargl wrote:

> On Fri, 23 Feb 2024 20:02:00 +0000, MitchAlsup1 wrote:

>> Michael S wrote:
>>
>>> 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.
>>
>> If someone looking for fast sin(x) you are correct, for a person looking
>> for the best possible (correctly rounded) result, you are not. In any
>> event I have driven that monstrosity down from 50-odd cycles to 4--
>> making it at least palatable.
>>
>>> 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".
>>
>> There are verification tests that know the exact value of both x and
>> sin(x).
>> For these uses you argument is not valid--however I am willing to grant
>> that outside of verification, and in actual use, your argument holds as
>> well ad the noise in the data provides.

> Fortunately, for 32-bit single precision floating point, one can

All of the numerics I have spoken about are DP (64-bit) values.

> exhaustively test single-argument functions. For the SW implementation
> on FreeBSD, exhaustive testing shows

> % tlibm sinpi -fPED -x 0 -X 0x1p23 -s 0
> Interval tested for sinpif: [0,8.38861e+06]
> 1000000 calls, 0.015453 secs, 0.01545 usecs/call
> ulp <= 0.5: 99.842% 1253631604 | 99.842% 1253631604
> 0.5 < ulp < 0.6: 0.158% 1989420 | 100.000% 1255621024
> Max ulp: 0.583666 at 6.07950642e-05

> % tlibm sin -fPED -x 0 -X 0x1p23 -s 0
> Interval tested for sinf: [0,8.38861e+06]
> 1000000 calls, 0.019520 secs, 0.01952 usecs/call
> ulp <= 0.5: 99.995% 1249842491 | 99.995% 1249842491
> 0.5 < ulp < 0.6: 0.005% 60102 | 100.000% 1249902593
> Max ulp: 0.500900 at 3.68277281e+05

I find it interesting that sinpi() has worse numeric error than sin().

I also find it interesting that the highest error is in the easy part
of polynomial evaluation without argument reduction whereas sin() has
its worst result in a region where significant argument reduction has
transpired.

{{Seems like another case of faster poor answers top slower correct
answers.}}

> The speed test is for 1M values evenly distributed over
> the interval. The difference in speed for sinpi vs sin
> is due to the argument reduction.

But result precision suffers nonetheless.

> Note 1: libm built with clang/llvm with only -O2 on a
> AMD Phenom II X2 560 Processor (3300.14-MHz K8-class CPU).

> Note 2: subnormal values for x are test not included in
> the count as subnormal are tested with a different approach.

On Fri, 23 Feb 2024 22:29:17 +0000, MitchAlsup1 wrote:

> I find it interesting that sinpi() has worse numeric error than sin().

Another argument for sticking with the simpler solution? One set of
radian-specific functions plus conversion factors, instead of a separate
set of unit-specific functions for every unit?

On Fri, 23 Feb 2024 20:38:59 -0000 (UTC), Steven G. Kargl wrote:

> Note 2: subnormal values ...

Why did they bring in the term “subnormal”, anyway? What was wrong with
“denormalized”?

On Fri, 23 Feb 2024 12:28:40 -0800, Chris M. Thomasson wrote:

> So zooming in "deep" on say, something like my MultiJulia IFS work is
> going to require arbitrary precision trig...

In which case, all these arguments from people saying that particular non-
radian angle units are going to squeeze out just that little bit more in
significant figures from IEEE754 single or double precision are really
just irrelevant, aren’t they?

On Fri, 23 Feb 2024 22:29:17 +0000, MitchAlsup1 wrote:

> Steven G. Kargl wrote:
>
>> On Fri, 23 Feb 2024 20:02:00 +0000, MitchAlsup1 wrote:
>
>>> Michael S wrote:
>>>
>>>> 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.
>>>
>>> If someone looking for fast sin(x) you are correct, for a person
>>> looking for the best possible (correctly rounded) result, you are not.
>>> In any event I have driven that monstrosity down from 50-odd cycles to
>>> 4-- making it at least palatable.
>>>
>>>> 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".
>>>
>>> There are verification tests that know the exact value of both x and
>>> sin(x).
>>> For these uses you argument is not valid--however I am willing to
>>> grant that outside of verification, and in actual use, your argument
>>> holds as well ad the noise in the data provides.
>
>> Fortunately, for 32-bit single precision floating point, one can
>
> All of the numerics I have spoken about are DP (64-bit) values.

Sure, but it isn't possible to exhaustively DP on current hardware
(available to me). Simple testing can give one a warm fuzzy feeling.
With 10M values in the range [0,0x1p53], the SW sinpi seems to be better
than the SW sin.

% tlibm sin -d -x 0 -X 0x1p53 -N 10 -s 0
Interval tested for sin: [0,9.0072e+15]
10000000 calls, 2.594275 secs, 0.25943 usecs/call
count: 10000000
xm = 3.4119949728897955e+15, /* 0x43283e61, 0xf8ab4587 */
libm = 7.2135591711063873e-01, /* 0x3fe71559, 0x0118855e */
mpfr = 7.2135591711063862e-01, /* 0x3fe71559, 0x0118855d */
ULP = 0.77814

% tlibm sinpi -d -x 0 -X 0x1p53 -N 10 -s 0
Interval tested for sinpi: [0,9.0072e+15]
10000000 calls, 0.184541 secs, 0.01845 usecs/call
count: 10000000
xm = 1.5384297865527400e+12, /* 0x42766318, 0xf99b8bd7 */
libm = 7.2898962872051931e-01, /* 0x3fe753e2, 0x0ecf4a3e */
mpfr = 7.2898962872051942e-01, /* 0x3fe753e2, 0x0ecf4a3f */
ULP = 0.69476

Note, the timing difference is again dominated by argument reduction.

Also note, that each of the above tests took ~180 cpu seconds. At
the moment, tlibm will not use multiple cores or cpus on other nodes.

>> exhaustively test single-argument functions. For the SW implementation
>> on FreeBSD, exhaustive testing shows
>
>> % tlibm sinpi -fPED -x 0 -X 0x1p23 -s 0 Interval tested for sinpif:
>> [0,8.38861e+06]
>> 1000000 calls, 0.015453 secs, 0.01545 usecs/call
>> ulp <= 0.5: 99.842% 1253631604 | 99.842% 1253631604
>> 0.5 < ulp < 0.6: 0.158% 1989420 | 100.000% 1255621024 Max ulp:
>> 0.583666 at 6.07950642e-05
>
>> % tlibm sin -fPED -x 0 -X 0x1p23 -s 0 Interval tested for sinf:
>> [0,8.38861e+06]
>> 1000000 calls, 0.019520 secs, 0.01952 usecs/call
>> ulp <= 0.5: 99.995% 1249842491 | 99.995% 1249842491
>> 0.5 < ulp < 0.6: 0.005% 60102 | 100.000% 1249902593 Max ulp:
>> 0.500900 at 3.68277281e+05
>
> I find it interesting that sinpi() has worse numeric error than sin().
>
> I also find it interesting that the highest error is in the easy part of
> polynomial evaluation without argument reduction whereas sin() has its
> worst result in a region where significant argument reduction has
> transpired.
>
> {{Seems like another case of faster poor answers top slower correct
> answers.}}

For my purposes, a max ulp 0.538 is good enough. The time needed
to reduce this to 0.5009 is better spent on other unimplemented
libm functions in Freebsd's libm or implemented functions with
much worse ULP

>> The speed test is for 1M values evenly distributed over the interval.
>> The difference in speed for sinpi vs sin is due to the argument
>> reduction.
>
> But result precision suffers nonetheless.

Argument reduction itself isn't the culprit. Go read the FreeBSD source
code. What is done once one has the reduced argument is the issue. I
suspect that any patch you come up with would be gladly accepted.

--
steve

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Fri, 23 Feb 2024 20:38:59 -0000 (UTC), Steven G. Kargl wrote:
>
>> Note 2: subnormal values ...
>
> Why did they bring in the term “subnormal”, anyway? What was wrong with
> “denormalized”?

Greater clarity maybe? After all, the two terms do mean different
things. In IEEE FP only subnormals can exist, but it surely helps to be
able to talk about the difference.

--
Ben.

On 2024-02-23, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Fri, 23 Feb 2024 20:38:59 -0000 (UTC), Steven G. Kargl wrote:
>
>> Note 2: subnormal values ...
>
> Why did they bring in the term “subnormal”, anyway? What was wrong with
> “denormalized”?

subnormals are subset of denormals. In IEEE 754, the only denormals
are subnormals. This is because values that are outside of the subnormal
range have the implicit 1 in the mantissa.

Suppose you have a binary floating-point representation in which the 1
in the mantissa must be explicit, e.g.

101
1.10100101 x 10

Then you can have denormals regardless of the exponent value.

E.g. the above normal number can also be expressed this way:

110 <-- incremented
0.110100101 x 10

^
|
mantissa shifted right, bringing in a zero on the left

This denormal isn't subnormal, though; the subnormals are those
denormals which have a magnitude smaller than the smallest normal
magnitude. Those are the helpful/necessary ones which fill the gap
between zero and the smallest normals.

IEEE numbers don't have a zero on the left; the highest bit of the
mantissa is not represented and is assumed to be 1. As a special hack,
this implicit 1 assumption is lifted for the subnormals. This behavior
is turned on when the exponent value is the smallest possible one.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Fri, 23 Feb 2024 23:16:32 +0000, Ben Bacarisse wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Fri, 23 Feb 2024 20:38:59 -0000 (UTC), Steven G. Kargl wrote:
>>
>>> Note 2: subnormal values ...
>>
>> Why did they bring in the term “subnormal”, anyway? What was wrong with
>> “denormalized”?
>
> Greater clarity maybe? After all, the two terms do mean different
> things. In IEEE FP only subnormals can exist, but it surely helps to be
> able to talk about the difference.

I thought they were the same thing: extra numbers inserted in the gap
between the normalized number closest to zero on each side, to allow for
gradual underflow.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Fri, 23 Feb 2024 23:16:32 +0000, Ben Bacarisse wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> On Fri, 23 Feb 2024 20:38:59 -0000 (UTC), Steven G. Kargl wrote:
>>>
>>>> Note 2: subnormal values ...
>>>
>>> Why did they bring in the term “subnormal”, anyway? What was wrong with
>>> “denormalized”?
>>
>> Greater clarity maybe? After all, the two terms do mean different
>> things. In IEEE FP only subnormals can exist, but it surely helps to be
>> able to talk about the difference.
>
> I thought they were the same thing: extra numbers inserted in the gap
> between the normalized number closest to zero on each side, to allow for
> gradual underflow.

Those are subnormal. They are smaller (in magnitude) than the smallest
normal. Denormals are simply representations with leading zeros. IEEE
FP's implicit leading 1 means these (denormals that are not subnormal)
can't exist in that representation.

--
Ben.

On Sat, 24 Feb 2024 01:15:58 +0000, Ben Bacarisse wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> I thought they were the same thing: extra numbers inserted in the gap
>> between the normalized number closest to zero on each side, to allow
>> for gradual underflow.
>
> Those are subnormal. They are smaller (in magnitude) than the smallest
> normal. Denormals are simply representations with leading zeros. IEEE
> FP's implicit leading 1 means these (denormals that are not subnormal)
> can't exist in that representation.

So in IEEE754, they are the same thing. Which is what I thought. So you
don’t really need two terms for them. Particularly when one of them has
certain undesirable ... connotations.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Sat, 24 Feb 2024 01:15:58 +0000, Ben Bacarisse wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> I thought they were the same thing: extra numbers inserted in the gap
>>> between the normalized number closest to zero on each side, to allow
>>> for gradual underflow.
>>
>> Those are subnormal. They are smaller (in magnitude) than the smallest
>> normal. Denormals are simply representations with leading zeros. IEEE
>> FP's implicit leading 1 means these (denormals that are not subnormal)
>> can't exist in that representation.
>
> So in IEEE754, they are the same thing.

No. I am pretty sure you understand what's been said so you must be
arguing for the sake of it.

--
Ben.

On 2024-02-24, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Sat, 24 Feb 2024 01:15:58 +0000, Ben Bacarisse wrote:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>>> I thought they were the same thing: extra numbers inserted in the gap
>>>> between the normalized number closest to zero on each side, to allow
>>>> for gradual underflow.
>>>
>>> Those are subnormal. They are smaller (in magnitude) than the smallest
>>> normal. Denormals are simply representations with leading zeros. IEEE
>>> FP's implicit leading 1 means these (denormals that are not subnormal)
>>> can't exist in that representation.
>>
>> So in IEEE754, they are the same thing.
>
> No. I am pretty sure you understand what's been said so you must be
> arguing for the sake of it.

I have only bicycles in my garage, so in my garage, "bicycles" and
"vehicles" are the same thing, not just the same set.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Sat, 24 Feb 2024 01:27:28 +0000, Ben Bacarisse wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Sat, 24 Feb 2024 01:15:58 +0000, Ben Bacarisse wrote:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>>> I thought they were the same thing: extra numbers inserted in the gap
>>>> between the normalized number closest to zero on each side, to allow
>>>> for gradual underflow.
>>>
>>> Those are subnormal. They are smaller (in magnitude) than the
>>> smallest normal. Denormals are simply representations with leading
>>> zeros. IEEE FP's implicit leading 1 means these (denormals that are
>>> not subnormal) can't exist in that representation.
>>
>> So in IEEE754, they are the same thing.
>
> No. I am pretty sure you understand what's been said so you must be
> arguing for the sake of it.

So, give me an example, in IEEE754, of something that is one but not the
other.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Fri, 23 Feb 2024 23:16:32 +0000, Ben Bacarisse wrote:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>>> On Fri, 23 Feb 2024 20:38:59 -0000 (UTC), Steven G. Kargl wrote:
>>>>
>>>>> Note 2: subnormal values ...
>>>>
>>>> Why did they bring in the term "subnormal", anyway? What was wrong with
>>>> "denormalized"?
>>>
>>> Greater clarity maybe? After all, the two terms do mean different
>>> things. In IEEE FP only subnormals can exist, but it surely helps to be
>>> able to talk about the difference.
>>
>> I thought they were the same thing: extra numbers inserted in the gap
>> between the normalized number closest to zero on each side, to allow for
>> gradual underflow.
>
> Those are subnormal. They are smaller (in magnitude) than the smallest
> normal. Denormals are simply representations with leading zeros. IEEE
> FP's implicit leading 1 means these (denormals that are not subnormal)
> can't exist in that representation.

There is some terminology confusion here. Depending on what
source is consulted, the term "denormal" has different meanings.
On Wikipedia, for example, "denormal numbers" redirects to
"subnormal number". Apparently the IEEE floating point standard
uses the term differently. Other sources are not consistent.

Note that the ISO C standard uses and defines the terms "subnormal
floating-point numbers" and "unnormalized floating-point numbers",
as disjoint sets, distinct from normalized floating-point numbers
(which the ISO C standard also defines). I expect it would help
the conversation to use these three terms (normalized, subnormal,
and unnormalized) and no others, since "denormal" or "denormalized"
seems to mean different things depending on which source is used.

On Sat, 24 Feb 2024 02:21:57 +0000, Lawrence D'Oliveiro wrote:

> On Sat, 24 Feb 2024 01:27:28 +0000, Ben Bacarisse wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> On Sat, 24 Feb 2024 01:15:58 +0000, Ben Bacarisse wrote:
>>>
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>>
>>>>> I thought they were the same thing: extra numbers inserted in the
>>>>> gap between the normalized number closest to zero on each side, to
>>>>> allow for gradual underflow.
>>>>
>>>> Those are subnormal. They are smaller (in magnitude) than the
>>>> smallest normal. Denormals are simply representations with leading
>>>> zeros. IEEE FP's implicit leading 1 means these (denormals that are
>>>> not subnormal) can't exist in that representation.
>>>
>>> So in IEEE754, they are the same thing.
>>
>> No. I am pretty sure you understand what's been said so you must be
>> arguing for the sake of it.
>
> So, give me an example, in IEEE754, of something that is one but not the
> other.

Well, that's a conundrum. One cannot give you an example as IEEE 754
does not describe unnormal numbers.

See https://en.wikipedia.org/wiki/Subnormal_number

PS: Yes, I know that page does not tell you what unnormal means.

--
steve

On Sat, 24 Feb 2024 02:49:29 -0000 (UTC), Steven G. Kargl wrote:

> On Sat, 24 Feb 2024 02:21:57 +0000, Lawrence D'Oliveiro wrote:
>
>> So, give me an example, in IEEE754, of something that is one but not
>> the other.
>
> Well, that's a conundrum. One cannot give you an example as IEEE 754
> does not describe unnormal numbers.

No, it’s not a conundrum. It’s just a confirmation of my point that, in
IEEE754, you don’t need two words because there is only the single
concept.

On 2024-02-24, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sat, 24 Feb 2024 02:49:29 -0000 (UTC), Steven G. Kargl wrote:
>
>> On Sat, 24 Feb 2024 02:21:57 +0000, Lawrence D'Oliveiro wrote:
>>
>>> So, give me an example, in IEEE754, of something that is one but not
>>> the other.
>>
>> Well, that's a conundrum. One cannot give you an example as IEEE 754
>> does not describe unnormal numbers.
>
> No, it’s not a conundrum.

Well, it's a subnundrum, which in your case is the same thing
as a denundrum.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Fri, 23 Feb 2024 22:39:19 +0000, Lawrence D'Oliveiro wrote:

> On Fri, 23 Feb 2024 22:29:17 +0000, MitchAlsup1 wrote:
>
>> I find it interesting that sinpi() has worse numeric error than sin().
>
> Another argument for sticking with the simpler solution? One set of
> radian-specific functions plus conversion factors, instead of a separate
> set of unit-specific functions for every unit?

Here's a counter argument for your simple conversion
factors. Changing FreeBSD's libm to return sinf(M_PI*x)
for sinpif(x), one observes

%./tlibm sinpi -f -x 0 -X 0x1p22 -PED
Interval tested for sinpif: [0,4.1943e+06]
ulp <= 0.5: 83.174% 1037372501 | 83.174% 1037372501
0.5 < ulp < 0.6: 0.937% 11690904 | 84.111% 1049063405
0.6 < ulp < 0.7: 0.689% 8587516 | 84.800% 1057650921
0.7 < ulp < 0.8: 0.497% 6200902 | 85.297% 1063851823
0.8 < ulp < 0.9: 0.323% 4023726 | 85.620% 1067875549
0.9 < ulp < 1.0: 0.157% 1952256 | 85.776% 1069827805
1.0 < ulp < 1.5: 0.347% 4332879 | 86.124% 1074160684
1.5 < ulp < 2.0: 0.247% 3083647 | 86.371% 1077244331
2.0 < ulp < 3.0: 0.360% 4491936 | 86.731% 1081736267
3.0 < ulp < 0.0: 13.269% 165496149 | 100.000% 1247232416
Max ulp: 8388278.500000 at 5.65300049e+03

% ./tlibm sinpi -f -a 5.65300049e+03
x = 5.65300049e+03f, /* 0x45b0a801 */
libm = -2.51050433e-03f, /* 0xbb248746 */
mpfr = -1.53398013e-03f, /* 0xbac90fd5 */
ULP = 8388278.50000

I can assure one of the libm and mpfr values, when x = 5653.00049,
is quite wrong.

--
steve