Why not a Python compiler?
Santiago Romero
( Surely if this question has been asked for a zillion of times... )
( and sorry for my english! )
I'm impressed with python. I'm very happy with the language and I
find Python+Pygame a very powerful and productive way of writing 2D
games. I'm not, at this moment, worried about execution speed of the
small game I'm working on (it runs at full 60 fps even in an old AMD-
K6 450 Laptop computer), but I continue asking me the same question:
Why not a Python COMPILER?
It would be very nice to be able to output Linux, MAC or Windows
binaries of compiled (not bytecompiled) code. It would run faster, it
will be smaller in size (I think) and it will be easy to distribute to
people not having python installed. Yes, I know about py2exe, but I'm
not sure if that's the right aproach.
So, what's wrong with compiling python?
Maybe is not possible due to nature of the language? Is just a
decision?
What do you think about this?
cokof...@gmail.com
I don't know the exact details but I think the issue is the dynamic
nature of Python makes it impossible to correctly store the various
types and changes into compiled code. Someone else will probably be
able to provide a good reason as to why it isn't very feasible, nor a
good idea. If you want to speed up your python look at Psyco.
http://psyco.sourceforge.net/
Jeroen Ruigrok van der Werven
> Why not a Python COMPILER?
A lot of things within Python are very run-time dependent so creating a
compiler is not trivial work.
There are, however, endeavours underway like shed skin:
http://code.google.com/p/shedskin/
This provides a Python to C++ compiler, but it enforces some restrictions on
Python's code.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
We have met the enemy and they are ours...
Kay Schluehr
Sure. You can access comp.lang.python via google.google.com. It has a
search function.
Dustan
> On Feb 5, 9:19 am, Santiago Romero <srom...@gmail.com> wrote:
>
> > ( Surely if this question has been asked for a zillion of times... )
>
> Sure. You can access comp.lang.python via
groups
> .google.com.
Bruno Desthuilliers
> ( Surely if this question has been asked for a zillion of times... )
Why not checking this by yourself ? google is down ?-)
> I'm impressed with python. I'm very happy with the language and I
> find Python+Pygame a very powerful and productive way of writing 2D
> games. I'm not, at this moment, worried about execution speed of the
> small game I'm working on (it runs at full 60 fps even in an old AMD-
> K6 450 Laptop computer), but I continue asking me the same question:
>
> Why not a Python COMPILER?
http://docs.python.org/lib/module-compiler.html
> It would be very nice to be able to output Linux, MAC or Windows
> binaries of compiled (not bytecompiled) code.
Ah, sorry.
> It would run faster, it
> will be smaller in size (I think)
These two points are very questionnable given Python's dynamicity. IIRC,
some guru already made the point, a couple or more years ago, that it
would be a lot of effort and buy *very* few wrt/ execution speed since
everything still have to happens at runtime. IOW, a JIT compiler seems a
far better solution, but this (so far) still impose some (serious)
limitations to be of any help.
Ript...@gmail.com
> Why not a Python COMPILER?
What about a Python JIT hardware chip, so the CPU doesn't have to
translate. Although it seems to me that with today's dual and quad
core processors that this might be a mute point because you could just
use one of the cores.
Steve Holden
I am sure that would be popular with all the frustrated computer users
there are in the world.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Jeff Schwab
> Ript...@gmail.com wrote:
>>> Why not a Python COMPILER?
>>
>> What about a Python JIT hardware chip, so the CPU doesn't have to
>> translate. Although it seems to me that with today's dual and quad
>> core processors that this might be a mute point because you could just
>> use one of the cores.
>>
> What about a chip that reads your mind and does what you want it to?
+1!
> I am sure that would be popular with all the frustrated computer users
> there are in the world.
I'll take two. (Chips, not frustrated users).
--
"I sold the cow for these magic ICs," said Jack.
Jeff Schwab
> Ript...@gmail.com wrote:
>>> Why not a Python COMPILER?
>>
>> What about a Python JIT hardware chip, so the CPU doesn't have to
>> translate. Although it seems to me that with today's dual and quad
>> core processors that this might be a mute point because you could just
>> use one of the cores.
>>
> What about a chip that reads your mind and does what you want it to?
+1!
> I am sure that would be popular with all the frustrated computer users
> there are in the world.
I'll take two. (Chips, not frustrated users).
Jeff
stand-alone C programs using near-Python syntax:
Pyrex: http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/
Stand-alone how-to: http://www.freenet.org.nz/python/embeddingpyrex/
Pyrex how-to: http://ldots.org/pyrex-guide/,
http://www.artfulcode.net/articles/extending-python-pyrex/ (shameless
plug, I know)
Ript...@gmail.com
I'm not sure where that came from. Microsoft had talked about a
hardware JIT for .NET a few years back. I was just wondering if anyone
had thought of it for python or anything like that.
Steven D'Aprano
Okay, you know how hard it is to create a software JIT compiler for a
language as dynamic as Python? It's REALLY HARD, which is why it hasn't
already been done[1]. Now you want that done in *hardware*, which is much
harder. Who's going to spend the money on R&D?
I'm sure there are thousands of l33t hax0rs out there who have thought
"Wouldn't it be c00l if there was a chip I could put into my PC to make
Python run a million times faster!!!". When I was younger and more
stupi^W innocent I had a mad fegairy for Forth and Lisp chips, but their
lack of financial viability and their unfortunate habit of actually being
*slower* than running the language in software put a big dent in the
idea. As general purpose CPUs got faster, the idea of making a specialist
language chip is now pretty much dead. Even if you could find a niche
market prepared to pay for it, "people who run Python programs" is
probably not that market.
[1] Apart from some specializing compilers like Pysco
http://psyco.sourceforge.net/introduction.html
--
Steven
Steve Holden
joseph...@gmail.com
cybersource.com.au> wrote:
> Okay, you know how hard it is to create a software JIT compiler for a
> language as dynamic as Python? It's REALLY HARD, which is why it hasn't
> already been done[1]. Now you want that done in *hardware*, which is much
> harder. Who's going to spend the money on R&D?
>
To be clear, compiling a language that is dynamic *in the particular
way Python is designed to be dynamic*, for example, documenting and
exporting as an API the dictionary lookup mechanism for method
dispatch, is really hard.
Compiling languages such as Lisp, which are quite dynamic, and in some
ways much *more* dynamic than Python, to native machine code has been
standard practice since the 1970s.
The issue is how Python, for whatever reason, was designed as a
language. Not with whether it is dynamic or static.
Luis M. González
There are some projects aimed to speed up Python by a large margin.
Right now you can use psyco, which is considered to be feature
complete, and whose future relies on the Pypy project.
Pypy is a very ambitious project and it aims, amongst many other
goals, to provide a fast just-in-time python implementation.
They even say that the "secret goal is being faster than c, which is
nonsense, isn´t it?" (I still didn´t get the joke though...).
And finally, you have ShedSkin, a project developed by one lonely and
heroic coder (Mark Dufour).
Shedskin aims at being a static python compiler, which can translate a
subset of python to stand alone executables.
It also can compile extension modules for cpython.
It works by translating python to c++ and then to machine code.
The python code must be done in a static way (getting rid of dynamic
features like, for example, not asigning different types to the same
variable).
Luis
John Nagle
Exactly. Or "when the only tool you have is a hash, everything
looks like a dictionary". The performance problems of Python stem
from the difficulty of telling whether a hash lookup is really necessary.
The killer is that Python lets you modify the namespaces of all functions,
objects, and modules from the outside. Given that language spec,
you're stuck with an implementation like CPython where everything really
is a hash internally.
If the namespaces of objects, functions, and modules could only be
modified from within the object, function, or module, then a compiler
could examine the module and see if there was anything that required
the general late-binding case. Everything else could then be bound early,
avoiding huge numbers of unnecessary lookups and yielding a considerable
speedup. It's necessary to provide for the late-binding case to keep
the dynamism of the language, but late-binding everything kills
performance.
Shed Skin has restrictions like that, but Shed Skin is being
developed by one guy, which isn't much for an optimizing compiler.
John Nagle
Reedick, Andrew
> -----Original Message-----
> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
> list-bounces+jr9445=att...@python.org] On Behalf Of Luis M. González
> Sent: Tuesday, February 05, 2008 6:44 PM
> To: pytho...@python.org
> Subject: Re: Why not a Python compiler?
>
>
> Pypy is a very ambitious project and it aims, amongst many other
> goals, to provide a fast just-in-time python implementation.
> They even say that the "secret goal is being faster than c, which is
> nonsense, isn´t it?" (I still didn´t get the joke though...).
>
'c' is also the speed of light. And since nothing can travel faster than light...
One demerit has been marked against your geek card for missing an obvious science pun. Additionally, your membership to the Star Trek Lifestyle Adventure Club has been put on probationary status for the next twelve parsecs.
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621
Grant Edwards
>> Pypy is a very ambitious project and it aims, amongst many
>> other goals, to provide a fast just-in-time python
>> implementation. They even say that the "secret goal is being
>> faster than c, which is nonsense, isn´t it?" (I still didn´t
>> get the joke though...).
>
> 'c' is also the speed of light.
'c' is the speed of light _in_a_vacuum_.
> And since nothing can travel faster than light...
Nothing can travel faster than the speed of light
_in_a_vacuum_. There are situtaitons where things can (and
regularly do) travel faster than light:
http://en.wikipedia.org/wiki/Cherenkov_radiation
Half a demerit.
> One demerit has been marked against your geek card for missing
> an obvious science pun. Additionally, your membership to the
> Star Trek Lifestyle Adventure Club has been put on
> probationary status for the next twelve parsecs.
Ouch. Two demerits for using the distance unit "parsec" in a
context where a quantity of time was required.
--
Grant Edwards grante Yow! Boys, you have ALL
at been selected to LEAVE th'
visi.com PLANET in 15 minutes!!
Reedick, Andrew
> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
> list-bounces+jr9445=att...@python.org] On Behalf Of Grant Edwards
> Sent: Wednesday, February 06, 2008 10:35 AM
> To: pytho...@python.org
> Subject: Re: Why not a Python compiler?
>
>
> >> Pypy is a very ambitious project and it aims, amongst many
> >> other goals, to provide a fast just-in-time python
> >> implementation. They even say that the "secret goal is being
> >> faster than c, which is nonsense, isn´t it?" (I still didn´t
> >> get the joke though...).
> >
> > 'c' is also the speed of light.
>
> 'c' is the speed of light _in_a_vacuum_.
True.
> > And since nothing can travel faster than light...
>
> Nothing can travel faster than the speed of light
> _in_a_vacuum_. There are situtaitons where things can (and
> regularly do) travel faster than light:
> http://en.wikipedia.org/wiki/Cherenkov_radiation
Nope. It propagates, not travels, faster than light. Go ask a physicist to explain it. It's odd...
>
> > One demerit has been marked against your geek card for missing
> > an obvious science pun. Additionally, your membership to the
> > Star Trek Lifestyle Adventure Club has been put on
> > probationary status for the next twelve parsecs.
>
> Ouch. Two demerits for using the distance unit "parsec" in a
> context where a quantity of time was required.
Ten demerits for not catching the Star Wars Kessel Run reference.
Steve Holden
>> -----Original Message-----
>> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
>> Sent: Wednesday, February 06, 2008 10:35 AM
>>
>>>> Pypy is a very ambitious project and it aims, amongst many
>>>> other goals, to provide a fast just-in-time python
>>>> implementation. They even say that the "secret goal is being
>>>> faster than c, which is nonsense, isn´t it?" (I still didn´t
>>>> get the joke though...).
>>> 'c' is also the speed of light.
>> 'c' is the speed of light _in_a_vacuum_.
>
>
>
>>> And since nothing can travel faster than light...
>> Nothing can travel faster than the speed of light
>> _in_a_vacuum_. There are situtaitons where things can (and
>> regularly do) travel faster than light:
>> http://en.wikipedia.org/wiki/Cherenkov_radiation
>
>
>
>
>>> an obvious science pun. Additionally, your membership to the
>>> Star Trek Lifestyle Adventure Club has been put on
>>> probationary status for the next twelve parsecs.
>> Ouch. Two demerits for using the distance unit "parsec" in a
>> context where a quantity of time was required.
>
>
>
>
pissing contest.
Steve Holden
>> -----Original Message-----
>> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
>> Sent: Wednesday, February 06, 2008 10:35 AM
>>
>>>> Pypy is a very ambitious project and it aims, amongst many
>>>> other goals, to provide a fast just-in-time python
>>>> implementation. They even say that the "secret goal is being
>>>> faster than c, which is nonsense, isn´t it?" (I still didn´t
>>>> get the joke though...).
>>> 'c' is also the speed of light.
>> 'c' is the speed of light _in_a_vacuum_.
>
>
>
>>> And since nothing can travel faster than light...
>> Nothing can travel faster than the speed of light
>> _in_a_vacuum_. There are situtaitons where things can (and
>> regularly do) travel faster than light:
>> http://en.wikipedia.org/wiki/Cherenkov_radiation
>
>
>
>
>>> an obvious science pun. Additionally, your membership to the
>>> Star Trek Lifestyle Adventure Club has been put on
>>> probationary status for the next twelve parsecs.
>> Ouch. Two demerits for using the distance unit "parsec" in a
>> context where a quantity of time was required.
>
>
Carl Friedrich Bolz
>> -----Original Message-----
>> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
>> Sent: Tuesday, February 05, 2008 6:44 PM
>> goals, to provide a fast just-in-time python implementation.
>> They even say that the "secret goal is being faster than c, which is
>> nonsense, isn´t it?" (I still didn´t get the joke though...).
>>
>
nice theory, but wrong: The PyPy home page uses a capital letter C:
http://codespeak.net/pypy/dist/pypy/doc/home.html
Cheers,
Carl Friedrich Bolz
Carl Friedrich Bolz
>> -----Original Message-----
>> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
>> list-bounces+jr9445=att...@python.org] On Behalf Of Luis M. González
>> Sent: Tuesday, February 05, 2008 6:44 PM
>> To: pytho...@python.org
>> Subject: Re: Why not a Python compiler?
>>
>>
>> goals, to provide a fast just-in-time python implementation.
>> They even say that the "secret goal is being faster than c, which is
>> nonsense, isn´t it?" (I still didn´t get the joke though...).
>>
>
Carl Friedrich Bolz
Luis M. Gonzalez wrote:
> Well, lets suppose that being faster than C is the real goal...
How about we call it a very long-term dream?
> Are you confident that it will be reached?
We have ideas how to get there, but it is really rather long-term. There
will be a lot of research needed to achieve that for sure.
> How far is it at this moment?
Since a year already we have a JIT that makes quite fast code for purely
integer-type operations. Quite fast meaning about the speed of gcc -O0.
So far it is not faster than Psyco (it supports generators, though). We
are confident that the JIT will get substantially better this year
(probably better than Psyco). Where exactly this will leave us we don't
know.
> I've been following the project but the scarcity of news is getting me
> anxious...
Read the blog: morepypy.blogspot.com :-)
Cheers,
Carl Friedrich
Carl Friedrich Bolz
Jorge Godoy
>> -----Original Message-----
>> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
>> list-bounces+jr9445=att...@python.org] On Behalf Of Grant Edwards
>>
>> Nothing can travel faster than the speed of light
>> _in_a_vacuum_. There are situtaitons where things can (and
>> regularly do) travel faster than light:
>> http://en.wikipedia.org/wiki/Cherenkov_radiation
>
>
> Nope. It propagates, not travels, faster than light. Go ask a physicist
> to explain it. It's odd...
So let me see if I understood this correctly: C travels, C++ propagates? :-)
Steven D'Aprano
>> > 'c' is also the speed of light.
>>
>> 'c' is the speed of light _in_a_vacuum_.
>
> True.
>
>
>> > And since nothing can travel faster than light...
>>
>> Nothing can travel faster than the speed of light _in_a_vacuum_. There
>> are situtaitons where things can (and regularly do) travel faster than
>> light: http://en.wikipedia.org/wiki/Cherenkov_radiation
>
>
> Nope. It propagates, not travels, faster than light. Go ask a
> physicist to explain it. It's odd...
Propagate, travel, what's the difference?
If you're referring to the fact that in non-vacuum, light travels more
slowly due to frequent interactions with the particles of the medium it
travels through, that's discussed in the Wikipedia article.
There are quite a number of superluminal (faster than light) phenomena.
See, for example:
http://en.wikipedia.org/wiki/Slow_light
http://en.wikipedia.org/wiki/Phase_velocity
http://en.wikipedia.org/wiki/Faster-than-light
particularly the section titled:
"Superficially FTL phenomena which do not carry information"
--
Steven
Gary Duzan
No demerits for Andrew; it is a Star Wars reference, which is
quite on topic for this subthread.
http://starwars.wikia.com/wiki/Kessel_Run
Gary Duzan
Motorola H&NM
Stefan Behnel
> I'm impressed with python. I'm very happy with the language and I
> find Python+Pygame a very powerful and productive way of writing 2D
> games. I'm not, at this moment, worried about execution speed of the
> small game I'm working on (it runs at full 60 fps even in an old AMD-
> K6 450 Laptop computer), but I continue asking me the same question:
>
> Why not a Python COMPILER?
>
> It would be very nice to be able to output Linux, MAC or Windows
> binaries of compiled (not bytecompiled) code. It would run faster, it
> will be smaller in size (I think)
Take a look at Cython. It's an optimising Python-to-C compiler for writing
Python extensions. So you can basically take a Python module and compile it to
C code that runs against the CPython runtime.
> and it will be easy to distribute to
> people not having python installed. Yes, I know about py2exe, but I'm
> not sure if that's the right aproach.
That's a different focus, but then, there's "portable Python".
http://www.portablepython.com/
Stefan
Jean-Paul Calderone
>Santiago Romero wrote:
> [snip]
>>
>> Why not a Python COMPILER?
>>
>> It would be very nice to be able to output Linux, MAC or Windows
>> binaries of compiled (not bytecompiled) code. It would run faster, it
>> will be smaller in size (I think)
>
>Take a look at Cython. It's an optimising Python-to-C compiler for writing
>Python extensions. So you can basically take a Python module and compile it to
>C code that runs against the CPython runtime.
>
>http://cython.org/
>
It's a not-quite-Python-to-C compiler. I don't think it is an optimizing
compiler either. Can you provide a reference for this?
Jean-Paul
Ryszard Szopa
> I don't know the exact details but I think the issue is the dynamic
> nature of Python makes it impossible to correctly store the various
> types and changes into compiled code. Someone else will probably be
> able to provide a good reason as to why it isn't very feasible, nor a
> good idea. If you want to speed up your python look at Psyco. http://psyco.sourceforge.net/
Yeah, but exactly what features make it so hard to write a compiler
for Python?
Common Lisp seems like a language at least as dynamic as Python, e.g.
you can change the type of objects at runtime, you can make changes to
functions, you can change classes at runtime, you can add methods and
generic functions (nb. these changes are reflected in existing
objects), you have a metaobject protocol. Moreover, you have
multimethods (in Python you don't, so it is one less thing to care).
However, Common Lisp has a few decent compilers (at least two open
source and two commercial).
Google tells me that such arguments have been raised back in 2001 [1].
I can add from myself that today Python is much more similar to Common
Lisp than in 2001. For example, multiple inheritance in Python >= 2.3
behaves like in Dylan, which in turn behaves like CLOS with a twist.
What is more, apparently there is a Python compiler via CL: CLPython
(I don't have access to ACL, however, so I can't verify the claims of
the authors).
Finally, speaking of JIT compilers: recently has appeared something
that looks like avery nice JIT compiler for Scheme, Ikarus [3].
Scheme is also quite dynamical, but is not OO, so I don't know how
viable is the analogy.
Of course, when writing Python extensions in C is fairly easy and when
rewriting just the critical part of the code is enough to get
acceptable performance, I really doubt I will see anybody willing to
invest serious amounts of money and time into writing a native
compiler for Python. Learning C cannot be so hard ;-). Also, this
seems consistent with Python viewed as a glue between libraries
written in C.
Cheers,
-- Richard
BIG FAT DISCLAIMER: I DO NOT want to start a "Python vs. Common Lisp
and Scheme" flame war.
[1] http://mail.python.org/pipermail/python-list/2001-April/080394.html
[2] http://common-lisp.net/project/clpython/
[3] http://www.cs.indiana.edu/~aghuloum/ikarus/
Steve Holden
> On Feb 5, 9:30 am, cokofree...@gmail.com wrote:
>
>> I don't know the exact details but I think the issue is the dynamic
>> nature of Python makes it impossible to correctly store the various
>> types and changes into compiled code. Someone else will probably be
>> able to provide a good reason as to why it isn't very feasible, nor a
>> good idea. If you want to speed up your python look at Psyco. http://psyco.sourceforge.net/
>
> Yeah, but exactly what features make it so hard to write a compiler
> for Python?
a. People tell me writing a compiler for Python is hard.
b. It's certainly way to hard for me.
c. But hey, I've heard about this neat language called Common Lisp that
has a compiler. It looks a lot like Python.
d. So why can't you brainboxes write a compiler for Python?
Please tell me if I'm missing anything from this summary of your thought
processes.
Bjoern Schliessmann
> Of course, when writing Python extensions in C is fairly easy and
> when rewriting just the critical part of the code is enough to get
> acceptable performance, I really doubt I will see anybody willing
> to invest serious amounts of money and time into writing a native
> compiler for Python. Learning C cannot be so hard ;-).
Sure! Learning English also is not too hard. So everyone should be
capable of writing poetry of Shakespeare niveau.
Regards,
Björn
--
BOFH excuse #69:
knot in cables caused data stream to become twisted and kinked
Stefan Behnel
> Learning English also is not too hard. So everyone should be
> capable of writing poetry of Shakespeare niveau.
You're lucky that you can infer anything from a wrong statement.
http://www.mipmip.org/tidbits/pronunciation.shtml
Stefan
joseph...@gmail.com
> Ryszard Szopa wrote:
> > On Feb 5, 9:30 am, cokofree...@gmail.com wrote:
>
> >> I don't know the exact details but I think the issue is the dynamic
> >> nature of Python makes it impossible to correctly store the various
> >> types and changes into compiled code. Someone else will probably be
> >> able to provide a good reason as to why it isn't very feasible, nor a
>
> > Yeah, but exactly what features make it so hard to write a compiler
> > for Python?
> > [...]
>
> a. People tell me writing a compiler for Python is hard.
>
> b. It's certainly way to hard for me.
>
> c. But hey, I've heard about this neat language called Common Lisp that
> has a compiler. It looks a lot like Python.
>
> d. So why can't you brainboxes write a compiler for Python?
>
> Please tell me if I'm missing anything from this summary of your thought
> processes.
>
The basic difference is in point c. Common Lisp was a standard arrived
at by discussions including people who spent the 1970s and 1980s
developing high-performance native-code Lisp compilers targeting
conventional architectures (e.g. PDP-10, VAX, Sun workstations, etc.).
Stuff that would be hard to support with compiled code on conventional
CPUs was discouraged by the process.
The semantics of the Common Lisp standard were developed with the
needs of compilers in mind. CLOS is a very powerful object system, but
the design was developed with compilation and efficiency concerns in
mind. One major difference from Python OOP (as I understand it): CLOS
methods are looked up by their global method name. Python methods
(IIRC) are looked up in per-instance dictionaries. Redefining CLOS
methods requires changing one method-dispatch cache, and is supported
through a high-level interface, which a compiler can translate into
the low-level implementation machinery. Python code can mash the
dictionaries at will, because the low-level machinery is exposed.
The details, if I have mis-stated them, are not as important as the
principle of original design intent I am trying to illustrate.
Stefan Behnel
> On Thu, 07 Feb 2008 11:03:12 +0100, Stefan Behnel <stef...@behnel.de>
> wrote:
>> Take a look at Cython. It's an optimising Python-to-C compiler for
>> writing
>> Python extensions. So you can basically take a Python module and
>> compile it to
>> C code that runs against the CPython runtime.
>>
>> http://cython.org/
>
> It's a not-quite-Python-to-C compiler.
Ok, there are differences. For example, you can't define functions dynamically
(it doesn't currently support closures anyway). But it already supports a much
wider subset of the language than Pyrex originally did. For example, you can
use list comprehensions and Python 3 keyword-only arguments in function
signatures. I would expect it would compile quite a lot of Python code out
there without or with only minor modifications.
> I don't think it is an optimizing
> compiler either. Can you provide a reference for this?
It optimises a lot of common patterns into very fast sequences of Python API
calls (or even generates specialised non-API code for them). It also generates
optimised runtime code for special cases based on the type of an object (e.g.
if the object you iterate turns out to be a list, it uses fast list API calls
in loops, and a standard iterator otherwise). So the generated code is usually
much faster than what Pyrex gives you. Robert and I had an optimise session
lately where we dropped the function call-overhead by some 20-50% (!) compared
to the preceding Cython version (not even to Pyrex), just depending on the
signature.
I think that qualifies for an "optimising" compiler.
Stefan
Grant Edwards
Silly me.
I wonder if George Lucas intended it as a joke or if he thought
a parsec was a unit of time.
--
Grant Edwards grante Yow! Clear the laundromat!!
at This whirl-o-matic just had
visi.com a nuclear meltdown!!
Torsten Bronger
Grant Edwards writes:
> On 2008-02-06, Gary Duzan <mgi...@motorola.com> wrote:
>
>> In article <13qjktd...@corp.supernews.com>,
>>
>> Grant Edwards <gra...@visi.com> wrote:
>>
>>> [...]
>>>
>>> Ouch. Two demerits for using the distance unit "parsec" in a
>>> context where a quantity of time was required.
>>
>> No demerits for Andrew; it is a Star Wars reference, which is
>> quite on topic for this subthread.
>>
>> http://starwars.wikia.com/wiki/Kessel_Run
>
> Silly me.
>
> I wonder if George Lucas intended it as a joke or if he thought
> a parsec was a unit of time.
The latter because it was corrected in the novelization.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: bro...@jabber.org
(See http://ime.webhop.org for further contact info.)
Ivan Van Laningham
knew what he was doing; supposedly, Obi-Wan's expression indicated
that he knew Solo was feeding him shit.
I think Lucas didn't have a clue, myself; it's not credible that
citizens of a starfaring civilization who deliberately set out to hire
a starship wouldn't know the difference between time and distance.
Occam's razor says Lucas screwed up and doesn't want to admit it.
Metta,
Ivan
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
Ivan Van Laningham
God N Locomotive Works
http://www.pauahtun.org/
http://www.python.org/workshops/1998-11/proceedings/papers/laningham/laningham.html
Army Signal Corps: Cu Chi, Class of '70
Author: Teach Yourself Python in 24 Hours
Reedick, Andrew
> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
> list-bounces+jr9445=att...@python.org] On Behalf Of Torsten Bronger
> Sent: Thursday, February 07, 2008 3:32 PM
> To: pytho...@python.org
> Subject: Re: Why not a Python compiler?
>
> >
> > a parsec was a unit of time.
>
> The latter because it was corrected in the novelization.
>
Errr... didn't one of the novels explain it away by describing the
kessel run as a region of space warped by black holes or other objects?
Bragging rights for crossing such a field thus centered on shortest
distance instead of time.
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623
Lou Pecora
Torsten Bronger <bro...@physik.rwth-aachen.de> wrote:
> > a parsec was a unit of time.
>
> The latter because it was corrected in the novelization.
>
> Tschö,
> Torsten.
Sounds like one. The reverse of light year that sounds like a unit of
time, but isn't. I've heard it used seriously like time in some movie.
--
-- Lou Pecora
Steven D'Aprano
> Gary Kurtz at SunCon 77 explained that it was a test to see if Obi-Wan
> knew what he was doing; supposedly, Obi-Wan's expression indicated that
> he knew Solo was feeding him shit.
Why the hell would the pilot care whether the passengers knew what a
parsec was? Did Concorde pilots quiz their passengers what Mach 1 means?
Especially a pirate like Solo, who really only cared about one question:
"can the passenger pay?".
> I think Lucas didn't have a clue, myself; it's not credible that
> citizens of a starfaring civilization who deliberately set out to hire a
> starship wouldn't know the difference between time and distance. Occam's
> razor says Lucas screwed up and doesn't want to admit it.
For sure.
--
Steven
Steven D'Aprano
> Ryszard Szopa wrote:
>> On Feb 5, 9:30 am, cokofree...@gmail.com wrote:
>>
>>> I don't know the exact details but I think the issue is the dynamic
>>> nature of Python makes it impossible to correctly store the various
>>> types and changes into compiled code. Someone else will probably be
>>> able to provide a good reason as to why it isn't very feasible, nor a
>>> good idea. If you want to speed up your python look at Psyco.
>>> http://psyco.sourceforge.net/
>>
>> Yeah, but exactly what features make it so hard to write a compiler for
>> Python?
>> [...]
>
> a. People tell me writing a compiler for Python is hard.
>
> b. It's certainly way to hard for me.
>
> c. But hey, I've heard about this neat language called Common Lisp that
> has a compiler. It looks a lot like Python.
>
> d. So why can't you brainboxes write a compiler for Python?
>
> Please tell me if I'm missing anything from this summary of your thought
> processes.
Be fair -- he's asking what specific features of Python make it hard.
That's a reasonable question.
--
Steven
Jeroen Ruigrok van der Werven
>Errr... didn't one of the novels explain it away by describing the
>kessel run as a region of space warped by black holes or other objects?
>Bragging rights for crossing such a field thus centered on shortest
>distance instead of time.
http://starwars.wikia.com/wiki/Kessel_Run
Han Solo claimed that his Millennium Falcon "made the Kessel Run in less
than twelve parsecs." The parsec is a unit of distance, not time. Solo was
not referring directly to his ship's speed when he made this claim. Instead,
he was referring to the shorter route he was able to travel by skirting the
nearby Maw black hole cluster, thus making the run in under the standard
distance. However, parsec relates to time in that a shorter distance equals
a shorter time at the same speed. By moving closer to the black holes, Solo
managed to cut the distance down to about 11.5 parsecs.
In the A New Hope novelization, Han says "standard time units" rather than
"parsecs". Therefore, the reduced distance of Solo's Kessel Run is most
likely a retcon to explain George Lucas's confusion of time and distance
units.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
A place for everything, and everything in its place...
Erik Max Francis
> Gary Kurtz at SunCon 77 explained that it was a test to see if Obi-Wan
> knew what he was doing; supposedly, Obi-Wan's expression indicated
> that he knew Solo was feeding him shit.
>
> I think Lucas didn't have a clue, myself; it's not credible that
> citizens of a starfaring civilization who deliberately set out to hire
> a starship wouldn't know the difference between time and distance.
> Occam's razor says Lucas screwed up and doesn't want to admit it.
Indeed, that is precisely what I would have said. Any after-the-fact
explanation of why the error was present (but not corrected or pointed
out in the movie) is just so much rationalization.
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis
So little time, so little to do.
-- Oscar Levant
Steve Holden
> On Thu, 07 Feb 2008 13:44:05 -0700, Ivan Van Laningham wrote:
>
>> Gary Kurtz at SunCon 77 explained that it was a test to see if Obi-Wan
>> knew what he was doing; supposedly, Obi-Wan's expression indicated that
>> he knew Solo was feeding him shit.
>
> Why the hell would the pilot care whether the passengers knew what a
> parsec was? Did Concorde pilots quiz their passengers what Mach 1 means?
>
cabin as a Mach number.
> Especially a pirate like Solo, who really only cared about one question:
> "can the passenger pay?".
>
>
>> I think Lucas didn't have a clue, myself; it's not credible that
>> citizens of a starfaring civilization who deliberately set out to hire a
>> starship wouldn't know the difference between time and distance. Occam's
>> razor says Lucas screwed up and doesn't want to admit it.
>
> For sure.
>
>
What's more, he won't pay dues so ILM can be a full sponsor member of
the PSF. It doesn't seem credible to me that an organization of that
size couldn't find $2,000 in its budget to support the language of which
it may well be the largest single user in the world. Not that I
seriously imagine George Lucas micromanages the budget down to that level.
Steve Holden
Fortunately someone less grumpy provided quite a decent answer.
Hrvoje Niksic
> Be fair -- he's asking what specific features of Python make it
> hard. That's a reasonable question.
Indeed. The best explanation I've seen explained goes something like
this: imagine a hypothetical Python compiler that achieves native
compilation by compiling to Common Lisp and using the CL's compiler to
produce native code. Upon encountering the expression such as:
a + b
the compiler could do little else except translate it to something
like:
(python:add a b)
In order to correctly implement Python addition, python:add needs to
do a lot of work at run-time. It needs to check for __add__ method of
one or both operands without assuming what it does, since a
user-defined class is free to define __add__ to do whatever it
pleases. The compiler could attempt to infer the types of operands,
but that is hard since an expression such as "a = module.SomeClass()"
completely changes meaning if module.SomeClass or
module.SomeClass.__add__ change. Such changes may seem improbable,
but fact is that being able to do them is a documented part of the
language, and a lot of code makes good use of it. Assuming these
things don't happen means the compiler doesn't implement Python.
This applies not only to addition; expressions such as "foo.bar",
which include any method call, would be translated to (python:getattr
foo "bar"), and so on. Most functions would have to construct actual
tuples, since a function can be replaced with one that takes *args.
Again, optimizing almost any of this away would change the semantics
of Python. From the ability to assign to classes, to modules, to
globals(), and to __dict__'s, literally anything can change at
run-time. *Some* kinds of runtime dispatches can be sped up by
setting up sophisticated caches (one such cache for methods is being
applied to CPython), but getting that right without breaking
correctness is quite tricky. Besides the same caches could be used to
speed up CPython too, so they don't constitute an advantage of the
compiler.
The main determinant of Python's performance isn't the interpreter
overhead, but the amount of work that must be done at run-time and
cannot be moved to compile-time or optimized away.
Arnaud Delobelle
> Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.au> writes:
> > Be fair -- he's asking what specific features of Python make it
> > hard. That's a reasonable question.
>
> Indeed. The best explanation I've seen explained goes something like
> this: imagine a hypothetical Python compiler that achieves native
> compilation by compiling to Common Lisp and using the CL's compiler to
> produce native code. Upon encountering the expression such as:
>
> a + b
>
> the compiler could do little else except translate it to something
> like:
>
> (python:add a b)
Please get back on topic. This discussion is about parsecs and
wookies now.
--
Arnaud
Torsten Bronger
Reedick, Andrew writes:
>> -----Original Message-----
>> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
>> list-bounces+jr9445=att...@python.org] On Behalf Of Torsten Bronger
>> Sent: Thursday, February 07, 2008 3:32 PM
>> To: pytho...@python.org
>> Subject: Re: Why not a Python compiler?
>>
>>> I wonder if George Lucas intended it as a joke or if he thought
>>> a parsec was a unit of time.
>>
>> The latter because it was corrected in the novelization.
>
> Errr... didn't one of the novels explain it away by describing the
> kessel run as a region of space warped by black holes or other
> objects? Bragging rights for crossing such a field thus centered
> on shortest distance instead of time.
Well, in the link that Grant provided, it says
In the A New Hope novelization, Han says "standard time units"
rather than "parsecs". Therefore, the reduced distance of Solo's
Kessel Run is most likely a retcon to explain George Lucas's
confusion of time and distance units.
Tschö,
jack trades
news:28eead2f-a40c-414b...@d70g2000hsb.googlegroups.com...
> Why not a Python COMPILER?
Check out CLPython it has a Python compiler, though I highly doubt it is
what you are thinking of.
From http://common-lisp.net/project/clpython/manual.html
Sometimes, the generated Python code can be simplified because the value of
an expressions is known at compile time. This is where compiler macros come
in. In this example, as 4 > 3 always holds, the compiler macro for py->
replaces (funcall #'py-> 4 3) by the Python value True. After that, the
compiler macro for py-val->lisp-bool recognizing True is a constant value,
replaces (py-val->lisp-bool True) by t. The Lisp compiler then deduces that
always the first branch of the if expression is taken, and replace the whole
(cond ...) by (py-print nil (list "y") nil).
In this example the compiler macros were able to remove a lot of the Lisp
code at compile time. This results in more efficient code. However, in
practice there is often not that much that can be decided at compile time,
due to Python-the-language being very dynamic. For example, in the
expression 5 + x the value of x can be anything. As classes are able to
redefine how the + operator behaves (by means of the __add__ and __radd__
methods), the value of 5 + x can be anything as well. Unless the context
gives more information about the type of x, the Lisp code must contain a
call to the generic addition function py-+.
Nevertheless, the compiler macro will inline "common" case, and make the
generic call only for "uncommon" arguments. If small integers (fixnums) are
common for the + operator, the compiler macro for py-+ could emit:
(if (typep x 'fixnum)
(+ 5 x)
(py-+ 5 x))The check for x being fixnum is very fast; and if x is indeed a
fixnum then the inline addition is also very fast. If x is not a fixnum, it
could another kind of (Lisp) number, or even a Pythonic object posing as a
number. The generic py-+ will handle that.
Compiled vs Interpreted Code
CLPython can run Python code in two modes, interpreted or compiled. In the
latter case, the Lisp code is translated into assembly. The advantage of
interpreted code is that debugging is easier (the stack trace contains more
information); on the other hand execution of compiled code is much faster.
Jack Trades
Steven D'Aprano
> Hallöchen!
>
> Reedick, Andrew writes:
>
>>> -----Original Message-----
>>> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
>>> list-bounces+jr9445=att...@python.org] On Behalf Of Torsten Bronger
>>> Sent: Thursday, February 07, 2008 3:32 PM To: pytho...@python.org
>>> Subject: Re: Why not a Python compiler?
>>>
>>>> I wonder if George Lucas intended it as a joke or if he thought a
>>>> parsec was a unit of time.
>>>
>>> The latter because it was corrected in the novelization.
>>
>> Errr... didn't one of the novels explain it away by describing the
>> kessel run as a region of space warped by black holes or other objects?
>> Bragging rights for crossing such a field thus centered on shortest
>> distance instead of time.
>
> Well, in the link that Grant provided, it says
>
> In the A New Hope novelization, Han says "standard time units"
> rather than "parsecs". Therefore, the reduced distance of Solo's
> Kessel Run is most likely a retcon to explain George Lucas's
> confusion of time and distance units.
Bah humbug! New Hope, new poke.
Some of us are old enough to remember when Star Wars was Star Wars: the
movie was called Star Wars, the opening credits listed it as Star Wars
(with New Hope merely a subtitle specifically to invoke the flavour of
the Saturday afternoon movies of Lucas' teen years) and the novelization
was called Star Wars.
That novel was credited to Lucas but actually ghost-written by Alan Dean
Foster. The 1976 Sphere Books edition is called Star Wars, it's subtitled
"From the Adventures of Luke Skywalker", and the inside front page refers
to the movie as Star Wars. With no subtitle.
In that book, Han refers to "twelve standard time parts", a clunky and
ugly phrase even stupider than calling it twelve parsecs, which reads and
sounds like real language.
Personally, I think Lucas should have just said that in that particular
galaxy far far away and a long time ago, "parsec" *was* a measure of
time. I'd buy that.
--
Steven
Paul Boddie
>
> [snip more interesting considerations about compiling python]
>
> Please get back on topic. This discussion is about parsecs and
> wookies now.
Yes, it's like the lower-value parts of Wikipedia have spilled out
onto Usenet. ;-)
But I think Hrvoje's post summarises quite well: Python operations are
not directly equivalent to the primitive operations which often employ
the same symbols (eg. arithmetic operators), determining the
attributes of objects typically requires relatively expensive
operations (compared to optimised cases in other languages),
predicting the outcome of such run-time operations is difficult
because even the slightest change can have global consequences.
That said, there are some things in Python which are intentionally
predictable: names are always associated with a particular scope
(local, global), access to such scopes is not configurable (unlike
access to instance namespaces, for example). Moreover, people have
asserted that many programs do not use the full potential of Python's
dynamic facilities. For example, how many programs do something like
this...?
class A:
...
class B:
...
for cls in A, B:
class C(cls):
...
Removing the mere possibility of such stuff piece by piece, or rather
telling the programmer that it makes their programs run slow, could
make Python programs more readily inspectable and potentially more
open to optimisation. I regard this as a more interesting route than
just slapping type annotations all over the place and pretending that
Java's younger brother hasn't just been conceived.
Paul
Ryszard Szopa
In this respect, CL's is similar to Python. Generic functions are even
more dynamic than Python's methods. You can add a method to a gf
whenever you please. Also, you can assign to classes, change their
structure (add or remove slots), change their metaclass and so on. As
for foo.bar and friends: in CL you have to define an accessor function
if you don't want to use (SLOT-VALUE foo 'bar) all the time (this is
usually done through a shortcut in the DEFCLASS macro).
CL objects are not hash-tables, so you will get an error if you try to
assign to a bogus (by which I mean not present in the class
definition) slot. However, you can implement a slot-missing method
to sanely handle this situation.
You cannot reset slots containing methods in CL (as they do not
exist). However, you should be able to implement
SLOT-VALUE-USING-CLASS and (SETF SLOT-VALUE-USING-CLASS) which would
emulate Python's behavior. Finally, you can use EQL specializers,
which give you object (not class) specific behavior.
The one thing that isn't so easy to emulate is assignment to modules
(though redefinition of a function in some package works as you would
expect).
> setting up sophisticated caches (one such cache for methods is being
> applied to CPython), but getting that right without breaking
> correctness is quite tricky. Besides the same caches could be used to
> speed up CPython too, so they don't constitute an advantage of the
> compiler.
>
> The main determinant of Python's performance isn't the interpreter
> overhead, but the amount of work that must be done at run-time and
> cannot be moved to compile-time or optimized away.
Well, I am still not convinced that Python is intrinsically
un-compilable :-).
Some optimizations that are nowadays done by hand probably could be
abstracted. Think assigning a method to a local variable before using
it in a loop... Expressing simple loops as C for loops... Tail call
optimization... (Of course, my intuitions about what would be a great
optimization for a Python compiler are vague, so please correct me if
I am drastically wrong.) Note that these are the kind of optimizations
you don't want in your interpreter. When it comes to debugging, the
lack of tail call optimization is a feature, not a bug.
Finally, skimming the CLPython mailing list suggests it actually
works. Presently it is slower than CPython, but after all it is a far
from mature one developer project, so you can treat it as a proof of
concept.
Anyway, I won't be very surprised if in a couple of years your average
c.l.py troll is going to be asking "So I heard that Python is an
interpreted only language, how can it be any good?", and you will be
explaining for the thousandth time: "Since version 4.2 Python has a
fast native code compiler, so...". ;-)
Cheers,
-- Richard
BTW maybe Dylan could be a better model for Python for compilation? In
many respects it is a lot more similar to Python than Common Lisp. It
is a Lisp-1 (it has a single namespace for functions and variables),
and it seems to be more object oriented than CL.
Grant Edwards
> -On [20080207 22:09], Reedick, Andrew (jr9...@ATT.COM) wrote:
>>Errr... didn't one of the novels explain it away by describing the
>>kessel run as a region of space warped by black holes or other objects?
>>Bragging rights for crossing such a field thus centered on shortest
>>distance instead of time.
>
> http://starwars.wikia.com/wiki/Kessel_Run
>
> Han Solo claimed that his Millennium Falcon "made the Kessel Run in less
> than twelve parsecs." The parsec is a unit of distance, not time. Solo was
> not referring directly to his ship's speed when he made this claim. Instead,
> he was referring to the shorter route he was able to travel by skirting the
> nearby Maw black hole cluster, thus making the run in under the standard
> distance. However, parsec relates to time in that a shorter distance equals
> a shorter time at the same speed. By moving closer to the black holes, Solo
> managed to cut the distance down to about 11.5 parsecs.
Um, yea, I'd have to call bullshit on that.
IIRC, he was answering a question something like "is she fast".
If you buy the above BS, he'd have to be be answering a
question about his piloting skills not about how fast the ship
is.
One could give GL the benefit of the doubt and claim that GL
intentionally miswrote the line to give the movie the feel of
the badly-written serials he was emulating. But then again, I
think GL has since proven beyond a doubt that he's just a
really bad writer who is particularly awful at dialog.
> In the A New Hope novelization, Han says "standard time units"
> rather than "parsecs". Therefore, the reduced distance of
> Solo's Kessel Run is most likely a retcon to explain George
> Lucas's confusion of time and distance units.
--
Grant Edwards grante Yow! BELA LUGOSI is my
at co-pilot ...
visi.com
Grant Edwards
> A Parsec is a fixed value (which, admittedly, presumes the culture
> developed a 360degree circle broken into degrees => minutes =>
> seconds... or, at least, some units compatible with the concept of an
> "arc second", like 400 grads of, say, 100 "minutes", each of 100
> "seconds")
It also presumes a standard diamter of that circle.
--
Grant Edwards grante Yow! Are you the
at self-frying president?
visi.com
Hrvoje Niksic
>> The main determinant of Python's performance isn't the interpreter
>> overhead, but the amount of work that must be done at run-time and
>> cannot be moved to compile-time or optimized away.
>
> Well, I am still not convinced that Python is intrinsically
> un-compilable :-).
It's not. My point is that it's very hard to optimize if your goal is
to implement Python as currently defined.
> Some optimizations that are nowadays done by hand probably could be
> abstracted. Think assigning a method to a local variable before using
> it in a loop...
That's an example of what I'm talking about: it is simply not correct
to cache methods in general. If you think changing classes is a
no-no, remember that function objects can be and do get added to an
individual instance's __dict__. Of course, your compiler could
support a declaration that disables the optimization for code that
really needs to do it, but then you're no longer compatible with
Python. (And by "Python" I don't mean just CPython, but the core
language as defined by the language reference and implemented in
CPython, Jython, and IronPython.)
> Anyway, I won't be very surprised if in a couple of years your
> average c.l.py troll is going to be asking "So I heard that Python
> is an interpreted only language, how can it be any good?", and you
> will be explaining for the thousandth time: "Since version 4.2
> Python has a fast native code compiler, so...". ;-)
I'll be very happy to be proven wrong in that respect. :-)
Grant Edwards
>> the compiler could do little else except translate it to something
>> like:
>>
>> (python:add a b)
> [snip more interesting considerations about compiling python]
>
> Please get back on topic. This discussion is about parsecs and
> wookies now.
What's a "wookie" a unit of?
--
Grant Edwards grante Yow! Am I accompanied by a
at PARENT or GUARDIAN?
visi.com
Jeff Schwab
> On 2008-02-08, Arnaud Delobelle <arn...@googlemail.com> wrote:
>
>>> the compiler could do little else except translate it to something
>>> like:
>>>
>>> (python:add a b)
>> [snip more interesting considerations about compiling python]
>>
>> Please get back on topic. This discussion is about parsecs and
>> wookies now.
>
> What's a "wookie" a unit of?
Fur.
Reedick, Andrew
> From: python-list-bounces+jr9445=att...@python.org [mailto:python-
> list-bounces+jr9445=att...@python.org] On Behalf Of Grant Edwards
> Sent: Friday, February 08, 2008 12:46 PM
> To: pytho...@python.org
> Subject: Re: Why not a Python compiler?
>
>
> >> the compiler could do little else except translate it to something
> >> like:
> >>
> >> (python:add a b)
> > [snip more interesting considerations about compiling python]
> >
> > Please get back on topic. This discussion is about parsecs and
> > wookies now.
>
> What's a "wookie" a unit of?
>
How many ewoks are there to a wookie? (Yes, I know the metric system is
archaic, but I really don't care for them new fangled 'standard units'.)
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621
Lou Pecora
Grant Edwards <gra...@visi.com> wrote:
> On 2008-02-08, Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:
>
> > A Parsec is a fixed value (which, admittedly, presumes the culture
> > developed a 360degree circle broken into degrees => minutes =>
> > seconds... or, at least, some units compatible with the concept of an
> > "arc second", like 400 grads of, say, 100 "minutes", each of 100
> > "seconds")
>
> It also presumes a standard diamter of that circle.
Which is the Earth's orbit. So, long, long ago in a galaxy far, far
away did they know about the Earth and decide to use it as the basis for
length in the universe? Even before people on earth defined it?
Or (ominous music builds here, switch to low voice) is it as some now
contend? We are the decendents of a long, lost civilization who
colonized Earth and used it as a base for their operations to the point
of adopting it as their own home?
... You Betcha!
:-)
--
-- Lou Pecora
Steve Holden
> On 2008-02-08, Arnaud Delobelle <arn...@googlemail.com> wrote:
>
>>> the compiler could do little else except translate it to something
>>> like:
>>>
>>> (python:add a b)
>> [snip more interesting considerations about compiling python]
>>
>> Please get back on topic. This discussion is about parsecs and
>> wookies now.
>
> What's a "wookie" a unit of?
>
much.
Marc 'BlackJack' Rintsch
> Expressing simple loops as C for loops...
You mean simple loops like ``for i in xrange(1000):``? How should the
compiler know what object is bound to the name `xrange` when that loop is
executed?
Ciao,
Marc 'BlackJack' Rintsch
Marc 'BlackJack' Rintsch
> On 2008-02-08, Arnaud Delobelle <arn...@googlemail.com> wrote:
>
>> Please get back on topic. This discussion is about parsecs and
>> wookies now.
>
> What's a "wookie" a unit of?
The degree of confusion among the jury when using the Chewbacca defense. :-)
http://en.wikipedia.org/wiki/Chewbacca_defense
Ciao,
Marc 'BlackJack' Rintsch
Luis M. González
> On Fri, 08 Feb 2008 17:45:36 +0000, Grant Edwards wrote:
>
> >> Please get back on topic. This discussion is about parsecs and
> >> wookies now.
>
> > What's a "wookie" a unit of?
>
> The degree of confusion among the jury when using the Chewbacca defense. :-)
>
> http://en.wikipedia.org/wiki/Chewbacca_defense
>
> Ciao,
> Marc 'BlackJack' Rintsch
You are all a bunch of pathetic geeks with your nerdy lingo.
All of you should be frozen in carbonite and sold to a Hutt...
Jeff Schwab
Ahhh, *you* must be the one who found time to write that Wikipedia
article on the Chewbacca defense.
Steven D'Aprano
> On Fri, 08 Feb 2008 05:12:29 -0800, Ryszard Szopa wrote:
>
>> Expressing simple loops as C for loops...
>
> You mean simple loops like ``for i in xrange(1000):``? How should the
> compiler know what object is bound to the name `xrange` when that loop
> is executed?
Assuming the aim is to optimize for speed rather than memory, the
solution is for the compiler to create something like this pseudo-code:
if xrange is Python's built-in xrange:
execute optimized for-loop at C-like speed
else:
execute unoptimized normal loop at Python speed
(In case it's not obvious, the decision of which branch to take is made
at run time, not compile time.)
This, naturally, assumes that the test of whether xrange is the built-in
xrange is fast. If it is not, then the optimized code will actually be
slower for small enough loops. But that's hardly unusual: no optimizing
compiler guarantees to optimize code in every possible case.
I understand that is more or less what psycho already does.
--
Steven
Martin P. Hellwig
> On Wed, 06 Feb 2008 10:14:10 -0600, Reedick, Andrew wrote:
>
>>>> 'c' is also the speed of light.
>>> 'c' is the speed of light _in_a_vacuum_.
>> True.
>>
>>
>>>> And since nothing can travel faster than light...
>>> Nothing can travel faster than the speed of light _in_a_vacuum_. There
>>> are situtaitons where things can (and regularly do) travel faster than
>>> light: http://en.wikipedia.org/wiki/Cherenkov_radiation
>>
>> Nope. It propagates, not travels, faster than light. Go ask a
>> physicist to explain it. It's odd...
>
> Propagate, travel, what's the difference?
>
Unfortunately, I didn't study any of this but I sure do remember the
answer one drunk physic said to me in a bar when I ask him the question:
"Does light travel or propagate?"
He answered: "Depends on how you see light."
He must have studied philosophy too :-)
<cut rest>
--
mph
Thomas Dybdahl Ahle
On Sat, 2008-02-09 at 14:56 +0100, Martin P. Hellwig wrote:
> > Propagate, travel, what's the difference?
> >
> Unfortunately, I didn't study any of this but I sure do remember the
> answer one drunk physic said to me in a bar when I ask him the question:
> "Does light travel or propagate?"
> He answered: "Depends on how you see light."
> He must have studied philosophy too :-)
Quantum mechanics are closely related to philosophy.
--
Best Regards,
Med Venlig Hilsen,
Thomas
Grant Edwards
I've never understood that claim. You can philosophize about
anything: biology, math, weather, the stars, the moon, and so
on. I don't see how QM is any more related to philosophy than
any other field in science.
--
Grant Edwards grante Yow! RELAX!!... This
at is gonna be a HEALING
visi.com EXPERIENCE!! Besides,
I work for DING DONGS!
Doug Morse
light, say from the sun, is actually sending particles to the earth, since the
space between is mostly vacuum? Or is there enough material in the
near-vacuum of space for propogation to occur?
On Sat, 09 Feb 2008 12:25:51 -0800, Dennis Lee Bieber <wlf...@ix.netcom.com>
wrote:
> ...
> Or just the old particle/wave dichotomy... particles travel, waves
> propagate (that is, the wave form -- crest/dip -- changes position, but
> the material of the medium it is in just jiggles in place).
Jeff Schwab
> On 2008-02-09, Thomas Dybdahl Ahle <lob...@gmail.com> wrote:
>> On Sat, 2008-02-09 at 14:56 +0100, Martin P. Hellwig wrote:
>>>> Propagate, travel, what's the difference?
>>>>
>>> Unfortunately, I didn't study any of this but I sure do remember the
>>> answer one drunk physic said to me in a bar when I ask him the question:
>>> "Does light travel or propagate?"
>>> He answered: "Depends on how you see light."
>>> He must have studied philosophy too :-)
>> Quantum mechanics are closely related to philosophy.
>
> I've never understood that claim. You can philosophize about
> anything: biology, math, weather, the stars, the moon, and so
> on. I don't see how QM is any more related to philosophy than
> any other field in science.
Any science with sufficient room for uncertainty (no pun) will
immediately be claimed as evidence for every pseudo-theory ever imagined
over a bowl of bad weed. "Particles can tunnel anywhere? Ahh, that
must be how the telepaths are doing it."
Bjoern Schliessmann
[parsecs]
> Which is the Earth's orbit. So, long, long ago in a galaxy far,
> far away did they know about the Earth and decide to use it as the
> basis for length in the universe? Even before people on earth
> defined it?
No, even simpler: In the Star Wars galaxy, parsec is a time unit. We
on earth just accidentally defined a unit with exactly the same
name -- which is a distance unit instead. :)
Regards,
Björn
--
BOFH excuse #167:
excessive collisions & not enough packet ambulances
mensa...@aol.com
> In article <13qotf2mgpvk...@corp.supernews.com>,
> �Grant Edwards <gra...@visi.com> wrote:
>
> > On 2008-02-08, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
>
> > > � � � A Parsec is a fixed value (which, admittedly, presumes the culture
> > > developed a 360degree circle broken into degrees => minutes =>
> > > seconds... or, at least, some units compatible with the concept of an
> > > "arc second", like 400 grads of, say, 100 "minutes", each of 100
> > > "seconds")
>
> > It also presumes a standard diamter of that circle.
>
> Which is the Earth's orbit. �So, long, long ago in a galaxy far, far
> away did they know about the Earth and decide to use it as the basis for
> length in the universe? �Even before people on earth defined it? �
>
> Or (ominous music builds here, switch to low voice) is it as some now
> contend? �We are the decendents of a long, lost civilization who
> colonized Earth and used it as a base for their operations to the point
> of adopting it as their own home?
>
> ... �You Betcha!
>
> :-)
How come they spoke English?
>
> --
> -- Lou Pecora
Gabriel Genellina
> So, showing of my physics ignorance: I presume then that this means that
> light, say from the sun, is actually sending particles to the earth,
> since the
> space between is mostly vacuum? Or is there enough material in the
> near-vacuum of space for propogation to occur?
Before the famous Michelson-Morley experiment (end of s. XIX), some
physicists would have said "light propagates over ether, some kind of
matter that fills the whole space but has no measurable mass", but the
experiment failed to show any evidence of it existence.
Then it was hard to explain light propagation as a wave (but Maxwell
equations appeared to be so right!), and previous experiments showed that
light was not made of particles either. Until DeBroglie formulated its
hypothesis of dual nature of matter (and light): wave and particle at the
same time.
--
Gabriel Genellina
mani
> On 5 feb, 05:19, Santiago Romero <srom...@gmail.com> wrote:
>
>
>
> > ( Surely if this question has been asked for a zillion of times... )
> > ( and sorry for my english! )
>
> > I'm impressed with python. I'm very happy with the language and I
> > find Python+Pygame a very powerful and productive way of writing 2D
> > games. I'm not, at this moment, worried about execution speed of the
> > small game I'm working on (it runs at full 60 fps even in an old AMD-
> > K6 450 Laptop computer), but I continue asking me the same question:
>
> > Why not a Python COMPILER?
>
> > It would be very nice to be able to output Linux, MAC or Windows
> > binaries of compiled (not bytecompiled) code. It would run faster, it
> > will be smaller in size (I think) and it will be easy to distribute to
> > people not having python installed. Yes, I know about py2exe, but I'm
> > not sure if that's the right aproach.
>
> > So, what's wrong with compiling python?
>
> > Maybe is not possible due to nature of the language? Is just a
> > decision?
>
> > What do you think about this?
>
> There are some projects aimed to speed up Python by a large margin.
> Right now you can use psyco, which is considered to be feature
> complete, and whose future relies on the Pypy project.
>
> Pypy is a very ambitious project and it aims, amongst many other
> goals, to provide a fast just-in-time python implementation.
> They even say that the "secret goal is being faster than c, which is
> nonsense, isn´t it?" (I still didn´t get the joke though...).
>
> And finally, you have ShedSkin, a project developed by one lonely and
> heroic coder (Mark Dufour).
> Shedskin aims at being a static python compiler, which can translate a
> subset of python to stand alone executables.
> It also can compile extension modules for cpython.
> It works by translating python to c++ and then to machine code.
> The python code must be done in a static way (getting rid of dynamic
> features like, for example, not asigning different types to the same
> variable).
>
> Luis
and Take a look at this page if you look for a plan to develop a fast
python program, you wont regret it.
http://ondrej.certik.cz/development/
Mani
Stefan Behnel
> On Sat, 09 Feb 2008 01:11:09 +0000, Marc 'BlackJack' Rintsch wrote:
>
>> On Fri, 08 Feb 2008 05:12:29 -0800, Ryszard Szopa wrote:
>>
>>> Expressing simple loops as C for loops...
>> You mean simple loops like ``for i in xrange(1000):``? How should the
>> compiler know what object is bound to the name `xrange` when that loop
>> is executed?
>
> Assuming the aim is to optimize for speed rather than memory, the
> solution is for the compiler to create something like this pseudo-code:
>
> if xrange is Python's built-in xrange:
> execute optimized for-loop at C-like speed
> else:
> execute unoptimized normal loop at Python speed
>
> (In case it's not obvious, the decision of which branch to take is made
> at run time, not compile time.)
>
... and Cython, when iterating over lists, for example. That's one of the
reasons why looping is so much faster in Cython than in Pyrex.
Stefan
Grant Edwards
>> Or just the old particle/wave dichotomy... particles
>> travel, waves propagate (that is, the wave form -- crest/dip
>> -- changes position, but the material of the medium it is in
>> just jiggles in place).
> So, showing of my physics ignorance: I presume then that this
> means that light, say from the sun, is actually sending
> particles to the earth, since the space between is mostly
> vacuum? Or is there enough material in the near-vacuum of
> space for propogation to occur?
They act like both waves and as particles depending on what
experiment you do. Though even if you consider them as waves
they don't depend on "jiggling" of a medium. That medium was
called the "luminiferous aether" (aka ether), and in the 19th
century experiments showed conclusively that it doesn't exist:
http://en.wikipedia.org/wiki/Luminiferous_aether
--
Grant Edwards grante Yow! .. I think I'd
at better go back to my DESK
visi.com and toy with a few common
MISAPPREHENSIONS...
casti...@gmail.com
>
> - Show quoted text -
There's always the Visitor pattern.
in xrange(10000).for x:
loop_of_x_at_forlike_speed()
Do identifiers get hashed once at compile/ definition-execution time,
or every time they're encountered? This could be fast...
greg
> Before the famous Michelson-Morley experiment (end of s. XIX), some
> physicists would have said "light propagates over ether, some kind of
> matter that fills the whole space but has no measurable mass", but the
> experiment failed to show any evidence of it existence.
Not just that, but it showed there was something seriously weird
about space and time -- how can light travel at the same speed
relative to *everyone*? Einstein eventually figured it out.
In hindsight, Maxwell's equations had been shouting "Relativity!"
at them all along, but nobody had seen it.
> previous experiments showed
> that light was not made of particles either.
Except that the photoelectric effect showed that it *is* made
of particles. Isn't the universe fun?
> Until DeBroglie formulated
> its hypothesis of dual nature of matter (and light): wave and particle
> at the same time.
Really it's neither waves nor particles, but something else for
which there isn't a good word in everyday English. Physicists
seem to have got around that by redefining the word "particle"
to mean that new thing.
So to get back to the original topic, it doesn't really matter
whether you talk about light travelling or propagating. Take
your pick.
--
Greg
greg
> No, even simpler: In the Star Wars galaxy, parsec is a time unit.
Yep, it's the Paradoxical Second, defined as the average length of
time it takes a person to figure out that the pilot they've
hired is feeding them a load of bull for the purpose of finding
out how long it takes them to notice they're being fed a load
of bull.
--
Greg
Steven D'Aprano
>> Until DeBroglie formulated
>> its hypothesis of dual nature of matter (and light): wave and particle
>> at the same time.
>
> Really it's neither waves nor particles, but something else for which
> there isn't a good word in everyday English. Physicists seem to have got
> around that by redefining the word "particle" to mean that new thing.
I like the term "wavical" to describe that. We're all made of wavicals,
it's just that the wave-like fuzziness is usually too small to notice.
Unless you drink too much tequila.
--
Steven
Steve Holden
migration away from the intuitive. In strict linguistic terms the word
"subatomic" is a fine oxymoron. I suspect it's really "turtles all the
way down".
Grant Edwards
> Well the history of physics for at least two hundred years has
> been a migration away from the intuitive.
Starting at least as far back as Newtonian mechanics. I once
read a very interesting article about some experiments that
showed that even simple newtonian physics is counter-intuitive.
Two of the experiments I remember vividly. One of them showed
that the human brain expects objects constrained to travel in a
curved path will continue to travel in a curved path when
released. The other showed that the human brain expects that
when an object is dropped it will land on a spot immediately
below the drop point -- regardless of whether or not the ojbect
was in motion horizontally when released.
After repeated attempts at the tasks set for them in the
experiments, the subjects would learn strategies that would
work in a Newtonian world, but the initial intuitive reactions
were very non-Newtonian (regardless of how educated they were
in physics).
> In strict linguistic terms the word "subatomic" is a fine
> oxymoron. I suspect it's really "turtles all the way down".
--
Grant Edwards grante Yow! Yes, but will I
at see the EASTER BUNNY in
visi.com skintight leather at an
IRON MAIDEN concert?
Robert Bossy
> On 2008-02-11, Steve Holden <st...@holdenweb.com> wrote:
>
>
>> Well the history of physics for at least two hundred years has
>> been a migration away from the intuitive.
>>
>
> Starting at least as far back as Newtonian mechanics. I once
> read a very interesting article about some experiments that
> showed that even simple newtonian physics is counter-intuitive.
> Two of the experiments I remember vividly. One of them showed
> that the human brain expects objects constrained to travel in a
> curved path will continue to travel in a curved path when
> released. The other showed that the human brain expects that
> when an object is dropped it will land on a spot immediately
> below the drop point -- regardless of whether or not the ojbect
> was in motion horizontally when released.
>
> After repeated attempts at the tasks set for them in the
> experiments, the subjects would learn strategies that would
> work in a Newtonian world, but the initial intuitive reactions
> were very non-Newtonian (regardless of how educated they were
> in physics).
>
speed depends on the weight of the object without realizing it's a
double mistake.
Cheers,
RB
Dotan Cohen
> On 2008-02-11, Steve Holden <st...@holdenweb.com> wrote:
>
> > Well the history of physics for at least two hundred years has
> > been a migration away from the intuitive.
>
> Starting at least as far back as Newtonian mechanics. I once
> read a very interesting article about some experiments that
> showed that even simple newtonian physics is counter-intuitive.
> Two of the experiments I remember vividly. One of them showed
> that the human brain expects objects constrained to travel in a
> curved path will continue to travel in a curved path when
> released. The other showed that the human brain expects that
> when an object is dropped it will land on a spot immediately
> below the drop point -- regardless of whether or not the ojbect
> was in motion horizontally when released.
>
> After repeated attempts at the tasks set for them in the
> experiments, the subjects would learn strategies that would
> work in a Newtonian world, but the initial intuitive reactions
> were very non-Newtonian (regardless of how educated they were
> in physics).
>
I would like to take part in such an experiment.
I should note that movies and such often portray the wrong motion of
objects. Years of that type of conditioning may be responsible for the
non-newtonian expectations of the participants.
Dotan Cohen
http://what-is-what.com
http://gibberish.co.il
א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Gabriel Genellina
escribi�:
> On 2008-02-11, Steve Holden <st...@holdenweb.com> wrote:
>
>> Well the history of physics for at least two hundred years has
>> been a migration away from the intuitive.
>
> Starting at least as far back as Newtonian mechanics. I once
> read a very interesting article about some experiments that
> showed that even simple newtonian physics is counter-intuitive.
The inertia principle is counter-intuitive too, in a real world with
friction. Things don't just "keep going" when impulse cease to exist;
everyone knows that a running car eventually stops if the engine stops.
That it "would" keep moving at the same speed in a straight line is an
abstraction that people hardly can build from experience.
--
Gabriel Genellina
Erik Max Francis
> Grant Edwards wrote:
>> After repeated attempts at the tasks set for them in the
>> experiments, the subjects would learn strategies that would
>> work in a Newtonian world, but the initial intuitive reactions
>> were very non-Newtonian (regardless of how educated they were
>> in physics).
>
> I'm pretty sure we can still hear educated people say that free fall
> speed depends on the weight of the object without realizing it's a
> double mistake.
Well, you have to qualify it better than this, because what you've
stated in actually correct ... in a viscous fluid. Terminal speed is
reached when the force due to gravity is equal and opposite to the drag
force, and the drag force is dependent on the properties of the fluid,
as well as the size and mass of the object that is falling through it.
It's only when you're dealing with objects falling through vacuum that
all objects fall at the same rate, and that's because the gravitational
and inertial masses are identical.
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis
There is nothing so subject to the inconstancy of fortune as war.
-- Miguel de Cervantes, ca. 1600
Erik Max Francis
> Well the history of physics for at least two hundred years has been a
> migration away from the intuitive. In strict linguistic terms the word
> "subatomic" is a fine oxymoron. I suspect it's really "turtles all the
> way down".
Well, hard to say that's been a monotonic pattern. For instance,
Aristotelian physics had an awful lot of components that were fairly
bizarre, counter-intuitive, or even contrary to easily gained
experience. The notion of impetus -- where an object throw moves in a
straight line until it runs out of impetus, then falls straight down --
is clearly contrary to everyday experience of watching two people throw
a ball back and forth from a distance, since the path of the ball is
clearly curved.
Jeff Schwab
> Robert Bossy wrote:
>> Grant Edwards wrote:
>>> After repeated attempts at the tasks set for them in the
>>> experiments, the subjects would learn strategies that would
>>> work in a Newtonian world, but the initial intuitive reactions
>>> were very non-Newtonian (regardless of how educated they were
>>> in physics).
>>
>> I'm pretty sure we can still hear educated people say that free fall
>> speed depends on the weight of the object without realizing it's a
>> double mistake.
>
> Well, you have to qualify it better than this, because what you've
> stated in actually correct ... in a viscous fluid.
By definition, that's not free fall.
Erik Max Francis
In a technical physics context. But he's talking about posing the
question to generally educated people, not physicists (since physicists
wouldn't make that error). In popular parlance, "free fall" just means
falling freely without restraint (hence "free fall rides," "free
falling," etc.). And in that context, in the Earth's atmosphere, you
_will_ reach a terminal speed that is dependent on your mass (among
other things).
So you made precisely my point: The average person would not follow
that the question was being asked was about an abstract (for people
stuck on the surface of the Earth) physics principle, but rather would
understand the question to be in a context where the supposedly-wrong
statement is _actually true_.
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis
I woke up this morning / You were the first thing on my mind
-- India Arie
Erik Max Francis
> On 2008-02-09, Thomas Dybdahl Ahle <lob...@gmail.com> wrote:
>> Quantum mechanics are closely related to philosophy.
>
> I've never understood that claim. You can philosophize about
> anything: biology, math, weather, the stars, the moon, and so
> on. I don't see how QM is any more related to philosophy than
> any other field in science.
It probably comes from reading popularizations that make the really
silly attempt to join physics to Eastern philosophy and metaphysics, for
instance, garbage like _The Tao of Physics_. Modern physics can get
weird and spooky and counterintuitive, but any real connection made with
Eastern philosophy is only in the eye of the beholder.
Erik Max Francis
It's usually spelled _wavicle_, by the way.
Jeff Schwab
> Jeff Schwab wrote:
>
>> Erik Max Francis wrote:
>>> Robert Bossy wrote:
>>>> I'm pretty sure we can still hear educated people say that free fall
>>>> speed depends on the weight of the object without realizing it's a
>>>> double mistake.
>>>
>>> Well, you have to qualify it better than this, because what you've
>>> stated in actually correct ... in a viscous fluid.
>>
>> By definition, that's not free fall.
>
> In a technical physics context. But he's talking about posing the
> question to generally educated people, not physicists (since physicists
> wouldn't make that error). In popular parlance, "free fall" just means
> falling freely without restraint (hence "free fall rides," "free
> falling," etc.). And in that context, in the Earth's atmosphere, you
> _will_ reach a terminal speed that is dependent on your mass (among
> other things).
>
> So you made precisely my point: The average person would not follow
> that the question was being asked was about an abstract (for people
> stuck on the surface of the Earth) physics principle, but rather would
> understand the question to be in a context where the supposedly-wrong
> statement is _actually true_.
So what's the "double mistake?" My understanding was (1) the misuse
(ok, vernacular use) of the term "free fall," and (2) the association of
weight with free-fall velocity ("If I tie an elephant's tail to a
mouse's, and drop them both into free fall, will the mouse slow the
elephant down?")
Lou Pecora
<9635c9ed-ba6e-4172...@f10g2000hsf.googlegroups.com>,
"mensa...@aol.com" <mensa...@aol.com> wrote:
> On Feb 8, 2:53?pm, Lou Pecora <pec...@anvil.nrl.navy.mil> wrote:
> > In article <13qotf2mgpvk...@corp.supernews.com>,
> > ?Grant Edwards <gra...@visi.com> wrote:
> >
> > > On 2008-02-08, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
> >
> > > > ? ? ? A Parsec is a fixed value (which, admittedly, presumes the culture
> > > > developed a 360degree circle broken into degrees => minutes =>
> > > > seconds... or, at least, some units compatible with the concept of an
> > > > "arc second", like 400 grads of, say, 100 "minutes", each of 100
> > > > "seconds")
> >
> > > It also presumes a standard diamter of that circle.
> >
> > Which is the Earth's orbit. ?So, long, long ago in a galaxy far, far
> > away did they know about the Earth and decide to use it as the basis for
> > length in the universe? ?Even before people on earth defined it? ?
> >
> > Or (ominous music builds here, switch to low voice) is it as some now
> > contend? ?We are the decendents of a long, lost civilization who
> > colonized Earth and used it as a base for their operations to the point
> > of adopting it as their own home?
> >
> > ... ?You Betcha!
> >
> > :-)
>
> How come they spoke English?
Because they taught it to us. It's obvious.
--
-- Lou Pecora