Re: numerics, roles, and naming

2010-03-14 Thread James Cloos
 DD == Darren Duncan dar...@darrenduncan.net writes:

Some tiny thoughts:

DD ... I would consider Numeric more broad, such as to include
DD anything that might conceivably be called a number, probably
DD user-defined, that isn't representable by a complex.

Is Numeric intended to have a guarantee of commutability? Ie, is it a ring?

Or, put another way, would a Quaternion be a Numeric?

DD Or maybe better yet for completion sake, make Gaussian a role and
DD something like Gaus the type or something.

Wasn’t his name Gauß?  If so, then Gauß or Gauss, yes?

In general, though, I agree with the thesis.

-JimC
-- 
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6


Re: numerics, roles, and naming

2010-03-14 Thread Ruud H.G. van Tol

Darren Duncan wrote:

For the integer version, my understanding is that number theory already 
provides a suitable term, Gaussian integer, which is a complex number 
whose real and imaginary parts are both integers.


So I suggest using Gaussian as the name option for an IntComplex.

Or maybe better yet for completion sake, make Gaussian a role and 
something like Gaus the type or something.


Alternately, while we would still need a Complex-specific role, we could 
possibly avoid a need to explicitly declare some of the composing types 
if Complex is parameterizable, as AFAIK Rational et al are parameterizable.


What do you think?


Did you consider discrete?

--
Ruud



Re: numerics, roles, and naming

2010-03-14 Thread Jon Lang
Ruud H.G. van Tol wrote:
 Did you consider discrete?

