What units should be used for angles in trig functions?
On 2/21/24 17:35, Lawrence D'Oliveiro wrote:
What units should be used for angles in trig functions?
The standard specifies that sin, cos, and tan() take arguments
measured in radians. Degrees are mentioned only in the context of the
complex versions of the trig functions, and only for the purpose of mentioning that they do NOT take arguments in degrees.
What units should be used for angles in trig functions?
Radians are the most natural unit for most trig calculations, and that’s what the library routines in C and many other languages use. However,
degrees are a more natural unit for humans to input, and to get results
in.
Thus, other languages, but not (yet?) C, provide conversion functions. For example, Python has math.radians() for converting degrees to radians, and math.degrees() for going the other way. Java has something similar.
But I think providing conversion functions is an unnecessarily clumsy way
of doing it, because for every alternative angle unit, you need two functions.
Better to provide just a single conversion factor. E.g.
DEG = π / 180
Now it is easy enough to input angles to a calculation in degrees, e.g.
sin(45 * DEG)
And getting outputs in degrees is equally easy, e.g.
atan2(Y, X) / DEG
Sometimes it is convenient to work in terms of whole circles (360°):
CIRCLE = 2 * π
Thus the examples become:
sin(CIRCLE / 8)
and
atan2(Y, X) / CIRCLE
Anybody remember “gradians”?
GRAD = π / 200
And of course, for completeness, we can have a factor for explicitly specifying that you are working radians:
RAD = 1.0
The latest version of IEEE-754 Standard (or, may be, the one that is
still in preparation? I don't remember), specifiies additional set of
trig routines for which argument=1.0 corresponds to 180 degrees (pi
Radians). The names are SinPi, CosPi etc...
I find this choice somewhat less logical than 1.0 corresponding to 360 degrees, but that's a matter of personal taste.
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
What units should be used for angles in trig functions?
Radians are the most natural unit for most trig calculations, and that’s what the library routines in C and many other languages use. However,
degrees are a more natural unit for humans to input, and to get results
in.
Thus, other languages, but not (yet?) C, provide conversion functions. For example, Python has math.radians() for converting degrees to radians, and math.degrees() for going the other way. Java has something similar.
But I think providing conversion functions is an unnecessarily clumsy way
of doing it, because for every alternative angle unit, you need two functions.
Better to provide just a single conversion factor. E.g.
DEG = π / 180
Now it is easy enough to input angles to a calculation in degrees, e.g.
sin(45 * DEG)
And getting outputs in degrees is equally easy, e.g.
atan2(Y, X) / DEG >
Sometimes it is convenient to work in terms of whole circles (360°):
CIRCLE = 2 * π
Thus the examples become:
sin(CIRCLE / 8)
and
atan2(Y, X) / CIRCLE
Anybody remember “gradians”?
GRAD = π / 200
And of course, for completeness, we can have a factor for explicitly specifying that you are working radians:
RAD = 1.0
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. Also the Euler identity
ix
e = cos x + i sin x
only holds if x is in radians. And so on and so on.
On 22/02/2024 08:32, David Brown wrote:
For implementing "sin", you first have to reduce the value modulo 2π.
For an efficient implentation yes. But applying the formula to values
outside the range of 0 - 2PI also produces the correct result if you go
on for long enough.
Radians is the only angle unit which is not arbitrary.
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.
Also the Euler identity
ix
e = cos x + i sin x
only holds if x is in radians. And so on and so on.
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.
On 22/02/2024 09:27, Blue-Maned_Hawk wrote:
No, it is not. "Turns" are also not arbitrary, and are also
Radians is the only angle unit which is not arbitrary.
mathematically fundamental.
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.
On 21/02/2024 22:35, Lawrence D'Oliveiro wrote:
What units should be used for angles in trig functions?The derivative of the sine is the cosine and vice versa, but only if you measure in radians.
On Thu, 22 Feb 2024 01:59:20 +0200, Michael S wrote:
The latest version of IEEE-754 Standard (or, may be, the one that is
still in preparation? I don't remember), specifiies additional set of
trig routines for which argument=1.0 corresponds to 180 degrees (pi
Radians). The names are SinPi, CosPi etc...
I find this choice somewhat less logical than 1.0 corresponding to 360
degrees, but that's a matter of personal taste.
Also quite unnecessary to invent a whole set of parallel functions just
for a different angle unit.
David Brown wrote:
On 22/02/2024 09:27, Blue-Maned_Hawk wrote:
No, it is not. "Turns" are also not arbitrary, and are also
Radians is the only angle unit which is not arbitrary.
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.
On 22/02/2024 09:27, Blue-Maned_Hawk wrote:
No, it is not. "Turns" are also not arbitrary, and are also
Radians is the only angle unit which is not arbitrary.
mathematically fundamental.
For single precision,
sinpi(1234.5) = 1 exactly. sin(3.1415926*1234.5) = sin(3878.2961) = 1
with an error of ULP = 0.0015 and FE_INEXACT raised.
If you're also trying to implement sinpi(x), sin(x), and sind(x)
over some extended domain such as x in [0,2^23], then argument reduction
for sinpi(x) and sind(x) are much easier than for sin(x), but still
require attention to detail.
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.
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).
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.
On Thu, 22 Feb 2024 19:14:24 -0000 (UTC), Steven G. Kargl wrote:
For single precision,
sinpi(1234.5) = 1 exactly. sin(3.1415926*1234.5) = sin(3878.2961) = 1
with an error of ULP = 0.0015 and FE_INEXACT raised.
That seems like a pretty arbitrary example with no earthly real-world use.
If you're also trying to implement sinpi(x), sin(x), and sind(x)
over some extended domain such as x in [0,2^23], then argument reduction
for sinpi(x) and sind(x) are much easier than for sin(x), but still
require attention to detail.
Doesn’t CORDIC take care of that?
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.
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.
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)
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...
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:No, that applies to lots of angle measures.
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.
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³).
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.
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.
In digital signal processing circle-based units are pretty much always
more natural than radians.
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.
On Thu, 22 Feb 2024 21:04:52 +0000, Lawrence D'Oliveiro wrote:
You are working with approximations anyway. That those approximationsThese aren't some random values for individuals dealing with wave
happen to exactly equal some random value seems irrelevant.
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
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 thoseThese aren't some random values for individuals dealing with wave propagation and resonances phenomena. Here's a better example for
approximations happen to exactly equal some random value seems
irrelevant.
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.
Besides, I hope that you were trolling, you should know very well that
nobody uses DFP for science or engineering.
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.
On 22/02/2024 16:29, Blue-Maned_Hawk wrote:
David Brown wrote:"Arbitrary" means that you picked something without any particular
On 22/02/2024 09:27, Blue-Maned_Hawk wrote:
No, it is not. "Turns" are also not arbitrary, and are also
Radians is the only angle unit which is not arbitrary.
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.
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.
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:No, that applies to lots of angle measures.
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.
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.
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: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.
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?
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.
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.
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.
So zooming in "deep" on say, something like my MultiJulia IFS work is
going to require arbitrary precision trig...
Note 2: subnormal values ...
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 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”?
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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”?
Denormal numbers that are not subnormal are called unnormal, and are
part of IEEE Decimal Floating Point.
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”.
Precisely because DFP is not likely to be used for this kind of
application ...
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 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.
think of the following interesting aspect:
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?
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.
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.
It's 360 because it divides by {lots}, nothing to do with days in a year.
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.
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.
30 can't be evenly divided by 4, 8, 9, 12, 18 or 20 for a start.
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.
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".
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.
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.
On Sat, 16 Mar 2024 16:19:11 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
As written, your example does not emphasize that the problem has
nothing to do with implementation of sinX() library routine.
It's best illustrated by followup conversation with bart, IMHO 100%
O.T.
On 17/03/2024 09:06, Michael S wrote:
On Sat, 16 Mar 2024 16:19:11 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
As written, your example does not emphasize that the problem has
nothing to do with implementation of sinX() library routine.
It's best illustrated by followup conversation with bart, IMHO 100%
O.T.
Actually, the thread topic is the more basic one of whether angles to
these functions should be specified as degrees or radians.
In answer to that, I decided long ago (in my language designs) to
keep them as radians, but allow degrees for constants if written in
one of these styles like this:
sin(30°) + cos(60 deg)
Because, once they're inside a variable:
sin(alpha) + cos(beta)
then the unit used is irrelevant.
As for the value returned from sin() etc, I haven't worried about
that since last century.
Except briefly more recently when I had an arbitrary precision
floating point library and considered whether to add such functions,
but concluded I didn't have the right skills, experience (of using ultra-high precision trig functions) or motivation.
The first problem was: exactly how accurately should it be generated.
With ieee754 it's easy, you only have 53 binary digits to fill.
In my (decimal) library, the default precision for a calculation like 1.0/3.0 is typically set up to 500 decimal digits, or about 1600
bits, otherwise it will keep going forever (the theoretical limit is
19 billion decimal digits, or 64 billion bits).
The second problem was, how do you even calculate sin(x) so that it converges to that accuracy within a reasonable amount of time? The
Taylor series that I used to use wouldn't cut it.
(Dealing with inputs that are extreme multiples of +/- 2pi radians
would be an additional difficulty.)
I decided not to bother with transcendental functions.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 299 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 52:12:15 |
| Calls: | 6,690 |
| Calls today: | 8 |
| Files: | 12,225 |
| Messages: | 5,344,724 |
| Posted today: | 1 |