On Sat, 24 Feb 2024 04:03:08 -0000 (UTC), Steven G. Kargl wrote:

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

That’s 9 figures, but single-precision IEEE754 floats only allow about 7.

On Sat, 24 Feb 2024 04:47:29 +0000, Lawrence D'Oliveiro wrote:

> On Sat, 24 Feb 2024 04:03:08 -0000 (UTC), Steven G. Kargl wrote:
>
>> I can assure one of the libm and mpfr values, when x = 5653.00049,
>> is quite wrong.
>
> That’s 9 figures, but single-precision IEEE754 floats only allow about
> 7.

ROTFL. I suggest (re-)reading the entire section

IEEE Std 754TM-2008

5.12.2 External decimal character sequences representing
finite numbers

However, I'll give you the salient part on p.32

For the purposes of discussing the limits on correctly
rounded conversion, define the following quantities:

for binary32, Pmin (binary32) = 9
....

Conversions from a supported binary format bf to an external
character sequence and back again results in a copy of the
original number so long as there are at least Pmin (bf)
significant digits specified and the rounding-direction
attributes in effect during the two conversions are round to
nearest rounding-direction attributes.

You also seem to miss that I gave you the bit pattern as
an unsigned 32-bit int. There are no extra binary digits.

At this point, I think it might be prudent for you to
read Goldberg's paper [1] and IEEE 754.

[1] https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

I'm done responding to your trolls and apologies other c.l.c
posters.

--
steve

On Sat, 24 Feb 2024 04:03:08 -0000 (UTC), Steven G. Kargl wrote:

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

They’re all wrong. Python says (in double-precision), that
math.sin(5653.00049) is -0.9566595256716378.

Even GCC’s sinf function says the value is -0.9565167, which is only a
slight discrepancy in the fourth decimal place, so even in single-
precision it is doing a darn sight better than you have managed above.

So where is there a version of the code you’re using, using different
angle units, that gets closer to the right answer?

On 2024-02-24, Steven G. Kargl <sgk@REMOVEtroutmask.apl.washington.edu> wrote:
> On Sat, 24 Feb 2024 04:47:29 +0000, Lawrence D'Oliveiro wrote:
>
>> On Sat, 24 Feb 2024 04:03:08 -0000 (UTC), Steven G. Kargl wrote:
>>
>>> I can assure one of the libm and mpfr values, when x = 5653.00049,
>>> is quite wrong.
>>
>> That’s 9 figures, but single-precision IEEE754 floats only allow about
>> 7.
>
> ROTFL. I suggest (re-)reading the entire section

[ snip ]

> for binary32, Pmin (binary32) = 9

Also, from the comp.lang.c point of view, in the C language we have
FLT_DIG and FLT_DECIMAL_DIG in <float.h>.

On IEEE 754 systems these are 6 and 9.

FLT_DIG gives you, roughly speaking, how many decimal digits of
precision a float can preserve in the decimal -> float -> decimal
conversion sequence

FLT_DECIMAL_DIG indicates how many digits are required to exactly
preserve a float value in decimal form: float -> decimal -> float.

--
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 05:38:53 +0000, Lawrence D'Oliveiro wrote:

> On Sat, 24 Feb 2024 04:03:08 -0000 (UTC), Steven G. Kargl wrote:
>
>> % ./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.
>
> They’re all wrong. Python says (in double-precision), that
> math.sin(5653.00049) is -0.9566595256716378.
>
> Even GCC’s sinf function says the value is -0.9565167, which is only a
> slight discrepancy in the fourth decimal place, so even in single-
> precision it is doing a darn sight better than you have managed above.
>
> So where is there a version of the code you’re using, using different
> angle units, that gets closer to the right answer?

sin(x) is not sinpi(x). The conversion factor that you're missing
is M_PI as in sinpi(x) = sin(M_PI*x). The whole point of the
half-cycle trig functions is that one does not need to do the
multiplication by pi, or more importantly the argument reduction
modulo pi.

% ./tlibm sin -f -a 5.65300049e+3
x = 5.65300049e+03f, /* 0x45b0a801 */
libm = -9.56659019e-01f, /* 0xbf74e79b */
mpfr = -9.56659019e-01f, /* 0xbf74e79b */
ULP = 0.10338

--
steve

On 2/23/24 17:39, Lawrence D'Oliveiro 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”?

