develooper Front page | perl.perl6.language | Postings from March 2010

Re: numerics, roles, and naming

Thread Previous | Thread Next
From:
Darren Duncan
Date:
March 12, 2010 19:57
Subject:
Re: numerics, roles, and naming
Message ID:
4B9B0D20.4090404@darrenduncan.net
Jon, thanks for your feedback; it was both informative and supportive.

Jon Lang wrote:
> Darren Duncan wrote:
>> 2.  There doesn't seem to be a role for "complex" as there is for "integer"
>> or "rational" or "real" or "numeric".  So, if the boxed Perl complex number
>> is called "Complex" and the machine native one is called "complex" or
>> "complex128" or whatever, what would one name the role that is common to all
>> of these?
> 
> I'm definitely in favor of there being a Complex role - not just for
> the reasons given above, but also to have a common role that applies
> to a complex number regardless of the coordinate system that's being
> used to store the value (e.g. cartesian vs. polar).  Both should be
> able to provide you with the real, imaginary, magnitude, and direction
> components; but classes based off of the cartesian model should be
> able to do the former two directly and calculate the latter two, and
> vice versa.  A single role that's agnostic about the coordinate system
> would allow us to use any of these in a function call.  For that
> purpose, I think that the common, underlying role should be called
> "Complex".

I agree 100%.  I also foresaw the cartesian vs polar thing, and considered it 
very important, but I didn't mention it in my post because for some reason I 
assumed that the existing Complex type already supported both views, or I 
thought I recalled the Synopsis already talking about it.

Anyway, yes, a Complex role *must* include both the cartesian and polar 
possible-representations (possreps), and then there can be a composing class 
optimized for each one.

>> Following the above pattern, you'd think that "Complex" would be best used
>> as th role name and so something else is needed for the type, either as some
>> abbreviation, or alternately with additions.
>>
>> Conceivably one could have a complex type defined in terms of any
>> combination of the various real or rational or integer types, such as
>> "NumComplex" or "RatComplex" (and "FatRatComplex") and "IntComplex" etc.
> 
> For practical purposes, I think that the component types for Complex
> should be standardized as Real - that is, the Complex role should
> assume that the components do the Real role.

That's reasonable.

> As I indicate above, I
> think that a more significant distinction should be the coordinate
> system: cartesian complex numbers are essentially optimized for use
> with addition and subtraction; polar complex numbers are a more
> efficient choice for multiplication and division; raising a number to
> a complex exponent works most efficiently if the exponent is cartesian
> and the result is polar, and vice versa for logs.  And so on.

And now I learned something about complex math.

>> 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.
> 
> Hmm... true enough.  I'd rather have Gaussian be to Complex as
> Integral is to Real: a separate role, not necessarily related in any
> sort of role composition sense, but serving a similar purpose.  Note
> that Gaussian would not have separate cartesian and polar forms; by
> definition, it operates off of a cartesian coordinate system.  While a
> polar version could exist in theory, it doesn't in practice; and even
> if it did, it wouldn't be interchangeable with the cartesian version,
> the way that they are when the components are Real.

Personally I prefer the idea of Int and Rat etc being disjoint as programming 
language data types, even if they are considered subsets by some conceptions, 
because then we can just have Int as the one primitive type in terms of which 
everything else is defined.

So it stands to reason in such as system that making Gaussian/Int-Complex types 
and Real-Complex types disjoint is consistent with the fact that Int does *not* 
compose the Real role.

> OTOH, Gaussian definitely has analogs comparable to the differences
> between Integral vs. Real, in that Gaussian and Integral have the
> concept of factors and everything that goes with them (e.g., primes,
> gcf, lcm, remainders, etc.)  Perhaps we need a role to encapsulate
> that notion, much like we have one that encapsulates the notion of
> order (e.g., before/after).  Or would that turn out to be unnecessary
> clutter, seeing as how we only have two examples of roles that would
> compose it (Integral and Gaussian), one of which is a highly technical
> fringe case?

The role may still be a good idea, though.

See also Boolean, which currently is used by just Bool and Bit (and bit).

On a tangent, something else I was wondering or suggesting is whether it would 
be reasonable for the Boolean role to be composed by anything that supports 
bitwise operations (I don't mean shifting, but not/and/or/xor/etc) since I 
believe all those bitwise operations are direct analogies to boolean operations. 
  I would assume in this case that all those operators in the role would be 
virtual, since each would be implemented differently.  Mind you, I could be 
mis-imagining what exactly the Boolean role contains.  (Also, if you want to be 
thorough, it would also contain the other 7 
nand/nor/xnor|iff/imp|implies/nimp/if/nif dyadic infix ops, even if they are 
easy enough to define in terms of the others.)

<snip>
>>From a layman's view of things, I keep on finding myself wanting to
> say "Integer" rather than "Integral".  That said, it's not that hard
> to retrain myself; and I do see some benefit to the notion that role
> names are adjectives while class names are nouns, as long as it's
> applied consistently to the standard roles.  That said, see below.
> 
> Still: when I first saw "Integral", the first thing that came to mind
> was "a calculus operation", not "whole numbers".
> 
>> 4.  If "Integral" is better called "Integer", or regardless ...
>>
>> Would "Numeric" be better called "Number"?  Would there by any objection to
>> renaming it such?  What are advantages of the former over the latter?
>>
>> Basically, same idea, if we're going more for nouns or adjectives role
>> names.
> 
> IMHO, we should be going for nouns for role names.  Adjectives should
> be reserved for use with a role's parameters - that is, a named
> parameter in a role's signature is an adjective, just like a named
> parameter in a routine's signature is an adverb.

I agree.  As far as I'm concerned, a role is a type (a set of values/objects), 
and so its name should be a noun.  What type is it?  The role type is a union 
over all of the other types that compose that role.  (Whereas the other union 
type declares itself what other types its values come from.)  Unlike a class, a 
type isn't defined by whether you can instantiate it.  You probably can't 
instantiate a "Dog|Cat" union type either, but you can instantiate Dog or Cat 
probably.  Part of what defines a type is whether you can declare that a 
variable or parameter or attribute etc can hold values of it.

So we can also interpret that any role or class name that looks like an 
adjective could in fact just be an abbreviation of a noun.  Such as, "Integral" 
is short for "IntegralNumber".  I believe that all of the existing roles I 
recall can be considered that way.  This said, if we have a choice to use a word 
that is a noun by itself, I may consider that preferable.

So, say, I suggest "Number" over "Numeric" and "Integer" over "Integral", etc.

-- Darren Duncan
Thread Previous | Thread Next

nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About