Re: [Haskell-cafe] Comments on Haskell 2010 Report
On 16:21 Fri 09 Jul , John Meacham wrote: I would think it is a typo in the report. Every language out there seems to think 0**0 is 1 and 0**y | y /= 0 is 0. I am not sure whether it is mandated by the IEEE standard but a quick review doesn't say they should be undefined (and the report mentions all the operations with undefined results) IEEE 754 has three different power operations. They are recommended operations, which means that supporting them is optional. pown only allows integral exponents, and the standard says the following: pown (x, 0) is 1 for any x (even a zero, quiet NaN, or infinity) pow handles integral exponents as a special case, and is similar: pow (x, ±0) is 1 for any x (even a zero, quiet NaN, or infinity) powr is defined as exp(y*log(x)). powr (±0, ±0) signals the invalid operation exception [NB: this means that the operation returns a quiet NaN]. In C, the pow function corresponds to the pow operation here, assuming the implementation conforms to annex F of the standard (an optional feature). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments on Haskell 2010 Report
On Jul 11, 2010, at 9:20 PM, Daniel Fischer wrote: * Prove the binomial theorem *without* the convention 0**0 := 1 Except that in the binomial theorem, one uses (^) and not (**). For (^), setting x ^ 0 = 1 is, as far as I'm aware, uncontested. This is not so: the exponent in the binomial theorem is a real number, not an integer. See http://mathworld.wolfram.com/BinomialTheorem.html Real numbers turn up in surprising places. I imagine most of us are familiar with the derivative operator D, and with iterations of it like second derivatives. But it's not just natural number powers of D that make sense; there are fractional derivatives, and D**(1/2) does find uses. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments on Haskell 2010 Report
On Sat, Jul 10, 2010 at 6:40 PM, Julian Fleischer julian.fleisc...@fu-berlin.de wrote: I guess I'm actually messing things up using the word natural - how can expand the multiplication of zero with itself zero times be natural? How could it not be? That is to say, what initial value would make sense for folding (*) over a list of numbers to compute the product? - C. p.s. -- [[mconcat]] = [[foldr mappend mempty]] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments on Haskell 2010 Report
On Sunday 11 July 2010 00:40:07, Julian Fleischer wrote:
Hi wren,
x**0 := 1, by convention.
[...]
So far as I'm aware, the x**0=1 vs 0**y=0 conflict leads to 0**0
[being] undefined
x**0 is 1 /by definition, 0**y naturally is 0, since (for example) 0**2
expands to 0*0 (being 0 of course).
But I would not want 0**(-1) to be 0, nor 0**(0 :+ 1) :: Complex Double.
0**y = 0 is the natural choice for positive real y or complex y with a
positive real part, not for all y.
(**) is quite a different beast from (^) or (^^). The latter two have a
natural interpretation as product of |n| copies of x (resp. reciprocal
thereof if n 0 for (^^)). (**) is more complicated.
So there is not a conflict of two
definitions, it's simply a definition somehow /overriding/ the natural
attempt. I guess I'm actually messing things up using the word natural
- how can expand the multiplication of zero with itself zero times be
natural?
[...] more helpful in mathematics.
/source-please
Try it yourself:
* Prove the binomial theorem *without* the convention 0**0 := 1
Except that in the binomial theorem, one uses (^) and not (**).
For (^), setting x ^ 0 = 1 is, as far as I'm aware, uncontested.
* Consider the function f(x) := x**0 - is it continuous (over the set of
natural numbers including zero)?
Continuity over the set of natural numbers is a non-issue, since usually
one chooses the discrete topology there, so let's consider x real.
But what about the function
p = \x y - x ** y
, where lim_{x - +0, y - +0} p x y doesn't exist?
Note: I, too, consider 0 ** 0 = 1 the best choice, and 0 ** y = 0 for
positive y. It's just not so clear cut, there are reasons to consider it
undefined.
Donald E. Knuth writes on the issue [1] (see page 6 of the generated
output), defending the position x**0 being 1.
Further: C99, Java define it that way. GHC does it that way.
Yay. Unfortunately, GHC uses the default method
x ** y = exp (y * log x)
for complex numbers, so
Prelude Data.Complex 0 ** 0 :: Complex Double
NaN :+ NaN
Prelude Data.Complex 0 ** 1 :: Complex Double
NaN :+ NaN
:sigh:
Possibly the default method is the reason for making 0 ** y undefined.
And hugs:
Hugs 0 ** 0 :: Double
Program error: argument out of range
Hugs 0 ** 1 :: Double
Program error: argument out of range
Standard Prelude of Haskell 98 Report defines ^ (** for natural numbers)
as x ^ 0 = 1 [sic] The convention is also used in 6.4.3: The value of
x^0 or x^^0 is 1 for any x, including zero [2]
I know it's about ^ in that section, but why should x^0 be 1 and x**0
be undefined? (or: is the natural zero not the real zero?)
Exponentiation with integer exponents isn't the same as exponentiation with
arbitrary real (or complex) exponents.
Nevertheless, it is desirable that the latter be an extension of the
former.
greetings,
Julian
[1] http://www-cs-faculty.stanford.edu/~knuth/papers/tnn.tex.gz
[2] http://www.haskell.org/onlinereport/basic.html#sect6.4.3
Cheers,
Daniel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments on Haskell 2010 Report
Hi wren, x**0 := 1, by convention. [...] So far as I'm aware, the x**0=1 vs 0**y=0 conflict leads to 0**0 [being] undefined x**0 is 1 /by definition, 0**y naturally is 0, since (for example) 0**2 expands to 0*0 (being 0 of course). So there is not a conflict of two definitions, it's simply a definition somehow /overriding/ the natural attempt. I guess I'm actually messing things up using the word natural - how can expand the multiplication of zero with itself zero times be natural? [...] more helpful in mathematics. /source-please Try it yourself: * Prove the binomial theorem *without* the convention 0**0 := 1 * Consider the function f(x) := x**0 - is it continuous (over the set of natural numbers including zero)? Donald E. Knut writes on the issue [1] (see page 6 of the generated output), defending the position x**0 being 1. Further: C99, Java define it that way. GHC does it that way. Standard Prelude of Haskell 98 Report defines ^ (** for natural numbers) as x ^ 0 = 1 [sic] The convention is also used in 6.4.3: The value of x^0 or x^^0 is 1 for any x, including zero [2] I know it's about ^ in that section, but why should x^0 be 1 and x**0 be undefined? (or: is the natural zero not the real zero?) greetings, Julian [1] http://www-cs-faculty.stanford.edu/~knuth/papers/tnn.tex.gz [2] http://www.haskell.org/onlinereport/basic.html#sect6.4.3 smime.p7s Description: S/MIME cryptographic signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments on Haskell 2010 Report
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/8/10 22:25 , Alex Stangl wrote: 1. I.E. and e.g. should be followed by commas -- unless UK usage differs from US standards. (Page 3 and elsewhere, although FFI chapter I don't think I've ever seen them *followed* by commas. Preceded, always. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw3LQoACgkQIn7hlCsL25WpzACgiBSLqdueABWArQyQLbWBPrrs dKkAoJHA0u65jLLaZqizJM1dPLPtVLXt =pwq4 -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments on Haskell 2010 Report
On Fri, 09 Jul 2010 10:07:06 -0400, you wrote: I don't think I've ever seen them *followed* by commas. Preceded, always. In American English, they're always followed by commas, and preceded by comma, semicolon, dash or left parenthesis, depending on the specific context. Examples from various online style guides: I am the big cheese, i.e., the boss. The department is unattached; i.e., it is not administered by one of the schools or colleges. Most committee members-i.e., those who were willing to speak out-wanted to reject the plan. Most committee members (i.e., those who were willing to speak out) wanted to reject the plan. See also: http://www.videojug.com/film/how-to-use-ie-and-eg -Steve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments on Haskell 2010 Report
On Fri, Jul 9, 2010 at 16:23, Steve Schafer wrote: On Fri, 09 Jul 2010 10:07:06 -0400, brandon s. allbery wrote: I don't think I've ever seen them *followed* by commas. Preceded, always. In American English, they're always followed by commas, and preceded by comma, semicolon, dash or left parenthesis, depending on the specific context. One of the nice things about English is that there is often never an always. See http://grammar.quickanddirtytips.com/ie-eg-oh-my.aspx for a discussion. (For me personally, I prefer to minimize the juxtapositions of punctuation (e.g. . and ,). As long as there's not an editor looking over my shoulder telling me it's not acceptable, I will continue to do so.) As for future editions of the Haskell Report, one possibility to eliminate concerns about spelling and grammar would be to decide to follow a certain dialect and style. This would reduce the number of comma-related comments. Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments on Haskell 2010 Report
On Fri, 9 Jul 2010 17:14:31 +0200, you wrote: One of the nice things about English is that there is often never an always. See http://grammar.quickanddirtytips.com/ie-eg-oh-my.aspx for a discussion. Well, that page pretty much confirms what I said. In AMERICAN English, they're always followed by commas. The two sources mentioned on that page that suggest omitting the commas (Fowler's and Oxrford) are both based on UK English. -Steve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments on Haskell 2010 Report
On Fri, Jul 9, 2010 at 18:35, Steve Schafer wrote: On Fri, 9 Jul 2010 17:14:31 +0200, Sean Leather wrote: One of the nice things about English is that there is often never an always. See http://grammar.quickanddirtytips.com/ie-eg-oh-my.aspx for a discussion. Well, that page pretty much confirms what I said. In AMERICAN English, they're always followed by commas. The two sources mentioned on that page that suggest omitting the commas (Fowler's and Oxrford) are both based on UK English. And yet most of the other manuals describe the rule as usually, preferable/optional, and makes good sense. That refutes your claim that they're always followed by commas. ;) Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments on Haskell 2010 Report
I don't know what the rule is, but I personally just replace i.e. with that is and e.g. with for example in my head, and then apply whatever punctuation makes sense with those substitutions. Cheers, Greg On 7/9/10 12:17 PM, Sean Leather wrote: On Fri, Jul 9, 2010 at 18:35, Steve Schafer wrote: On Fri, 9 Jul 2010 17:14:31 +0200, Sean Leather wrote: One of the nice things about English is that there is often never an always. See http://grammar.quickanddirtytips.com/ie-eg-oh-my.aspx for a discussion. Well, that page pretty much confirms what I said. In AMERICAN English, they're always followed by commas. The two sources mentioned on that page that suggest omitting the commas (Fowler's and Oxrford) are both based on UK English. And yet most of the other manuals describe the rule as usually, preferable/optional, and makes good sense. That refutes your claim that they're always followed by commas. ;) Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments on Haskell 2010 Report
Hi, 8. [...] Saying 0**0 is undefined seems reasonable, but why 0**y? I agree on 0**y being 0 (not undefined), but why should 0**0 be undefined? x**0 := 1, by convention. Of course this is a still ongoing debate (regarding analysis of functions etc.), but the most usefull approach for /any/ programming language (and BTW for many mathematical proofs, too). -Julian smime.p7s Description: S/MIME cryptographic signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments on Haskell 2010 Report
On Sat, Jul 10, 2010 at 12:12:15AM +0200, Julian Fleischer wrote: 8. [...] Saying 0**0 is undefined seems reasonable, but why 0**y? I agree on 0**y being 0 (not undefined), but why should 0**0 be undefined? x**0 := 1, by convention. Of course this is a still ongoing debate (regarding analysis of functions etc.), but the most usefull approach for /any/ programming language (and BTW for many mathematical proofs, too). Hi Julian, Glad somebody responded about something other than e.g. and i.e. I wasn't arguing that 0**0 *ought* to be undefined, but that it is a reasonable policy, since, as you point out, it's a matter of ongoing debate. What I don't understand is why for y /= 0, 0**y would be undefined. Maybe the discontinuity at zero is undesirable. Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments on Haskell 2010 Report
On Fri, Jul 09, 2010 at 06:07:04PM -0500, Alex Stangl wrote: I wasn't arguing that 0**0 *ought* to be undefined, but that it is a reasonable policy, since, as you point out, it's a matter of ongoing debate. What I don't understand is why for y /= 0, 0**y would be undefined. Maybe the discontinuity at zero is undesirable. I would think it is a typo in the report. Every language out there seems to think 0**0 is 1 and 0**y | y /= 0 is 0. I am not sure whether it is mandated by the IEEE standard but a quick review doesn't say they should be undefined (and the report mentions all the operations with undefined results), if anything it should be left for instances to decide based on the underlying algebra of the specific type and the report shouldn't mention it. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments on Haskell 2010 Report
Brandon S Allbery KF8NH allb...@ece.cmu.edu writes: On 7/8/10 22:25 , Alex Stangl wrote: 1. I.E. and e.g. should be followed by commas -- unless UK usage differs from US standards. (Page 3 and elsewhere, although FFI chapter I don't think I've ever seen them *followed* by commas. Preceded, always. Agreed. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments on Haskell 2010 Report
On 10 July 2010 01:22, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Brandon S Allbery KF8NH allb...@ece.cmu.edu writes: On 7/8/10 22:25 , Alex Stangl wrote: 1. I.E. and e.g. should be followed by commas -- unless UK usage differs from US standards. (Page 3 and elsewhere, although FFI chapter I don't think I've ever seen them *followed* by commas. Preceded, always. From The Haskell 98 Library Report: partition takes a predicate and a list and returns a pair of lists: those elements of the argument list that do and do not satisfy the predicate, respectively; i.e., [...] I don't think you should bother nitpicking about commas here. As Gregory said, anywhere there is i.e., you can substitute it for that is. Consider if the spec. was written with that is instead of i.e., would you then criticise where and where not commas are used? Does this arbitrary prescription really matter? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments on Haskell 2010 Report
Julian Fleischer wrote: Hi, 8. [...] Saying 0**0 is undefined seems reasonable, but why 0**y? I agree on 0**y being 0 (not undefined), but why should 0**0 be undefined? x**0 := 1, by convention. I'm not familiar with that convention. So far as I'm aware, the x**0=1 vs 0**y=0 conflict leads to 0**0 being best handled as undefined. That is, I've not seen any arguments supporting either solution as somehow more natural or more helpful in mathematics. /source-please -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments on Haskell 2010 Report
Christopher Done wrote:
On 10 July 2010 01:22, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote:
Brandon S Allbery KF8NH allb...@ece.cmu.edu writes:
On 7/8/10 22:25 , Alex Stangl wrote:
1. I.E. and e.g. should be followed by commas -- unless UK usage
differs from US standards. (Page 3 and elsewhere, although FFI chapter
I don't think I've ever seen them *followed* by commas. Preceded,
always.
From The Haskell 98 Library Report:
partition takes a predicate and a list and returns a pair of lists: those
elements of the argument list that do and do not satisfy the predicate,
respectively; i.e., [...]
I don't think you should bother nitpicking about commas here. As
Gregory said, anywhere there is i.e., you can substitute it for
that is. Consider if the spec. was written with that is instead of
i.e., would you then criticise where and where not commas are used?
Does this arbitrary prescription really matter?
This is LaTeX folks! All prescriptivism can be solved by judicious use
of macros. Honestly, for dealing with all the different journals' style
guides, stuff like this should be standard fare for mere punctuation
differences:
\NeedsTeXFormat{LaTeX2e}
\ProvidesPackage{latin}[2010/07/09 resolve style disputes]
\RequirePackage{xspace}
\newif...@comma
\...@commatrue
\declareoption{comma...@commatrue}
\declareoption{nocomma...@commafalse}
\ProcessOptions
% According to most style guides we should not italicize common
% Latin, since it needlessly draws attention to unimportant text.
% For declarativity we specify this command so that clients can
% choose to italicize if desired.
\newcommand{\latin}[1]{#1}
\newcommand{\.}{% Or choose another name if you please
\...@comma
.,\xspace
\else
.\,
\fi
}
\newcommand{\Cf}{\latin{Cf}\.}
\newcommand{\cf}{\latin{cf}\.}
\newcommand{\Eg}{\latin{E.g}\.}
\newcommand{\eg}{\latin{e.g}\.}
\newcommand{\Ie}{\latin{I.e}\.}
\newcommand{\ie}{\latin{i.e}\.}
--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Comments on Haskell 2010 Report
based upon final version PDF created 7/6/2010 11:44:27 1. I.E. and e.g. should be followed by commas -- unless UK usage differs from US standards. (Page 3 and elsewhere, although FFI chapter seems to have the commas.) Also, inconsistent mix of British and American usage throughout (-ize and -ise, flavour, behaviour, behavior, analyse, color, colour, finaliser, finalizer, etc.) 2. Inconsistent spelling (lowercase/uppercase in section 1.4; lower-case/upper-case in section 2.4) 3. In section 3.11, boolean misspelled boolen. 4. LaTeX macros involving @ showing up in text. See sects 3.12, 6.4.2, 11.1, and in Chapter 9. 5. In section 3.15.2, reference to third bullet seems like it should be fourth bullet. 6. In section 3.17.2, the example that is supposed to return [undefined,undefined,undefined] seems like it really ought to return undefined, although I can see in the description above for ~apat matching where the other interpretation would hold. I actually tried this in GHC 10.4.2, binding the result to a variable and then applying the function length to it, and it comes back with undefined, whereas performing length [undefined,undefined,undefined] returns 3. So it appears that in this case, at least GHC 10.4.2 is returning undefined rather than [undefined,undefined,undefined]. 7. In section 6.3.4, [LT..] needs whitespace in the middle to parse correctly. 8. I'm curious about last part of section 6.4.3 that says 0**y is undefined. It seems to work reasonably under GHC, returning 0 in every case except 0**0, which returns 1 (the ^0 == 1 rule taking precedence, apparently.) Saying 0**0 is undefined seems reasonable, but why 0**y? 9. In section 6.4.6, statement about b^(d-1) = m b^d doesn't seem to hold when m 0. Should it be |m| in the equation, rather than m? 10. Section 7.1 uses function in places where it ought to use action. It seems more correct to describe print as returning an action that outputs a value. Most of the Input Functions (e.g., getChar, getLine, getContents, readLn) should be described as actions, not functions. It switches to using the term operation, which seems better, but then reverts back to function. 11. In section 8.4, variable misspelled varibale. 12. In section 8.5.1, in we require that chname ends on .h, on should be in. 13. Also in section 8.5.1, dependent misspelled dependant. 14. Last paragraph of section 8.5,1 has extra a -- ... defined to a accept a Following sentence has a semicolon where it should have a comma. 15. In section 10.3, (i.e. the programmer... has no closing paren. 16. In section 10.4, ... other lines are comment, comments sounds better. This occurs twice. 17. Also in section 10.6, anything misspelled anyything. 18. In Chapter 15, it would be more clear to describe bit i as producing a value with the ith bit set, and all other bits clear. 19. In section 20.3.1, caveats about finiteness of lists similar to ones given for and and or could also apply to any and all. Ditto for elem, notElem, etc. Maybe a single paragraph could summarize this short-circuiting behavior for all of them. 20. In heading for 20.9.2, quotes around Set are not balanced. Both are closing quotes. Ditto for 20.10.1, 20.10.2. 21. In section 29.1.1, finaliser and finalizer used in same paragraph. 22. In section 38.2, first occurrence of 'dual' has mismatched quotes. 23. In section 41.1, quotes around perform are mismatched. Word function is mildly misused again here. 24. In section 41.3.1, it would be nice to document what happens if act terminates abnormally, and then a secondary exception occurs during the closing of the handle. Oftentimes systems lose the primary exception and propagate out the secondary exception, whereas in reality we may be more interested in the original primary exception. 25. In section 41.4.4, bullet before isPermissionError isn't rendered correctly. Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