The same thing that's wrong with calling a horse a quadruped. It's
technically correct, but in a context where it could only be a horse,
the term "quadruped" is unnecessarily vague. Denormal numbers that are
not subnormal are called unnormal, and are part of IEEE Decimal Floating
Point. Decimal floating point types have been an optional feature of C
since 2020.
The C standard never uses the term denormal, but it does use unnormal.
The only thing it does with the term is define it, and allow for the
presence of such numbers - but nothing that it says about normal or
subnormal numbers (which is quite a lot) applies to unnormal numbers,
and that is a deliberate feature of the standard.

On 2/23/2024 2:42 PM, Lawrence D'Oliveiro wrote:
> 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?

It depends on the task at hand? Think of what type of performance hit
one can take if they use double precision on a GPU that supports it in
shader programs...

On Sat, 24 Feb 2024 02:25:51 -0500, James Kuyper wrote:

> Denormal numbers that are not subnormal are called unnormal, and are
> part of IEEE Decimal Floating Point.

Interesting, because when I brought up decimal floats in this thread, I
was accused, by Michael S <already5chosen@yahoo.com>, of “trolling”, on
the grounds that “nobody uses DFP for science or engineering”.

On 2/24/24 16:21, Lawrence D'Oliveiro wrote:
> On Sat, 24 Feb 2024 02:25:51 -0500, James Kuyper wrote:
>
>> Denormal numbers that are not subnormal are called unnormal, and are
>> part of IEEE Decimal Floating Point.
>
> Interesting, because when I brought up decimal floats in this thread, I
> was accused, by Michael S <already5chosen@yahoo.com>, of “trolling”, on
> the grounds that “nobody uses DFP for science or engineering”.

Yes, that makes sense. Precisely because DFP is not likely to be used
for this kind of application, it's inappropriate to talk about denormal
number, because outside of DFP, you're unlikely to run into any denormal
numbers that aren't also subnormal.

On Sat, 24 Feb 2024 17:32:47 -0500, James Kuyper wrote:

> Precisely because DFP is not likely to be used for this kind of
> application ...

But remember why the IEEE decided to formulate a standard for numerics in
the first place: it’s because your typical (non-computer) engineer is just
as naïve about numerical techniques as anybody else. IEEE754 was designed
to reduce many of the unpleasant surprises that bedevilled computer
arithmetic back in the day (Prof William “Mr IEEE754” Kahan’s foreword to
Apple’s Standard Numerics manual, from back in 1987, still makes
entertaining reading today). But as you know, binary arithmetic still has
its share of nonintuitive results. So it only seems logical to go to
decimal arithmetic, as the next step.

On Sat, 24 Feb 2024 12:40:52 -0800, Chris M. Thomasson wrote:

> Think of what type of performance hit one can take if they use double
> precision on a GPU that supports it in shader programs...

I don’t know; what kind of “performance hit” would it be?

Is it time to consider single-precision floats as basically a “legacy”
format, a holdover from the days when we couldn’t afford anything better?

Kaz Kylheku <433-929-6894@kylheku.com> writes:

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

I'm not sure what your point is. LD'O wanted to know why "they" brought
in the more specific term:

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

I just suggested they "they" might have chosen to use the more specific
term "bicycles" for the vehicles in you garage because it's more
precise. Are you disagreeing or using mockery to support that rather
obvious idea?

--
Ben.

On 2/24/2024 2:52 PM, Lawrence D'Oliveiro wrote:
> On Sat, 24 Feb 2024 12:40:52 -0800, Chris M. Thomasson wrote:
>
>> Think of what type of performance hit one can take if they use double
>> precision on a GPU that supports it in shader programs...
>
> I don’t know; what kind of “performance hit” would it be?
>
> Is it time to consider single-precision floats as basically a “legacy”
> format, a holdover from the days when we couldn’t afford anything better?

Imvho, it still has a lot to do with what type of work is involved. Some
people want to get bleeding edge wrt FPS and use floats for games, and
all sorts of interesting tricks wrt not really caring about accuracy all
that much, in a sense. Then, others don't seem to mind "too" of a
little hit on fps as long is they can reach a reasonable level of
accuracy for their particular problem. Double precision, heck I have
seen quad precision in a shader program before.

think of the following interesting aspect:

https://forums.parallax.com/discussion/147522/dog-leg-hypotenuse-approximation

Vs "needing" to get much more accurate results, for say medical imaging
wrt volumetric renders...

On Sat, 24 Feb 2024 19:26:53 -0800, Chris M. Thomasson wrote:

> think of the following interesting aspect:

One of many. Have you read the paper “What Every Computer Scientist Should
Know About Computer Arithmetic”? Among the examples, it looks at the well-
known formula for the quadratic equation:

-b ± sqrt(b² - 4ac)
-------------------
2a

