Re: numerics, roles, and naming
On Sun, 14 Mar 2010, 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. Discrete sounds good to me. Carl Friedrich Gauß was a very significant figure in the development of number theory and many other areas of mathematics; to use his name to label one of his a relatively minor developments doesn't really do him justice. Not that I have a better label in mind though. (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.) George Boole also worked in several areas of mathematics. One of those was what he termed algebra of logic, hence Boolean algebra as mathematicians know it now. But what we (programmers) call Boolean, although in line with his original concept, is a pale shadow of where Boolean Algebra has developed since. In particular there are things call power sets, and a field using set intersection and union over those has the same algebraic properties as the original algebra of logic, but not with just two true and false values. So mathematically a Boolean value doesn't necessarily behave the same way as a bit, rather it behaves like a structured collection of bits. Treating an integer value as a vector of bits is certainly one such structure. Things like primes over Z(2) are not very interesting, but a field or ring over Z(2)^n does have interesting behaviour that depends on n. So I'm in favour of a Boolean role including things such as a vector of bits. I suggest Predicate as the name of the role which implements a single true-or-false value (as distinct from a bit, which implements a 0-or-1 value). -Martin
Re: numerics, roles, and naming
On Mon, 15 Mar 2010, Mark J. Reed wrote: Anything that can be made into a list is discrete. Not quite, since you can create lists whose members belong to continuous sets, e.g. real numbers. Anything that naturally forms a list, maybe. A discrete non-finite set is isomorphic to the set of integers. This implies that you can pick an ordering, although perhaps not one that is computational useful. E.g. rational numbers can be mapped onto integers by laying them out in a 2D array, much like Gauß's complex integers, and then walking diagonally in one quadrant. If you have more than one quadrant, take them in turns. Extends to 3D and higher in a logic fashion. But totally useless as a greater than/equal to/less than comparison test. -Martin
Re: numerics, roles, and naming
At 10:25 +1300 3/17/10, Martin D Kealey wrote: On Mon, 15 Mar 2010, Mark J. Reed wrote: Anything that can be made into a list is discrete. Not quite, since you can create lists whose members belong to continuous sets, e.g. real numbers. Anything that naturally forms a list, maybe. A discrete non-finite set is isomorphic to the set of integers. This implies that you can pick an ordering, although perhaps not one that is computational useful. E.g. rational numbers can be mapped onto integers by laying them out in a 2D array, much like Gauß's complex integers, and then walking diagonally in one quadrant. If you have more than one quadrant, take them in turns. Extends to 3D and higher in a logic fashion. aleph 0. In the world of real (pun intended) computers there is no continuous set of real numbers. Microsoft Excel users are regularly reminded of that when they report bugs that are nothing more than the impossibility of representing 0.1 (10) as an IEEE float. Perhaps everything is discrete in the set of things that perl is expected to deal with. -- -- If you are presented a number as a percentage, and you do not clearly understand the numerator and the denominator involved, you are surely being lied to. --
Re: numerics, roles, and naming
Martin D Kealey wrote: George Boole also worked in several areas of mathematics. One of those was what he termed algebra of logic, hence Boolean algebra as mathematicians know it now. But what we (programmers) call Boolean, although in line with his original concept, is a pale shadow of where Boolean Algebra has developed since. In particular there are things call power sets, and a field using set intersection and union over those has the same algebraic properties as the original algebra of logic, but not with just two true and false values. So mathematically a Boolean value doesn't necessarily behave the same way as a bit, rather it behaves like a structured collection of bits. Treating an integer value as a vector of bits is certainly one such structure. Things like primes over Z(2) are not very interesting, but a field or ring over Z(2)^n does have interesting behaviour that depends on n. So I'm in favour of a Boolean role including things such as a vector of bits. I suggest Predicate as the name of the role which implements a single true-or-false value (as distinct from a bit, which implements a 0-or-1 value). What you're talking about now reminds me of the relational model of data, which may be (I'm not sure) derived from that algebra of logic you mention (it is at least based on predicate logic and set theory), where a relation value's heading represents a predicate and the relation's body represents a set of true propositions that can be formed from that predicate. So it may be worth considering, when deciding on Boolean-related role names that are meant be as feature-rich as you say, as to whether any choices would be appropriate for a relation type to compose. Of course, we also come back to the question as to whether what boolean algebra has evolved into is something that would be fitting in the Perl core or be best left to modules. -- Darren Duncan
Re: numerics, roles, and naming
On Sun, Mar 14, 2010 at 11:26 PM, Doug McNutt dougl...@macnauchtan.com wrote: Anything that can be made into a list is discrete. Not quite, since you can create lists whose members belong to continuous sets, e.g. real numbers. Anything that naturally forms a list, maybe. The other option is a function in the sense of the calculus that truly has an infinite number of values. The set of integers is both discrete and infinite. Likewise rationals and all the other countable sets. The main thing that discrete sets have that continuous sets don't is the ability to map them exactly onto a sequence. Given an integer, there's a single next integer; given a real number, there's infinitely many - and infinitely many more real numbers in between the start number and whichever next you choose. Perhaps the term atomic could be discreetly considered in place of discrete. In CSland, I suspect atomic is too strongly associated with operations to be applied to a data type that has nothing to do with multithreading or transactional integrity. -- Mark J. Reed markjr...@gmail.com
Re: numerics, roles, and naming
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
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
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
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
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
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
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 --
numerics, roles, and naming
So, I've been looking more closely at Perl's native value types and associated roles, and there are a few matters of their naming or availability that I have questions or suggestions on. 1. As a general observation, I note that it is a common pattern for basic Perl 6 value types that a role for the concept is written out as the whole name, such as Boolean or Rational or Integral or String etc, and the primary Perl type composing that is an abbreviation thereof, Bool or Rat or Int or Str etc. 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? Note that I wouldn't necessarily consider Numeric to be the answer because I would consider Numeric more broad, such as to include anything that might conceivably be called a number, probably user-defined, that isn't representable by a complex. So, is current thinking that Numeric is supposed to fill the role I mentioned, or is it meant to be broader than that, in which case do we need a complex role. If we should have a complex role, then what would we name it? 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. So I suggest making a Complex role and splitting the old Complex type at least into the distinct [Num|Rat|FatRat]Complex types I mentioned. 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? 3. I notice that some roles that are longer forms of type names look like nouns, while others look like adjectives. I suppose that adjectives are what you're going after, and the ones that look like nouns such as Boolean and Rational and Real are also adjectives. On the other hand, lots of roles are surely just nouns, such as Failure and Routine. So a question I have is, given the context, is Integral the best name for that role, or would Integer be better? From some quick searching around, the term integral doesn't seem to be used a lot in literature for the meaning you're ascribing, and integer seems to be much more common, when referring to these things. That is, unless you're specifically going for integral domain as what Integral is meant to cover. Is that it? So is there a specific reason or three that Integral is better than Integer or is it really a wash? Is anyone opposed to renaming Integral to Integer? Besides my inclination to think that some roles are better off looking like nouns when possible, it seems that most literature searches for the term integral bring up calculus operations, such as integration is seemingly a much more commonly used interpretation of the term integral, and so integer may lessen confusion there. Maybe. -- Darren Duncan
Re: numerics, roles, and naming
Follow-up, ... 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. (Note, any replies to this follow-up message should be tacked on as a reply to the initial one.) Thank you. -- Darren Duncan
Re: numerics, roles, and naming
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. 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. 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. 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. 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? 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. I'm fine with Complex being parameterizable, as long as Real is the default parameter. 3. I notice that some roles that are longer forms of type names look like nouns, while others look like adjectives. I suppose that adjectives are what you're going after, and the ones that look like nouns such as Boolean and Rational and Real are also adjectives. On the other hand, lots of roles are surely just nouns, such as Failure and Routine. So a question I have is, given the context, is Integral the best name for that role, or would Integer be better? 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
Re: numerics, roles, and naming
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
