> > > six hundred sixty-nine million, one hundred fifty-five thousand, three > > > hundred eighty-six and three tenths
> > That's true in US English. It's not true in British English. > > In the absence of a clear indication of which variety of English > > Pascal was intending to write, it's not reasonable to dismiss > > what he wrote as "wrong".
[Pascal:]
> I don't know, what are the difference in English and US numbers? But > it does not matter, at least lisp ~R is consistent and it parsed the > numbers and formated the output in the same language.
British English puts an "and" in the construction "--- hundred and ---" where US English doesn't. At one time British English defined 1 million = 10^6, 1 billion = 10^12, 1 trillion = 10^18, etc, but now just about everyone in the UK uses the US convention that 1 thousand = 10^3, 1 million = 10^6, 1 billion = 10^9, 1 trillion = 10^12, etc. There might be some minor differences in hyphenation or something, but that's basically it.
I have been informed that the British have taken up bad habits from American English and use «billion» to refer to both «thousand million» and «million million» with no other way to distinguish them than to think about the values and reject one of the two meanings intuitively.
This and the Fred Flintstone Units ought to relegate English to the garbage dump of history. Just re-elect George W. Bush and be done with it, OK?
-- Erik Naggum, disillusioned in Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <e...@naggum.no> writes: > I have been informed that the British have taken up bad habits from > American English and use «billion» to refer to both «thousand million» > and «million million» with no other way to distinguish them than to > think about the values and reject one of the two meanings intuitively.
I can't remember the last time I heard "billion" used to mean "million million", so I don't think this is a serious practical problem. It's ugly, though.
> This and the Fred Flintstone Units ought to relegate English to the > garbage dump of history. Just re-elect George W. Bush and be done > with it, OK?
Re-electing Dubya might consign too many other things to the garbage dump of history, or for that matter to any convenient garbage dump, so despite the antiquaronian charmulation of his peculiatory manner of speakitude I'm not inclined to accept your suggestion. Anyway, there's not a whole lot I can do to get him elected or unelected. (If his first "election" is anything to go by, there may not be much any voter can do.)
Um. I've been involved in one political flamefest in c.l.l already this month. I'd better stop.
* Erik Naggum wrote: > I have been informed that the British have taken up bad habits from > American English and use «billion» to refer to both «thousand million» > and «million million» with no other way to distinguish them than to > think about the values and reject one of the two meanings intuitively.
I don't think we do that. I think we've changed from an old convention where a billion was a million million to a new one where a billion is a thousand million. There has probably been (well: has certainly been) some confusion during the change, and there are no doubt holdouts who insist on the old usage, but I don't think that both usages can be used at once.
Erik Naggum <e...@naggum.no> writes: > * Pascal Bourguignon > | I don't know, what are the difference in English and US numbers?
> The English-speaking part of the world have enormous problem counting > any higher than 20, which explains their Fred Flintstone Units and > their irrational resistance to units
Irrational?! The english standard of measurement is nothing *but* rational:
1/8 mile per furlong 1/10 furlong per chain 1/4 chain per rod 1/25 rod per link 50/11 links per yard 1/3 yard per foot 1/12 foot per inch 1/3 inch per barleycorn
> >> "six hundred and sixty-nine million, one hundred and fifty-five thousand, > >> three hundred and eighty-six"
> > FWIW, the above output is wrong - "and" should only be used between the > > whole number and fractional parts, e.g.
> > six hundred sixty-nine million, one hundred fifty-five thousand, three > > hundred eighty-six and three tenths
> That's true in US English. It's not true in British English. > In the absence of a clear indication of which variety of English > Pascal was intending to write, it's not reasonable to dismiss > what he wrote as "wrong".
We're talking about ANSI Common Lisp. These US centric conventions are only to be expected - the "A" in ANSI is for "American" after all, and ANSI's "mission is to enhance both the global competitiveness of U.S. business and the U.S. quality of life by promoting and facilitating voluntary consensus standards and conformity assessment systems, and safeguarding their integrity."
That quote makes me sound rather jingoistic (FWIW I'm not - I oppose the Bush manufactured war in Iraq for example) but this is simply a matter of portability and standard conformance. Pascal's code is broken under a strictly conforming implementation since the input string will never be string-equal to that generated by the do loop when the input string is greater than 99 in US English (as one would expect with *ANSI* Common Lisp) and the implementation outputs UK English for ~r directives.
It makes little sense for a format directive in the ANSI standard to use UK English for formatting integers to words.
So this is not really Pascal's fault- I think his implementation is non conforming. Under sbcl, or OpenMCL, I get no "and" between whole number groups. Under clisp, and LispWorks however, I do, so I conclude that he is using an implementation that is non conforming in this respect.
Execute this: (format t "~r" '123456789) and you'll know whether your implementation gets this right or not.
> Re-electing Dubya might consign too many other things to the > garbage dump of history, or for that matter to any convenient > garbage dump, so despite the antiquaronian charmulation of > his peculiatory manner of speakitude I'm not inclined to > accept your suggestion. Anyway, there's not a whole lot I > can do to get him elected or unelected. (If his first "election" > is anything to go by, there may not be much any voter can do.)
> Um. I've been involved in one political flamefest in c.l.l > already this month. I'd better stop.
A little consistency, please! You and Joe with your interminable discussion of headscarf education have created the illusion that c.l.l. is a fine place to swap recipes for vegetables and debate American presidential politics (so you cannot claim it is of interest to anyone but the candidates, whom I have not seen here lately) and anything else you spot in the morning paper. Don't stop now, just as you are on the verge of success. One or two more threads like the one on math education and the precedent will be firmly in place, and there will be no danger anyone getting curious about Lisp will find here anything other than a bunch of self-appointed experts spouting endlessly on everything but Lisp. They will conclude they were right in the first place, Lisp is dead, can't even support a proper newsgroup.
Hey, what do you think, is it for real this time, the Ben&Jen breakup
:)?
kenny
ps. Three hundred words on dubbya followed by "I'd better stop" is what we call a non-stopping stop.
k
--
clinisys, inc http://www.tilton-technology.com/ --------------------------------------------------------------- "[If anyone really has healing powers,] I would like to call them about my knees." -- Tenzin Gyatso, the Fourteenth Dalai Lama
>> That's true in US English. It's not true in British English. >> In the absence of a clear indication of which variety of English >> Pascal was intending to write, it's not reasonable to dismiss >> what he wrote as "wrong".
> We're talking about ANSI Common Lisp. These US centric conventions are > only to be expected - the "A" in ANSI is for "American" after all, and > ANSI's "mission is to enhance both the global competitiveness of U.S. > business and the U.S. quality of life by promoting and facilitating > voluntary consensus standards and conformity assessment systems, and > safeguarding their integrity." ... > It makes little sense for a format directive in the ANSI standard to > use UK English for formatting integers to words.
The ANSI standard does not mandate that ~R produce output in US English rather than British English. You might as well argue that CLISP is non-conformant because it displays a menorah at startup and the menorah is a Jewish rather than an American symbol.
(Note: There was a lengthy thread about whether it's a Bad Thing that CLISP displays a menorah, earlier this year; let's not revisit that. I hope you agree that it's clearly not a violation of conformance.)
The standard is, in fact, very unspecific about just what ~R should do with large numbers. I can only assume that it's deliberately so. CLTL2 (of interest as a historical document, at least) goes into a bit more detail, indicating that its author did not consider that there is only one right way for ~R to render numbers in "English" and did consider it worth not ignoring British English when deciding what conventions to use.
Gareth McCaughan <gareth.mccaug...@pobox.com> writes: > The ANSI standard does not mandate that ~R produce output in US > English rather than British English. You might as well argue that > CLISP is non-conformant because it displays a menorah at startup and > the menorah is a Jewish rather than an American symbol.
Who knows -- if the ANSI Standard was written by good Christians, there would be 12 special operators, not 25, of course.
Identifying, excruciating and bonfiring the Satanic Special Operators is left as an exercise for the Schemers.
Regards, -- Nils Gösche "Don't ask for whom the <CTRL-G> tolls."
Gareth McCaughan <gareth.mccaug...@pobox.com> writes: > Raffael Cavallaro <raffaelcavall...@junk.mail.me.not.mac.com> writes: >> FWIW, the above output is wrong - "and" should only be used between the >> whole number and fractional parts, e.g. > That's true in US English. It's not true in British English.
FWIW, it's not even universally accepted in US English. School teachers in some areas (at some times) pushed it strongly, others don't care.
-- Alan Shutko <a...@acm.org> - I am the rocks. Before the Borg, there were the fundies.
Nils Goesche <car...@cartan.de> writes: > Who knows -- if the ANSI Standard was written by good Christians, > there would be 12 special operators, not 25, of course.
> Identifying, excruciating and bonfiring the Satanic Special Operators > is left as an exercise for the Schemers.
Gareth McCaughan <gareth.mccaug...@pobox.com> wrote in message <news:87fze6qz0u.fsf@g.mccaughan.ntlworld.com>... > The ANSI standard does not mandate that ~R produce output in > US English rather than British English.
<sarcasm>It doesn't specifically exclude 1337 sp34k either, so I guess that would be conforming as well.</sarcasm> Again, it is just bizarre to assume that the format conventions in the ANSI standard should be UK English, and not US English, since ANSI is a US standards body.
> You might as well > argue that CLISP is non-conformant because it displays a > menorah at startup and the menorah is a Jewish rather than > an American symbol.
So you hope here to associate me with the anti-Semites who posted to that thread? I avoided that one intentionally, but as far as I'm concerned, the maintainers of clisp have every right to print whatever welcome banner they want - they could even print quotations from the Torah in Hebrew, or access your sound card and start playing havah nagilah if they like. They have graciously provided an extremely portable common lisp implementation for free (in both senses), so I am merely grateful to them, whatever welcome banner they choose to present.
I do however believe that US English for ~r format directives would be more conforming than their current use of UK English. Ditto LispWorks.
Gareth McCaughan <gareth.mccaug...@pobox.com> writes: > > It makes little sense for a format directive in the ANSI standard to > > use UK English for formatting integers to words.
> The ANSI standard does not mandate that ~R produce output in > US English rather than British English. You might as well > argue that CLISP is non-conformant because it displays a > menorah at startup and the menorah is a Jewish rather than > an American symbol.
> (Note: There was a lengthy thread about whether it's > a Bad Thing that CLISP displays a menorah, earlier this > year; let's not revisit that. I hope you agree that it's > clearly not a violation of conformance.)
> The standard is, in fact, very unspecific about just what ~R > should do with large numbers. I can only assume that it's > deliberately so. CLTL2 (of interest as a historical document, > at least) goes into a bit more detail, indicating that its > author did not consider that there is only one right way for > ~R to render numbers in "English" and did consider it worth > not ignoring British English when deciding what conventions > to use.
It would have been neat if conforming lisps would have been allowed to use as output language for the ~R directive the i18n-specified language for that platform, eg on Unix it would use language information from the LC_*/LANG environment variables. Sadly, such an extension would be non-conforming though, since the standard explicitly mentions English. :-(
> > > It makes little sense for a format directive in the ANSI standard to > > > use UK English for formatting integers to words.
> > The ANSI standard does not mandate that ~R produce output in > > US English rather than British English. You might as well > > argue that CLISP is non-conformant because it displays a > > menorah at startup and the menorah is a Jewish rather than > > an American symbol.
> > (Note: There was a lengthy thread about whether it's > > a Bad Thing that CLISP displays a menorah, earlier this > > year; let's not revisit that. I hope you agree that it's > > clearly not a violation of conformance.)
> > The standard is, in fact, very unspecific about just what ~R > > should do with large numbers. I can only assume that it's > > deliberately so. CLTL2 (of interest as a historical document, > > at least) goes into a bit more detail, indicating that its > > author did not consider that there is only one right way for > > ~R to render numbers in "English" and did consider it worth > > not ignoring British English when deciding what conventions > > to use.
> It would have been neat if conforming lisps would have been allowed to > use as output language for the ~R directive the i18n-specified > language for that platform, eg on Unix it would use language > information from the LC_*/LANG environment variables. Sadly, such an > extension would be non-conforming though, since the standard > explicitly mentions English. :-(
Ah, there's a loophole--*English* doesn't have a standard!
>> The ANSI standard does not mandate that ~R produce output in >> US English rather than British English.
> <sarcasm>It doesn't specifically exclude 1337 sp34k either, so I guess > that would be conforming as well.</sarcasm>
Gosh, I'm glad you put that inside <sarcasm /> tags; I'd never have noticed otherwise. If there's a serious point there, I'm unable to work out what it is. (Unless you think that the variety of English spoken and written in, um, England, is as far from being correctly called "English" simpliciter as 1337 5p34k is.)
> Again, it is just bizarre to assume that the format conventions in the > ANSI standard should be UK English, and not US English, since ANSI is > a US standards body.
I didn't say that they *should be* UK English and not US English. I said that they *may be* if the implementors choose it, at any point where that is permitted by the standard.
I'll go further out on a limb and mention my shocking opinion that it is not wrong for localized versions of CL implementations to be produced, that generate (for instance) error messages in a language other than English. Nor is it wrong for companies not based in the US to make money out of selling CL implementations, despite your astute observation that ANSI exists to further the interests of US businesses.
Oh, sorry, should I have wrapped that in "<sarcasm>...</sarcasm>"?
>> You might as well >> argue that CLISP is non-conformant because it displays a >> menorah at startup and the menorah is a Jewish rather than >> an American symbol.
> So you hope here to associate me with the anti-Semites who posted to > that thread?
No: I have absolutely no such intention. (Nor, for the record, do I think that wishing CLISP didn't display a menorah at startup implies anti-semitism.)
> I avoided that one intentionally, but as far as I'm > concerned, the maintainers of clisp have every right to print whatever > welcome banner they want - they could even print quotations from the > Torah in Hebrew, or access your sound card and start playing havah > nagilah if they like. They have graciously provided an extremely > portable common lisp implementation for free (in both senses), so I am > merely grateful to them, whatever welcome banner they choose to > present.
Good; we are agreed.
> I do however believe that US English for ~r format directives would be > more conforming than their current use of UK English. Ditto LispWorks.
I think you are using "conforming" in a very strange sense.
> > The standard is, in fact, very unspecific about just what ~R > > should do with large numbers. I can only assume that it's > > deliberately so. CLTL2 (of interest as a historical document, > > at least) goes into a bit more detail, indicating that its > > author did not consider that there is only one right way for > > ~R to render numbers in "English" and did consider it worth > > not ignoring British English when deciding what conventions > > to use.
[Björn:]
> It would have been neat if conforming lisps would have been allowed to > use as output language for the ~R directive the i18n-specified > language for that platform, eg on Unix it would use language > information from the LC_*/LANG environment variables. Sadly, such an > extension would be non-conforming though, since the standard > explicitly mentions English. :-(
Yep. But I think it might be allowable to have a special mode in which ~R uses the local language. Just make sure it's triggered by something whose effects are explicitly undefined by the standard :-).
Tim Bradshaw <t...@cley.com> writes: > * Erik Naggum wrote: > > I have been informed that the British have taken up bad habits from > > American English and use «billion» to refer to both «thousand million» > > and «million million» with no other way to distinguish them than to > > think about the values and reject one of the two meanings intuitively.
> I don't think we do that. I think we've changed from an old > convention where a billion was a million million to a new one where a > billion is a thousand million. There has probably been (well: has > certainly been) some confusion during the change, and there are no > doubt holdouts who insist on the old usage, but I don't think that > both usages can be used at once.
If that's so, perhaps that's the reason why Beagle 2 is not responding!
-- __Pascal_Bourguignon__ http://www.informatimago.com/ There is no worse tyranny than to force a man to pay for what he doesn't want merely because you think it would be good for him.--Robert Heinlein http://www.theadvocates.org/
> [various other people:] > > > > six hundred sixty-nine million, one hundred fifty-five thousand, three > > > > hundred eighty-six and three tenths
> > > That's true in US English. It's not true in British English. > > > In the absence of a clear indication of which variety of English > > > Pascal was intending to write, it's not reasonable to dismiss > > > what he wrote as "wrong".
> [Pascal:] > > I don't know, what are the difference in English and US numbers? But > > it does not matter, at least lisp ~R is consistent and it parsed the > > numbers and formated the output in the same language.
> British English puts an "and" in the construction "--- hundred and ---" > where US English doesn't. At one time British English defined > 1 million = 10^6, 1 billion = 10^12, 1 trillion = 10^18, etc, > but now just about everyone in the UK uses the US convention that > 1 thousand = 10^3, 1 million = 10^6, 1 billion = 10^9, 1 trillion = > 10^12, etc. > There might be some minor differences in hyphenation or something, but > that's basically it.
~nR prints arg in radix n. The modifier flags and any remaining parameters are used as for the ~D directive. ~D is the same as ~10R. The full form is ~radix,mincol,padchar,commachar,comma-intervalR.
If no prefix parameters are given to ~R, then a different interpretation is given. The argument should be an integer. For example, if arg is 4:
* ~R prints arg as a cardinal English number: four.
* ~:R prints arg as an ordinal English number: fourth.
* ~@R prints arg as a Roman numeral: IV.
* ~:@R prints arg as an old Roman numeral: IIII.
Did it means that any kind of English is good, or should Oxford English be used or New York English or Canberra English?
Clisp sounds schizophrenic:
[15]> (format t "~R~%" 1000000110) one billion, one hundred and ten NIL
or really up to date if really England usage now is to use billion for 1e9.
SBCL, cmucl and openmcl sound American:
* (format t "~R~%" 1000000110) one billion one hundred ten NIL
Perhaps of just refering to "English number" it should have specified explicitely the rules to generate the string from the numbers?
-- __Pascal_Bourguignon__ http://www.informatimago.com/ There is no worse tyranny than to force a man to pay for what he doesn't want merely because you think it would be good for him.--Robert Heinlein http://www.theadvocates.org/
> [I said:] > >> That's true in US English. It's not true in British English. > >> In the absence of a clear indication of which variety of English > >> Pascal was intending to write, it's not reasonable to dismiss > >> what he wrote as "wrong".
> > We're talking about ANSI Common Lisp. These US centric conventions are > > only to be expected - the "A" in ANSI is for "American" after all, and > > ANSI's "mission is to enhance both the global competitiveness of U.S. > > business and the U.S. quality of life by promoting and facilitating > > voluntary consensus standards and conformity assessment systems, and > > safeguarding their integrity."
No jingoism, that's just what standards are about. :-)
> ... > > It makes little sense for a format directive in the ANSI standard to > > use UK English for formatting integers to words.
> The ANSI standard does not mandate that ~R produce output in > US English rather than British English. You might as well > argue that CLISP is non-conformant because it displays a > menorah at startup and the menorah is a Jewish rather than > an American symbol.
> (Note: There was a lengthy thread about whether it's > a Bad Thing that CLISP displays a menorah, earlier this > year; let's not revisit that. I hope you agree that it's > clearly not a violation of conformance.)
> The standard is, in fact, very unspecific about just what ~R > should do with large numbers. I can only assume that it's > deliberately so. CLTL2 (of interest as a historical document, > at least) goes into a bit more detail, indicating that its > author did not consider that there is only one right way for > ~R to render numbers in "English" and did consider it worth > not ignoring British English when deciding what conventions > to use.
In that case, they should have specified "human language" and localization, and stuff like that. (I'd be happy to be able to setf some global variable to get "un billion" for 1e12). Since they did not, I would interpret it to be requiring strict American English output. (And indeed clisp, being of European origin uses wrongly a mix of American and British English here).
-- __Pascal_Bourguignon__ http://www.informatimago.com/ There is no worse tyranny than to force a man to pay for what he doesn't want merely because you think it would be good for him.--Robert Heinlein http://www.theadvocates.org/
> >> FWIW, the above output is wrong - "and" should only be used between the > >> whole number and fractional parts, e.g.
> > That's true in US English. It's not true in British English.
> FWIW, it's not even universally accepted in US English. School > teachers in some areas (at some times) pushed it strongly, others > don't care.
Why did they not specify French? At least, in France we have normalizing organizations that edict formal rules to write numbers unequivocally (and units too), and these rules are official and published in the Journal Officiel (where all French Laws have to be published to be appliable).
-- __Pascal_Bourguignon__ http://www.informatimago.com/ There is no worse tyranny than to force a man to pay for what he doesn't want merely because you think it would be good for him.--Robert Heinlein http://www.theadvocates.org/
* Björn Lindberg | It would have been neat if conforming lisps would have been allowed to | use as output language for the ~R directive the i18n-specified | language for that platform, eg on Unix it would use language | information from the LC_*/LANG environment variables.
Focusing only on the ~R is myopic. How about ~P?
I am opposed to the whole localization and internationalization mess, as it is done at the wrong level. Instead of making programs use some strings instead of some other strings, the properly language-oriented approach uses a /protocol/ that results in improved user interaction when the user interface module communicates with the user. If this protocol was properly written and published, and I do /not/ mean APIs, users could write their own user interaction modules and could run the software and the user agent on different computers if they wanted to. The WWW could have offered this separation, but the promise of Java was never realized on the client side and today's user interaction is still controlled almost entirely by the server. In order to design protocols that it is possible to interact with, programmers need to think in very different terms from designing the user interaction as part of the application, and not having to do this is the lure of the string-replacing method. It is all very depressing that programming has never evolved as a discipline that could keep the user interface out of the application «logic», for these days, there is almost no real software development since everybody are working on irrelevant parts of the application.
-- Erik Naggum | Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
>>>>> On 24 Jan 2004 08:16:40 +0000, Erik Naggum ("Erik") writes:
Erik> Instead of making programs use some strings instead of some Erik> other strings, the properly language-oriented approach uses a Erik> /protocol/ that results in improved user interaction when the Erik> user interface module communicates with the user. If this Erik> protocol was properly written and published, and I do /not/ Erik> mean APIs, users could write their own user interaction Erik> modules and could run the software and the user agent on Erik> different computers if they wanted to.
Erik> It is all very depressing that programming has never evolved Erik> as a discipline that could keep the user interface out of the Erik> application «logic», for these days
This is, in a general sense, the kind of problem that the presentation system of CLIM is supposed to be about.
Rather than the main application programmer writing
(format t "~&~R lossage~:P" n-lossages)
he would instead define a LOSSAGE presentation type.
Then the GUI programmer would write the PRESENT methods, multi-dispatched on the LOSSAGE class and a LOCALE.
However, that's not really how most CLIM (or DW) code that I've seen was written. Graphical based presentations are like that, but things about text were not abstracted as far.
Adam Warner <use...@consulting.net.nz> writes: > Hi Timothy Moore,
>> If you want presentation types, you know where to find them: CLIM. The >> presentation type information is explicit in the program but implicit on >> the display.
> Thanks for the tip Timothy. I haven't used CLIM and I wasn't consciously > (mis)appropriating the term.
It's not really a misappropriation at all. You're describing exactly what presentation types are for. That is, they have no relevance to the processing of objects, merely to the way in which you'd like to display it in some part of some user interface. Of course, a presentation is not the number that it is displaying. You can't add a presentation of an integer in hex format to another one, but you could define a presentation-g-f that did something like that and then returned the result as some sort of presentation, as well. What presentation type that result would have is not at all a feature of the number system, but rather, a feature of the user interface the application would like to provide to the user. Thankfully, the application you choose to write is not specified in either the CL or CLIM standards.
-- Rahul Jain rj...@nyct.net Professional Software Developer, Amateur Quantum Mechanicist