and considers cases where this will not work well, and where you should
use the alternative form

2c
-------------------
-b ± sqrt(b² - 4ac)

instead. (Which has its own cases where it produces poor results, but
luckily they don’t overlap those for the first form.)

On Sun, 25 Feb 2024 00:18:33 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>
> > 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.
>
> I'm not sure what your point is. LD'O wanted to know why "they"
> brought in the more specific term:
>
> "Why did they bring in the term “subnormal”, anyway? What was wrong
> with “denormalized”?"
>
> I just suggested they "they" might have chosen to use the more
> specific term "bicycles" for the vehicles in you garage because it's
> more precise. Are you disagreeing or using mockery to support that
> rather obvious idea?
>

On 22/02/2024 19: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.

A year has 365 days, and that influenced the idea that there should be
360 degrees in a circle. But the Babylonians knew that it was 365 or
close and not 360. So did they think that having 360 degrees was a
fundamental, inherent, mathematical property of a circle, or did they not?
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 25/02/2024 11:19, Malcolm McLean wrote:
> On 22/02/2024 19: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.
>
> A year has 365 days, and that influenced the idea that there should be
> 360 degrees in a circle. But the Babylonians knew that it was 365 or
> close and not 360. So did they think that having 360 degrees was a
> fundamental, inherent, mathematical property of a circle, or did they not?

I don't think that's true.

It's 360 because it divides by {lots}, nothing to do with days in a year.

Steven G. Kargl wrote:
> 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

That seems worse than it should be, I would expect better results than
the 0.5009 quoted for regular sin() below, and still with the same or
better performance. The only obvious explanation would be that sin(x)
over +/- 45 degrees would have a first Taylor term of 1.0*x, and you
could probably force the first Cheby term to be the same, so by adding
that as the last stage you get improved precision for free?

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

sin(x) for Subnormal x seems like it should be trivial: If you just
return x the maximum error of a Taylor series with two terms
(x - x^3/3!)
would be that second term which is by definition zero since x is already
subnormal, right?

If you want to perform well on a platform where subnormal ops traps to a
much slower hardware or software path, then it might make sense to start
by checking for |x| < 2^-340 or so?

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

Terje Mathisen wrote:

>

> sin(x) for Subnormal x seems like it should be trivial: If you just
> return x the maximum error of a Taylor series with two terms
> (x - x^3/3!)
> would be that second term which is by definition zero since x is already
> subnormal, right?

The 2 term polynomial begins to be accurate when |x| < ~2^-19 which is far
bigger than 2^-1023. (2^-19)^3 is 2^-57 which has few digits in the resulting
fraction 2^-19; certainly no 3rd term is required.

> If you want to perform well on a platform where subnormal ops traps to a
> much slower hardware or software path, then it might make sense to start
> by checking for |x| < 2^-340 or so?

Many subnormal operands yield constant results or themselves::

cos(sn) = 1.0
sin(sn) = sn
tan(sn) = sn

> Terje

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.

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. Well, that's what
you appear to be doing but I suspect another motive altogether.

--
Ben.

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.

All except 4, 8, 9, 12, 18, 20, 24, 36, 40, 45, 60, 72, 90, 120, 180,
and 360.

--
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 25/02/2024 22:21, Lawrence D'Oliveiro wrote:
> 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 mean, by dividing a circle into 30 degrees instead of 360?

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

The angles of a triangle would add up to 15 degrees; so a right-angled
triangle would have angles of 7.5 and 3.75 degrees.

A heading of 270 on a compass would be 22.5 degrees in your scheme, and
the smallest change of heading, 1 degree, would be 12 degrees using the
current system.

Or maybe you mean something else entirely; using base-30 instead of
base-10? Sure, that's going to be practical!

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.

On Sun, 25 Feb 2024 14:43:33 -0800, Keith Thompson 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.
>
> All except 4, 8, 9, 12, 18, 20, 24, 36, 40, 45, 60, 72, 90, 120, 180,
> and 360.

All exactly representable in Base-30:

1 / 4 => 0.7f
1 / 8 => 0.3mf
1 / 9 => 0.3a
1 / 12 => 0.2f
1 / 18 => 0.1k
1 / 20 => 0.1f
1 / 24 => 0.17f
1 / 36 => 0.0p
1 / 40 => 0.0mf
1 / 45 => 0.0k
1 / 60 => 0.0f
1 / 72 => 0.0cf
1 / 90 => 0.0a
1 / 120 => 0.07f
1 / 180 => 0.05
1 / 360 => 0.02f

No approximations, no recurring digits.