Re: r31735 -[spec] Say a bit about Numeric operators and Bridge.
On 16 Jul 2010, at 14:39, pugs-comm...@feather.perl6.nl wrote:
Because all CReal types are well-ordered
Oh, they are? Just how are we implementing that? http://en.wikipedia.org/wiki/Well-order
says that the de facto standard foundations of mathematics are
insufficient to define a formula for well-ordering the reals. Even if
we just consider arbitrary-precision rationals, what's the least
element of C3 ... { (2 * $^p + 2) / ($^p + 2) }? This sequence
consists of infinitely many rationals in which each element is less
than its predecessor yet greater than sqrt(2), so there is no least
element under the ≤ ordering. If only CReal types were required to
have a *total* ordering rather than a *well*-ordering; things would be
so much simpler.
-- Minimiscience
Re: Ordering in \bbold{C}
On Mar 28, 2010, at 3:09 PM, James Cloos wrote: | Given A = a₁ + i·a₂ and B = b₁ + i·b₂, then: | | A ≤ B if a₁ b₁ || ( a₁ == b₁ a₂ ≤ b₂ ) | A ≥ B if a₁ b₁ || ( a₁ == b₁ a₂ ≥ b₂ ) Assuming that the last line should be A ≥ B if a₁ b₁ ..., this is called lexicographic ordering, and it's nothing new, especially not for complex numbers. (Someone might even have suggested ordering Complexes this way in the original discussion, but I can't find it right now.) The problem with this ordering and all other orderings of the complex plane is that it is impossible to make ℂ into an ordered field[1] that has all of the properties that we have come to expect from ordering the real numbers. Specifically, because -1 is a square in ℂ, ℂ being an ordered field would require that -1 0, which leads to a contradiction. I can give you a complete proof of this if you like. -- Minimiscience [1] http://en.wikipedia.org/wiki/Ordered_field
Re: generality of Range
On Oct 4, 2009, at 12:47 PM, yary wrote: There was a big discussion about this on the list recently but I don't recall the resolutions. The resolution was r28344: http://dev.pugscode.org/changeset/28344. The short version is that ranges are now primarily used for testing inclusion in intervals; if you want a list of values in an interval, use ... instead. -- Minimiscience
Re: r28523 - docs/Perl6/Spec/S32-setting-library
On Oct 1, 2009, at 4:15 PM, Moritz Lenz wrote: -Returns a list of all C$nth (complex) roots of C$x +Returns a list of all C$nth (complex) roots of C$x. Returns CNaN if +C $n = 0 , itself if C$n == 0, and is free to return a single CNaN Shouldn't this be C $n 0 ? What's the 0th root of a number, then? It would be a number $y for which $y ** 0 == $x, which can only be fulfilled for $x == 1. So in the general cases the answer to the question root($x, 0) is nonsense, which is best mapped to NaN. But the very next part of the sentence reads [returns] itself if C$n == 0. If root($x, 0) is supposed to return a list containing both NaN and $x, the specification should probably be explicit. If it's meant to only return NaN, the itself if C$n == 0 part needs to be deleted. -- Minimiscience
Re: r28523 - docs/Perl6/Spec/S32-setting-library
On Oct 1, 2009, at 4:43 PM, Jan Ingvoldstad wrote: On Thu, Oct 1, 2009 at 10:15 PM, Moritz Lenz mor...@faui2k3.org wrote: What's the 0th root of a number, then? It would be a number $y for which $y ** 0 == $x, which can only be fulfilled for $x == 1. So in the general cases the answer to the question root($x, 0) is nonsense, which is best mapped to NaN. That doesn't make sense. The answer is 1, not NaN. Think about it for a while: mathematically speaking, we would expect the 0th root of a number to be 1. I think you're confusing root with power. Any number raised to the zeroth power is one (except, arguably, zero itself), but, given a number $num, its zeroth root is a number $base such that $base ** 0 == $num, which, as stated above, only makes sense when $num == 1. -- Minimiscience
XOR does not work that way.
S03 describes ^^ as a short‐circuit exclusive‐or operator which returns true if only if exactly one operand is true, short circuiting after encountering two true values. However, this definition is only consistent with the mathematical definition of XOR when the operation is being performed on no more than two operands, yet ^^ has list associativity, implying that the Synopsis's specification applies regardless of how many expressions are being XORed together at once. Moreover, assuming that S03's definition only refers to XOR with two operands would make the specification seem very poorly written, and short-circuiting would not accomplish anything at all. Under the mathematical definition, a series of boolean values chained together (for lack of a better term) with XOR associate such that the result of a single XOR pairing is passed as an operand to the adjacent XOR. (Because XOR is associative in the mathematical sense, treating it as either left-associative or right-associative will always produce the same result.) It can be shown that the truth of the entire expression is *not* equivalent to whether there is exactly one true operand but rather to whether the number of true operands is odd (cf. 1 ^ 1 ^ 1 in C or Perl 5). Thus, in order to determine the truth value of such a series, the truth value of *every* operand needs to be evaluated, and so it is impossible to short-circuit. (Interestingly, assuming that it processes two operands at a time, the reduce operator [^^] implements XOR correctly for more than two operands, even if plain ^^ does not.) An operator which returns true if only if exactly one of its operands is true would be a separate operation entirely; the closest thing I can find in mathematics (OK, on Wikipedia) is the minimal negation operator http://en.wikipedia.org/wiki/Minimal_negation_operator when its arguments have been mapped through a logical NOT. This problem also applies to the description of the xor operator, though not to the bitwise XOR operators, as they make no claims to unorthodox behavior and the proper behavior can be inferred from the fact that they are left-associative. The appropriateness of the ^ junctive operator is less clear, however; while the synopses don't seem to refer to it as an exclusive-or operation (though I could be wrong about that), and its list associativity allows it to be viewed as wrapping a one() function around all of its operands, its similarity in spelling to ^^ and the bitwise XOR operators (especially the historical one) could be problematic. To summarize: either bring ^^ and xor with more than two operands in line with the mathematical definition (possibly by just making them left-associative and rewriting the descriptions to match), or stop calling them exclusive or. -- Minimiscience
Re: XOR does not work that way.
On Jun 22, 2009, at 5:51 PM, Damian Conway wrote: Perl 6's approach to xor is consistent with the linguistic sense of 'xor' (You may have a soup (x)or a salad (x)or a cocktail), and also with the IEEE 91 standard for logic gates. I don't think natural language -- especially the abomination that is English -- is the best guide for understanding logical operations (why, yes, I *do* speak Lojban; how did you know?). As for consistency, Perl 6's bitwise exclusive-or operators follow the mathematical meaning of XOR, so using the exactly one true value definition for ^^ and xor would make Perl 6 inconsistent with itself. I was going to say more in support of adding a separate operator for exactly one true value, but Darren Duncan beat me to it. -- Minimiscience