I think that Discrete could work quite well as the role that
encapsulates the ways in which Integer and Gauss are alike.  It may
even be genralizable beyond that, although there might be some discord
between theory and practice.  (In theory, Boolean is every bit as
discrete as Integer is; but in practice, it has no use for most if not
all of the methods in Integer that pertain to discreteness (factors,
remainders, primes, etc.)

-- 
Jonathan Dataweaver Lang


Re: numerics, roles, and naming

2010-03-14 Thread Darren Duncan

Jon Lang wrote:

Ruud H.G. van Tol wrote:

Did you consider discrete?


I think that Discrete could work quite well as the role that
encapsulates the ways in which Integer and Gauss are alike.  It may
even be genralizable beyond that, although there might be some discord
between theory and practice.  (In theory, Boolean is every bit as
discrete as Integer is; but in practice, it has no use for most if not
all of the methods in Integer that pertain to discreteness (factors,
remainders, primes, etc.)


I'm inclined to consider a Discrete to be broad enough to include Boolean, as 
well as every single enum type in general; it would also include Order, say.  So 
I would also then add a more specific something, say DiscreteNumeric.


I see some of the role relationships going like this:

 - Numeric is a proper subset of the universal set
 - Ordered is a proper subset of the universal set
 - Discrete is a proper subset of the universal set
 - Ordinal is a subset of [Ordered intersect Discrete]
 - DiscreteNumeric is a subset of [Numeric intersect Discrete]
 - Integral is a subset of [Ordinal intersect DiscreteNumeric]
 - Real, Rational are subsets of [[Ordered intersect Numeric] minus Ordinal]
 - Complex is a subset of [Numeric minus Ordered]
 - Gaussian is a subset of DiscreteNumeric (or [Complex intersect Discrete])
 - Boolean, Order are subsets of Discrete (or of Ordinal, take your preference)
 - Stringy is subset of [Ordered minus Ordinal] (or [Ordered minus Discrete]?)

Or, sort of arranged visually (with some repeats):

  universal-set
Numeric
  Real, Rational
  Complex
  DiscreteNumeric
Integral (conceptually also Real, Rational)
Gaussian (conceptually also Complex)
Ordered
  Ordinal
Integral
Boolean, Order
  Real, Rational
  Stringy
Discrete
  Ordinal
Integral
Boolean, Order
  Gaussian

A distinction between Ordered and Ordinal is that only Ordinal provides pred() 
and succ() while both provide before(), after(), etc.


So, some thoughts.

-- Darren Duncan


Re: numerics, roles, and naming

2010-03-14 Thread Jon Lang
Darren Duncan wrote:
 I'm inclined to consider a Discrete to be broad enough to include Boolean,
 as well as every single enum type in general; it would also include Order,
 say.  So I would also then add a more specific something, say
 DiscreteNumeric.

There are discrete things that are not ordered (such as gaussian
integers), and there are ordered things that are not discrete (such as
real numbers or strings).  As well, I was using the term Discrete as
shorthand for DiscreteNumber, just as Real can be thought of as
shorthand for RealNumber: the role's purpose, regardless of name, is
to mandate methods that are mostly unique to integer math (e.g.,
infix:%).  As such, it would be silly to apply the role to, say, an
enum of the days of the week: Thursday % Tuesday should not equal
Sunday; it should be nonsense.

And with that in mind, the role (whatever it's called) should not be
composed into Boolean, even conceptually: while Boolean values can be
mapped to numeric values, they are not inherently numeric, any more
than strings are.  Never mind the fact that there's no practical
application for such things as infix:% when talking about a class
with two possible values.

More generally, we need to be careful to keep anything new firmly
grounded in the practical.  If we introduce a Discrete role, it
should be because doing so allows us to do something more easily
(taking into account the effort involved in writing the role in the
first place), or because it makes some task possible that would
otherwise be impossible.  A role representing discrete numbers might
just meet these requirements, in that they let you write functions
that depend on being able to, say, factor numbers or find remainders
without worrying about what kind of numbers they are.  And even here
I'm leery, given the fringe status of non-Integer discrete numbers.
I'm not at all sure what practical benefit a generic Discrete role
would bring to the table.

Remember also: we're putting together the Perl 6 core here; we need to
show some discretion in terms of what to include vs. what gets farmed
out to perl 6 modules.  I suspect that gaussian integers belong
firmly in the latter camp; as such, they are germane to discussions
about core features only to the extent that the core needs to
anticipate such things.

-- 
Jonathan Dataweaver Lang


Re: numerics, roles, and naming

2010-03-14 Thread Darren Duncan

Jon Lang wrote:

Remember also: we're putting together the Perl 6 core here; we need to
show some discretion in terms of what to include vs. what gets farmed
out to perl 6 modules.  I suspect that gaussian integers belong
firmly in the latter camp; as such, they are germane to discussions
about core features only to the extent that the core needs to
anticipate such things.


I agree, in general.

Presumably, the core doesn't have to have any roles built-in that aren't already 
composed into at least 2 core classes or roles, to keep things simpler.


I would expect that a third-party module should be able to effectively define a 
role that would conceptually cover both a core type as well as types of their 
own, which they can then use, even though the definition of the core type 
doesn't compose that role itself.


So then they get the same functionality, and the core stays simpler.

-- Darren Duncan


Re: numerics, roles, and naming

2010-03-14 Thread Doug McNutt
At 18:14 -0800 3/14/10, Jon Lang wrote:
There are discrete things that are not ordered (such as gaussian
integers), and there are ordered things that are not discrete (such as
real numbers or strings). 

The word discrete as in atoms are the discrete view of matter may turn out to 
be confusing to a class of calculus trained folks.

Anything that can be made into a list is discrete. The other option is a 
function in the sense of the calculus that truly has an infinite number of 
values. Computers don't deal with that kind of thing except, perhaps, in the 
likes of Mathematica and Maple where ROOTOF( ) is used to represent something 
that cannot be calculated right now. I really don't think perl should be 
getting into that.

But there is a discrete Fourier transform that is never exactly the same as a 
Fourier transform done with  the techniques of integral calculus. Perl6 surely 
will be performing the discrete kind but will the arguments and answers need to 
be discrete variables? They will surely be lists of, often complex, numbers.

Perhaps the term atomic could be discreetly considered in place of discrete.
-- 

-- A fair tax is one that you pay but I don't --