Re: The Inf type
Brandon S. Allbery wrote: John M. Dlugosz wrote: Jon Lang wrote: type (i.e., 'num'). Somehow, I had got it into my head that Num was a role that is done by all types that represent values on the real number line, be they integers, floating-point, rationals, or irrationals. And really, I'd like Num to mean that. I'd rather see Would you care to muse over that with me: what Roles should we decompose the various numeric classes into? Get a good list for organizing the standard library functions and writing good generics, and =then= argue over huffman encoding for the names. Call them greek things for now so we don't confuse anyone g. Learn from the Haskell folks, who are still trying to untangle the mess they made of their numeric hierarchy (see http://haskell.org/haskellwiki/Mathematical_prelude_discussion). I'll look it over. That said, note that we're not dealing with a class hierarchy here; we're dealing with role composition, which needn't be organized into an overarching hierarchal structure to work properly. -- Jonathan Dataweaver Lang
Re: The Inf type
Jon Lang dataweaver-at-gmail.com |Perl 6| wrote: ; I see. We just had a role-vs-class cognitive disconnect. Officially, Num is the autoboxed version of the native floating point type (i.e., 'num'). Somehow, I had got it into my head that Num was a role that is done by all types that represent values on the real number line, be they integers, floating-point, rationals, or irrationals. And really, I'd like Num to mean that. I'd rather see what is currently called 'num' and 'Num' renamed to something like 'float' and 'Float', and leave 'Num' free to mean 'any real number, regardless of how it is represented internally'. Either that, or continue to use Num as specified, but also allow it to be used as a role so that one can create alternate representations of real numbers (or various subsets thereof) that can be used anywhere that Num can be used without being locked into its specific approach to storing values. Would you care to muse over that with me: what Roles should we decompose the various numeric classes into? Get a good list for organizing the standard library functions and writing good generics, and =then= argue over huffman encoding for the names. Call them greek things for now so we don't confuse anyone g. --John
Re: The Inf type
Jon Lang dataweaver-at-gmail.com |Perl 6| wrote: TSa wrote: John M. Dlugosz wrote: The sqrt(2) should be a Num of 1.414213562373 with the precision of the native floating-point that runs at full speed on the platform. That makes the Num type an Int with non-uniform spacing. E.g. there are Nums where $x++ == $x. And the -Inf and +Inf were better called Min and Max respectively. IOW, the whole type based aproach to Inf is reduced to mere notational convenience. Please give an example value for a Num where $x++ == $x. Other than Inf, of course. Num is floating point. If you exceed the mantissa precision, then ++ will not change it. I don't know why he's calling it an Int with non-uniform spacing unless he is complaining about what happens when you store ints in floats: it rounds off to the mantissa size. --John
Re: The Inf type
On 2008 Jun 3, at 3:15, John M. Dlugosz wrote: Jon Lang dataweaver-at-gmail.com |Perl 6| wrote: type (i.e., 'num'). Somehow, I had got it into my head that Num was a role that is done by all types that represent values on the real number line, be they integers, floating-point, rationals, or irrationals. And really, I'd like Num to mean that. I'd rather see Would you care to muse over that with me: what Roles should we decompose the various numeric classes into? Get a good list for organizing the standard library functions and writing good generics, and =then= argue over huffman encoding for the names. Call them greek things for now so we don't confuse anyone g. Learn from the Haskell folks, who are still trying to untangle the mess they made of their numeric hierarchy (see http://haskell.org/haskellwiki/Mathematical_prelude_discussion) . -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: The Inf type
Jon Lang dataweaver-at-gmail.com |Perl 6| wrote: e g. Learn from the Haskell folks, who are still trying to untangle the mess they made of their numeric hierarchy (see http://haskell.org/haskellwiki/Mathematical_prelude_discussion). I'll look it over. That said, note that we're not dealing with a class hierarchy here; we're dealing with role composition, which needn't be organized into an overarching hierarchal structure to work properly. Yes. If you look at my specdoc, the ideas I've identified thus far are basically driven by which functions are sensible on which types. The basic math functions basically define the most primitive roles, as those are what you will be calling (and counting on being sensibly defined) when you write more complicated functions that take generic types, and gives a natural handle on how to specify which types your own function is sensible for. --John
Re: The Inf type
On 2008 Jun 3, at 4:19, John M. Dlugosz wrote: Jon Lang dataweaver-at-gmail.com |Perl 6| wrote: e g. Learn from the Haskell folks, who are still trying to untangle the mess they made of their numeric hierarchy (see http://haskell.org/haskellwiki/Mathematical_prelude_discussion). I'll look it over. That said, note that we're not dealing with a class hierarchy here; we're dealing with role composition, which needn't be organized into an overarching hierarchal structure to work properly. Yes. If you look at my specdoc, the ideas I've identified thus far are basically driven by which functions are sensible on which types. The basic math functions basically define the which functions are sensible on which types is exactly where Haskell is messed up; basically, what makes sense varies according to whose notion of what a given numeric type is. Are you thinking in terms of what current machines do natively? In terms of set theory (a popular alternative among Haskell-folk)? In terms of what most people consider sensible (if you can in fact nail that particular bit of jelly down; OTOH, it may be the most Perlish way of doing it)? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: The Inf type
HaloO,
Mark J. Reed wrote:
In what the heck mathematical world is the square root of two an
infinite value? Irrationality and infinitude are not the same thing;
in particular, there are an (uncountably) infinite number of
irrational numbers...
I don't know what you accept as an infinity but there is e.g.
an infinite set of complex numbers
subset InfSqrt2 of Complex where { $_ ** sqrt(2) == 1 }
whereas
subset Inf141 of Complex where { $_ ** 1409/997 == 1 }
# 1409/997 approx 1.41
only has 1404773 entries. That is one way to transform the infinity
of an irrational number into an infinite set. Rationals only render
infinities of the kind a circle has, where you can run in one direction
without reaching an end.
Or take the tan function that can be used to wrap the real number line
around a circle at Zero. Then you get a point Inf on the other side of
Zero that just behaves like Zero, i.e. on one side you have all the
positive reals and on the other all the negative ones. So you can make
the transition from +Inf to -Inf just as easily as from +0 to -0. IOW,
there are properties that are usually ascribed to Zero that Inf can
claim as well. For that very reason I gave here, IEEE-754 distinguishes
-0 and +0 just like it distinguishes -Inf and +Inf. And there are
contexts where -Inf === +Inf makes sense just as -0 === +0 makes sense
and some where it doesn't. Now, how are these contexts distinguished?
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: The Inf type
HaloO,
John M. Dlugosz wrote:
I don't know why he's calling it an Int with non-uniform spacing
unless he is complaining about what happens when you store ints in
floats: it rounds off to the mantissa size.
With uniform spacing you have
constant $step = 1;
and
$x++; # means $x = $x + $step
whereas non-uniform is
$x++; # means $x = $x + $x.step;
You can make the second to subsume the first with
multi method *step (Int) { 1 }
and optimize whenever you can prove that $x always
does Int. If you can't, you leave that to the runtime.
Going further with that you could define $a == $b to
actually mean abs($a-$b) min($a.step, $b.step).
E.g. with the usual 64bit floats you have 0.5.step==2**-53
and (2**52).step==1. Then per definition
multi method *step (Real) { 0 }
essentially means a real object can't step away from itself
or some such.
Given the above, the optimizer can e.g. take a sub that claims to
achieve its business with two Reals in such a way that ++ is
considered a noop and taken out of the code. If the code is not
up to that it can hardly be a function that properly handles two
Reals. If your test suite manages to detect that failure is another
question. But a good enough optimizer makes bad enough programs
reveal their realness or lack thereof ;)
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: The Inf type
HaloO, John M. Dlugosz wrote: The sqrt(2) should be a Num of 1.414213562373 with the precision of the native floating-point that runs at full speed on the platform. That makes the Num type an Int with non-uniform spacing. E.g. there are Nums where $x++ == $x. And the -Inf and +Inf were better called Min and Max respectively. IOW, the whole type based aproach to Inf is reduced to mere notational convenience. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: The Inf type
TSa wrote: John M. Dlugosz wrote: The sqrt(2) should be a Num of 1.414213562373 with the precision of the native floating-point that runs at full speed on the platform. That makes the Num type an Int with non-uniform spacing. E.g. there are Nums where $x++ == $x. And the -Inf and +Inf were better called Min and Max respectively. IOW, the whole type based aproach to Inf is reduced to mere notational convenience. Please give an example value for a Num where $x++ == $x. Other than Inf, of course. As well, I can easily buy into the idea that +Inf _is_ conceptually equivalent to Max, in that '$x before +Inf' will be true for all non-Inf values of $x that are Nums. Likewise, -Inf is conceptually equivalent to Min in the same way. But just because they're conceptually equivalent, that doesn't mean that they're better off renamed. If you intend to come up with a more encompassing definition of Inf, please do so in a way that preserves the above behavior when you apply that definition to Num. -- Jonathan Dataweaver Lang
Re: The Inf type
On Fri, May 9, 2008 at 9:10 AM, TSa [EMAIL PROTECTED] wrote: E.g. sqrt(2) might return a special Inf that can be lazily stringified to an arbitrary long sequence of digits of sqrt(2). In what the heck mathematical world is the square root of two an infinite value? Irrationality and infinitude are not the same thing; in particular, there are an (uncountably) infinite number of irrational numbers... -- Mark J. Reed [EMAIL PROTECTED]
Re: The Inf type
On Mon, Jun 02, 2008 at 11:50:20AM -0700, Jon Lang wrote:
TSa wrote:
John M. Dlugosz wrote:
The sqrt(2) should be a Num of 1.414213562373 with the precision of the
native floating-point that runs at full speed on the platform.
That makes the Num type an Int with non-uniform spacing. E.g. there
are Nums where $x++ == $x. And the -Inf and +Inf were better called
Min and Max respectively. IOW, the whole type based aproach to Inf
is reduced to mere notational convenience.
Please give an example value for a Num where $x++ == $x. Other than
Inf, of course.
All floats run out of integer precision somewhere, e.g. in p5
$ perl -le '$x=1; while($x+1 != $x) { $x *= 2; } print $x'
1.84467440737096e+19
Arbitrary precision mantissas aren't practically useful, since they have
a strong tendency to consume all memory in a few iterations.
-ryan
Re: The Inf type
Ryan Richter wrote:
Jon Lang wrote:
TSa wrote:
John M. Dlugosz wrote:
The sqrt(2) should be a Num of 1.414213562373 with the precision of the
native floating-point that runs at full speed on the platform.
That makes the Num type an Int with non-uniform spacing. E.g. there
are Nums where $x++ == $x. And the -Inf and +Inf were better called
Min and Max respectively. IOW, the whole type based aproach to Inf
is reduced to mere notational convenience.
Please give an example value for a Num where $x++ == $x. Other than
Inf, of course.
All floats run out of integer precision somewhere, e.g. in p5
$ perl -le '$x=1; while($x+1 != $x) { $x *= 2; } print $x'
1.84467440737096e+19
Arbitrary precision mantissas aren't practically useful, since they have
a strong tendency to consume all memory in a few iterations.
Ah; I see. We just had a role-vs-class cognitive disconnect.
Officially, Num is the autoboxed version of the native floating point
type (i.e., 'num'). Somehow, I had got it into my head that Num was a
role that is done by all types that represent values on the real
number line, be they integers, floating-point, rationals, or
irrationals. And really, I'd like Num to mean that. I'd rather see
what is currently called 'num' and 'Num' renamed to something like
'float' and 'Float', and leave 'Num' free to mean 'any real number,
regardless of how it is represented internally'. Either that, or
continue to use Num as specified, but also allow it to be used as a
role so that one can create alternate representations of real numbers
(or various subsets thereof) that can be used anywhere that Num can be
used without being locked into its specific approach to storing
values.
--
Jonathan Dataweaver Lang
Re: The Inf type
HaloO, I wrote: John M. Dlugosz wrote: I wrote a complete treatment of Inf support. Please take a look at 24.26 Infinite on pages 116-119, and 3.11.3 Infinities on pages 26-27. I have a lot to say to that. Please give me time. I find your treatment of Inf too Num centric. E.g. already the built-in Complex should have an unsigned infinity. Or one that has an argument. This argument might also be useful for the complex zero. In both cases you have something like a lenthless direction. In general the Undef and Inf types should be parametric on the underlying type of concrete objects. Undef is sort of not yet in the type and Inf is outside the type on the other end so to speak. So I think Undef and Inf span the type. E.g. sqrt(2) might return a special Inf that can be lazily stringified to an arbitrary long sequence of digits of sqrt(2). Assignement to a Num collapses the Infinity towards the nearest Num. IOW, there are Aleph1 infinities of Num between 1 and 2. That is what *defines* Num in contrast to Rat which is Aleph0 infinity as a whole. But perhaps we should call this Aleph1 complete type Real and not use it ;) Also you missed transfinite ordinals which can be very useful. I'll be offline for two weeks, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: The Inf type
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: E.g. sqrt(2) might return a special Inf that can be lazily stringified to an arbitrary long sequence of digits of sqrt(2). ??? The sqrt(2) should be a Num of 1.414213562373 with the precision of the native floating-point that runs at full speed on the platform. If you had a lazy high-precision float class, that's still not Inf. --John
The Inf type
John M. Dlugosz wrote: I wrote a complete treatment of Inf support. Please take a look at 24.26 Infinite on pages 116-119, and 3.11.3 Infinities on pages 26-27. I have a lot to say to that. Please give me time. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
