What is different with Python ?

R

Roy Smith

Mike Meyer said:
I've never seen someone explain why, for instance, string addition is
O(n^2) beyond the very abstract "it creates a new string with each
addition". No concrete details at all.

I took a shot at that very question a while ago. Elephants never forget,
and neither does google (http://tinyurl.com/9nrnz).
 
M

Mike Meyer

Roy Smith said:
I took a shot at that very question a while ago. Elephants never forget,
and neither does google (http://tinyurl.com/9nrnz).

While that's an excellent explanation of why string addition is
O(n^2), it doesn't really look at the concrete details of the Python
string implementation - which is what I was referring to. I'm sorry
that I was unclear in what I said.

<mike
 
A

Andrew Dalke

Andrea said:
Wow... I always get surprises from physics. For example I
thought that no one could drop confutability requirement
for a theory in an experimental science...

Some physicists (often mathematical physicists) propose
alternate worlds because the math is interesting.

There is a problem in physics in that we know (I was
trained as a physicist hence the "we" :) quantum mechanics
and gravity don't agree with each other. String theory
is one attempt to reconcile the two. One problem is
the math of string theory is hard enough that it's hard
to make a good prediction. Another problem is the
realm where QM and GR disagree requires such high energies
that it's hard to test directly.
I was told that
in physics there are current theories for which there
is no hypotetical experiment that could prove them wrong...
(superstrings may be ? it was a name like that but I
don't really remember).

If we had a machine that could reach Planck scale energies
then I'm pretty sure there are tests. But we don't, by
a long shot.

Andrew Dalke
 
M

Michele Simionato

Andrea Griffini:
Wow... I always get surprises from physics. For example I
thought that no one could drop confutability requirement
for a theory in an experimental science... I mean that I
always agreed with the logic principle that unless you
tell me an experiment whose result could be a confutation
of your theory or otherwise you're not saying anything
really interesting.
In other words if there is no means by which the theory
could be proved wrong by an experiment then that theory
is just babbling without any added content.
A friend of mine however told me that this principle that
I thought was fundamental for talking about science has
indeed been sacrified to get unification. I was told that
in physics there are current theories for which there
is no hypotetical experiment that could prove them wrong...

You must always distinguish between Science (=what we know)
and Research (=what we do not know). Research is performed
with all methods except the scientific one, even if we don't
tell the others ;)

Michele Simionato
 
S

Steven D'Aprano

Roy said:
They're not???

Nope. They are mostly caused by the continents. If the
Earth was completely covered by ocean, the difference
between high and low tide would be about 10-14 inches.
(Over deep ocean, far from shore, the difference is
typically less than 18 inches.)

The enormous difference between high and low tide
measured near the shore (up to 45 feet in the Bay of
Fundy in Canada, almost forty times larger) is caused
by the interaction of the continents with the ocean. In
effect, the water piles up against the shore, like in a
giant bathtub when you slosh the water around.

The true situation is that tides are caused by the
interaction of the gravitational fields of the sun, the
moon and the Earth, the rotation of the Earth, the
physical properties of water, its salinity, the depth,
shape and composition of the coast and shoreline, the
prevailing ocean currents, vibrationary modes of the
ocean (including up to 300 minor harmonics), ocean
storms, and even the wind. You can understand why we
usually simplify it to "the moon causes the tides",
even though the moon isn't even the largest
contributing factor.

See, for example:

http://home.hiwaay.net/~krcool/Astro/moon/moontides/
 
S

Steven D'Aprano

Peter said:
Probably he's referring to something like this, from Wikipedia, which
emphasizes that while tides are caused primarily by the moon, the height
of the high and low tides involves the sun as well:

"The height of the high and low tides (relative to mean sea level) also
varies. Around new and full Moon, the tidal forces due to the Sun
reinforce those of the Moon, due to the syzygy found at those times -
both the Sun and the Moon are 'pulling the water in the same direction.'"

(If I'm right about this, then the statement is still wrong, since even
without the sun there would be high and low tides, just not of the
magnitude we have now.)

Close :)

If tides are caused by the moon, then removing the moon
would end tides. But this clearly isn't true: without
the moon, we would still have tides, only smaller.

On the other hand, the magnitude of the tides is much
larger than the magnitude of the moon's effect on the
oceans (up to forty times larger). So the moon is, at
best, merely a minor cause of the tides.

Of course, all this is quibbling. But it does
illustrate exactly what Cohen and Stewart mean when
they talk about "lies for children". The truth is a lot
more complicated that the simple, easy to understand
"the moon causes the tides".
 
S

Steven D'Aprano

Andrea said:
A friend of mine however told me that this principle that
I thought was fundamental for talking about science has
indeed been sacrified to get unification. I was told that
in physics there are current theories for which there
is no hypotetical experiment that could prove them wrong...
(superstrings may be ? it was a name like that but I
don't really remember).

I think either you or your friend has misunderstood.
There are a number of physics theories where we are
rapidly approaching the point that there are no
PRACTICAL tests we can apply, not that there are no
hypothetical tests imaginable. Physicists are aware of,
and disturbed by, the problem with this situation, and
they like it no better than you do.
 
A

Andrea Griffini

Um, you didn't do the translation right.

Whoops.

So you know assembler, no other possibility as it's such
a complex language that unless someone already knows it
(and in the specific architecture) what i wrote is pure
line noise.

You studied it after python, I suppose.
No, it isn't - because you have to worry about more details.

In assembler details are simply more explicit. Unfortunately
with computers you just cannot avoid details, otherwise your
programs will suck bad. When I wrote in an high level language
or even a very high level one the details are understood even
if I'm not writing down them. After a while a programmer will
even be able to put them at a subconscius level and e.g. by
just looking at O(N^2) code that could be easily rewritten as
O(N) or O(1) a little bell will ring in you brain telling you
"this is ugly". But you cannot know if something is O(1) or
O(N) or O(N^2) unless you know some detail. If you don't like
details then programming is just not the correct field.

In math when I write down the derivative of a complex function
it doesn't mean I don't know what is the definition of
derivative in terms of limits, or what are the conditions
that must be met to be able to write down it. Yet I'm not
writing them every time (some times I'll write them when they're
not obvious, but when they're obvious it doesn't mean I'm not
considering them or, worse, I don't know or understand them).
If you don't really understand what a derivative is and when
it makes sense and when it doesn't, your equations risk
to be good just for after dinner pub jokes.
In particular, when programming in an HLL the compiler will take care of
allocating storage for the variables. In assembler, the programmer has
to deal with it. These extra details make the code more complicated.

Just more explicit. So explicit that it can become boring.
After a while certain operations are so clearly understood
that you are able to write a program to do them to save us
some time (and to preventing us to get bored).
That's what HLL are for... to save you from doing, not to
save you from understanding. What the HLL is doing for you
is something that you don't do in the details, but that you
better not taking without any critic or even comphrension,
because, and this is anoter very important point, *YOU*
will be responsible of the final result, and the final
result will depend a lot (almost totally, actually) on
what you call details.
Just to make another example programming without the faintes
idea of what's happening is not really different from using
those "wizards" to generate a plethora of code you do not
understand. When the wizard will also take the *responsability*
for that code we may discuss it again, but until then if
you don't understand what the wizard does and you just
accept its code then you're not going to go very far.
Just resaying it if you don't understand why it works
there is just no possibility at all you'll understand
why it doesn't work.

Think that "a = b + c" in computes the sum of two real
numbers and your program will fail (expecting, how fool,
that adding ten times 0.1 you get 1.0) and you'll spend
some time wondering why the plane crashed... your code
was "correct" after all.
For instance, whitesmith had a z80 assembler that let you write:

a = b + c

and it would generate the proper instructions via direct
translation.

To use that I've to understand what registers will be
affected and how ugly (i.e. inefficient) the code could
get. Programmin in assembler using such an high level
feature without knowing those little details woul be
just suicidal.
Also, you can only claim that being closer to the chip is "simpler"
because you haven't dealt with a sufficiently complicated chip yet.

True that one should start with something reasonable.
I started with 6502 and just love its semplicity. Now
at work we've boards based on DSP TMSC320 and, believe
me, that assembler gives new meanings to the word ugly.
But saying for example that

del v[0]

just "removes the first element from v" you will end up
with programs that do that in a stupid way, actually you
can easily get unusable programs, and programmers that
go around saying "python is slow" for that reason.

That's an implementation detail. It's true in Python, but isn't
necessarily true in other languages.

Yeah. And you must know which is which. Otherwise you'll
write programs that just do not give the expected result
(because the user killed them earlier).
Yes, good programmers need to know that information - or,
as I said before, they need to know that they need to know
that information, and where to get it.

I think that a *decent* programmer must understand if the
code being written is roughly O(n) or O(n^2). Without
at least that the possibility of writing useful code,
excluding may be toy projects, is a flat zero.
Looking that information later may be just "too" late,
because the wrong data structure has already been used
and nothing can be done (except rewriting everything).
That may well be true of the standard C++ library - I don't write
it. But it certainly doesn't appear to be true of, for instance,
Python internals. I've never seen someone explain why, for instance,
string addition is O(n^2) beyond the very abstract "it creates a new
string with each addition". No concrete details at all.

The problem is that unless you really internalized what
that means you'll forget about it. Don't ask me why,
but it happens. Our mind works that way. You just cannot
live with a jillion of unrelated details you cannot place
in a scheme. It doesn't work. One would do thousand times
the effort that would be done using instead a model able
to justify those details.
This is simply false. The top of an application is the
application-level object

Except that the marketing will continuosly shift what
you application is supposed to do. And this is good, and
essential. This is "building". Sometimes marketing will
change specifications *before* you complete the very
first prototype. For complex enough projects this is more
the rule than the exception. In the nice "the pragmatic
programmer" book (IIRC) is told that there's no known
complex project in which specification was changed less
than four times before the first release... and the only
time they were changed just three times it was when the
guy running with the fourth variations was hit by a
lightning on the street.
Your opposite problem is avoided by not teaching the details until
they are needed, and making sure you teach that those are
implementation details, so they student knows not to draw such
conclusions from them.

What you will obtain is that people that will build
wrong models. Omitting details, if they can really
affect the result, is not a good idea.
This is completely different from omitting details
that no one without a 3km particle accellerator
could detect to kids in 4th grade school.
As mentioned, you see it all the time in c.l.python. People come from
other languages, and try to write Python as if the rules for that
other language apply.

That's exactly because they don't know the details of
any of the languages you used. Someone knowing the
details would be curious to know *how* "del v[0]"
is implemented in python. Actually it could be changed
easily in an O(1) operation with just a little slowdown
in element access (still O(1) but with a bigger constant).
This is a compromise that has not been accepted and
this very fact is important to know if you plan to
use python seriously.
It can be fixed from the start by teaching the student the difference
between abstract programming concepts and implementation details.

Sorry, but I really don't agree that big O is a "detail"
that could be ignored. Only bubble-and-arrow powerpoint
gurus could think that; I'm not in that crew.
Ignore those little details and your program will be
just as good as ones that don't even compile.
It tackled abstract problems like "sorting". The students I'm talking
about never dealt with anything that abstract.

Sorting is abstract ?
Now you're resorting to straw men and name-calling. That's an
indication that you no longer have any real points.

I'll blame my bad english for understanding that you
said that abelian groups should be taught before
relative numbers (somehow I crazily thought the point
of discussion was what's the correct order of learning
how to program), that TAOCP is too abstract (a book
where every single code listing is in assembler!)
and that big-o when programming is a detail that can
be safely ignored (good luck, IMO you'll need hell a
lot of it).

Andrea
 
P

Peter Maas

Magnus said:
Aha. So you must learn cosmology first then. I don't think so. ;)

I wasn't talking about size but about sensual accessibility. And
I'm going to withdraw from this discussion. My English is not good
enough for this kind of stuff. And ... it's off topic! ;)
 
J

James

If you're thinking of things like superstrings, loop quantum gravity
and other "theories of everything" then your friend has gotten
confused somewhere. There is certainly no current experiments which we
can do in practise, which is widely acknowledged as a flaw. Lots of
physicists are trying to work out low-energy consequences of these
theories so that they can be tested, but the maths is extremely hard
and the theories aren't even well understood in many cases; but that
doesn't mean that they've decided that they'll accept them fully and
not bother testing them!
 
P

Peter Hansen

Steven said:
Nope. They are mostly caused by the continents. ...
The true situation is that tides are caused by the interaction of the
gravitational fields of the sun, the moon and the Earth, the rotation of
the Earth, the physical properties of water, its salinity, the depth,
shape and composition of the coast and shoreline, the prevailing ocean
currents, vibrationary modes of the ocean (including up to 300 minor
harmonics), ocean storms, and even the wind. You can understand why we
usually simplify it to "the moon causes the tides", even though the moon
isn't even the largest contributing factor.

See, for example:

http://home.hiwaay.net/~krcool/Astro/moon/moontides/

Steve, please go and read that page again. While I readily accept that
you may be far more of an expert on tides than I, Roy, and whoever
contributed to the Wikipedia article, nearly every section on the page
that *you* referenced directly contradicts your basic claims. I quote:

"Tides are created because the Earth and the moon are attracted to each
other..."

"The sun's gravitational force on the earth is only 46 percent that of
the moon. Making the moon the single most important factor for the
creation of tides." [you said the moon isn't the largest factor]

"Since the moon moves around the Earth, it is not always in the same
place at the same time each day. So, each day, the times for high and
low tides change by 50 minutes." [if the moon were not such a large
cause, it wouldn't have this effect]

I believe you are still just saying that the *magnitude* of the tides is
greatly affected by other things, such as the shoreline, but what I keep
reading is you basically saying "the moon is not the cause and is only a
minor factor".

I also see nothing to suggest that if the moon and the sun were removed
from the picture, there would be much in the way of tides at all. (The
page you quoted says the sun has about 46% the effect of the moon which,
if true, means the statement "the presence of the moon and the sun cause
tides" still seems pretty accurate, certainly not a "lie for children"
but merely a simplification, if anything.

-Peter
 
A

Andrea Griffini

If you're thinking of things like superstrings, loop quantum gravity
and other "theories of everything" then your friend has gotten
confused somewhere.

More likely I was the one that didn't understand. Reading
what wikipedia tells about it i understood better what is
the situation. From a philosophical point of view I think
however looks like there is indeed a problem. Is just a
theorical - but infeasible - experiment for confutation
sufficient ?

I think I triggered my friend telling him that I found on
the web a discussion about a certain book of theorical
physics was considered just a joke made up by piling
physics buzzwords by some, and a real theory by others.
Finding that even this was a non-obvious problem amused
me, and he told me that advanced physics now has this kind
of problems with current theories that are so complex
and so impossible to check that it's even questionable
they're not breaking logic and the scientific method
and are instead a question of faith and opinions.

Andrea
 
R

Roy Smith

Steven D'Aprano said:
Nope. They are mostly caused by the continents. If the
Earth was completely covered by ocean, the difference
between high and low tide would be about 10-14 inches.

Yeah, I know about all that stuff. But, let's explore this from a teaching
point of view.
The true situation is that tides are caused by the
interaction of the gravitational fields of the sun, the
moon and the Earth, the rotation of the Earth, the
physical properties of water, its salinity, the depth,
shape and composition of the coast and shoreline, the
prevailing ocean currents, vibrationary modes of the
ocean (including up to 300 minor harmonics), ocean
storms, and even the wind.

That's a lot of detail to absorb, and is appropriate for a college-level
course taken by oceanography majors. The key to teaching something is to
strip away all the details and try to get down to one nugget of truth with
which you can lay a foundation upon which further learning can happen.

Yes, both the sun and the moon have gravitational fields which affect
tides. But the moon's gravitational field is much stronger than the sun's,
so as a first-order approximation, we can ignore the sun.

And, yes, there's a huge amplifying effect caused by coastline shape and
resonant frequencies of the ocean basins, but if you took away the moon
(remember, we're ignoring the sun for now), there would be no tides at all.
If you took away all the continents, there would still be tides, they would
just be a lot less (and nobody would notice them!).

And, yes, wind affects tide. I live at the western tip of Long Island
Sound. If the wind is blowing hard along the axis of the Sound for a solid
day or two, I can see that it has a drastic effect on the tides.

This says to me that "The tides are created by the moon, amplified by the
shapes of the land masses, and altered by the wind".

Sure, "the moon causes the tides" is not the whole picture, and from a
quantitative point of view, may not even be the major player, but from a
basic "How do I explain this physical process to a 6th grade child in a way
that's both easy to understand and fundamentally correct", I think "the
moon causes the tides" is the only reasonable explanation. Once that basic
idea is planted, all the other stuff can get layered on top to improve the
understanding of how tides work.

So, to try and bring this back to the original point of this thread, which
is that Python is a better first language than C, let's think of the moon
as the "algorithms, data structures, and flow control" fundamentals of
programming, and memory management as the continents and ocean basins.
What you want to teach somebody on day one is the fundamentals. Sure,
there are cases where poor memory management can degrade performance to the
point where it swamps all other effects, but it's still not the fundamental
thing you're trying to teach to a new CS student.
 
T

Terry Hancock

Teaching kids is different than teaching adults. The
latter can often take bigger steps and start from a
sound understanding of logical and intuitive thought.
"Simple" for an adult is different than for a child.

Of course, since children are vastly better at learning than
adults, perhaps adults are stupid to do this. ;-)

Quantum mechanics notwithstanding, I'm not sure there
is a "bottom" "most-reduced" level of understanding. It's
certainly not clear that it is relevant to programming.

It is invariably true that a deeper understanding of the
technology you use will improve your power of using it.
So, I have no doubt that knowing C (and the bits-and-bytes
approach to programming) will improve your performance
as a programmer if you started with Python. Just as learning
assembler surely made me a better C programmer.

But I could write quite nice programs (nice enough for my
needs at the time) in BASIC, and I certainly can in Python.

Sometimes, you just don't care if your algorithm is ideal, or
if "it will slow to a crawl when you deliver it to the customer".

When did the "customer" get into this conversation? I mean,
you're a neophyte who just learned how to program, and you're
already flogging your services on the unsuspecting masses?

In my experience, people first learn to program for their own
needs, and it's only a long time later that somebody decides
they want to become a professional. And maybe, when you're
a pro, knowledge of machine details is really important.

But an awful lot of people just want to putz around with the
computer (or more accurately just want to solve their own
problems using it). Surely, they don't need to know anything
about quantum transitions, transistors, or malloc to do that.

In fact, I find such stuff introduces a lot of noise in my
thinking with Python. Awhile back I wanted to write a
program that would take a title like "My fun trip to Europe,
and a thousand and one things I saw there" and make a
mnemonic file-name less than 32 characters long out of it,
that obeyed simple naming conventions. I wanted it to spit
something out like "trip_europe_1001_things", the way a
human might name such a file. Well, first of all, with all
the clutter involved in processing strings, I would never
have tried this in C, it would've taken me a month! But
my real point follows ...

I used several different methods to go about squeezing down
a title to get rid of "less important" words.

For one, I wanted to know what the most common words were,
so I could make a hit list of words to delete from titles. I did this
using three or four titles from Project Gutenberg, and the Python
interpretor. It took maybe fifteen minutes, and went something
like this:

s = open('cia_factbook', 'r').read() + open('pride_prej', 'r').read() + open('alice', 'r').read()
words = s.split()
unique_words = {}
for word in words:
unique_words[word] = unique_words.get(word, 0) + 1
word_freqs = unique_words.items()
word_freqs.sort(lambda a,b: cmp(a[1],b[1]))
for word, freq in word_freqs[:100]:
print "%5d: %s" % (word, freq)

This is, of course, totally brutal on my computer's memory allocation,
because the source data is quite large. So, my C programming
instincts would've encouraged me to do all kinds of optimizing. But
why bother? Like I said, it took 15 minutes. Done. And that includes
the programming time. I took a completely naive approach and
it worked, so why should I bother making it hard for myself?

Sure, in the profession of writing commercial, off-the-shelf word counting
software to sell to "the customer", I should be truly ashamed, but who
cares? I didn't even save this program to disk, I've just tried to rewrite
it from memory here.

The idea that one must learn assembler to learn C and in turn
to learn Python strikes me as elitist or protectionist --- just another
way to turn people away from programming.

You should learn that stuff when it becomes obvious that you need it,
not from the outset. And for many people, it simply may never be
needed. Python is actually remarkably good at solving things in a
nearly optimal way.

This program also had another interesting property -- it couldn't have
a rigid specification. There's no way to write one, it has to succeed
intuitively, by producing output that is "mnemonic". But there's no
way to unit test for that. ;-) So no amount of "deep understanding of
what the machine is doing" would've really helped that much.

I think there's an awful lot of programming out there that is like that --
the problem is about solving a problem with appropriate *ideas*
not trying to find the most efficient *methods*. Often, it's not how
efficiently I can do a thing that interests me, but whether it can be
done at all.

I don't think total reductionism is particularly useful for this. My
thermodynamics professor once argued that, never having seen any,
but only knowing the laws of physics and thermodynamics, that
physicists would never have predicted the existence of *liquids*,
let alone oceans, nucleic acids, and life forms. The formation of those
things is still far beyond us on first-principles, and surely even if we
do come to an understanding of such things, the particular biology
of, say, flowering plants will be almost completely unaffected by such
knowledge.

Likewise, the creation and study of more complex ideas in software
is unlikely to benefit much from assembler-level understanding of
the machines on which it runs. It's simply getting too close to the
problem --- assembly language problems have become so well
understood, that they are becoming a domain for automated solution,
which is what high-level programming is all about.
 
T

Terry Hancock

The best I've heard is "Informatics" -- I have a vague impression
that this is a more European name for the field.

It's the reverse-translation from the French "Informatique".
 
T

Terry Hancock

Oh well, I guess it's a bit late to try to rename the Computer
Science discipline now.

Computer programming is a trade skill, not a science. It's like
being a machinist or a carpenter --- a practical art.

Unfortunately, our society has a very denigrative view of
craftsmen, and does not pay them well enough, so computer
programmers have been motivated to attempt to elevate the
profession by using the appellative of "science".

How different would the world be if we (more accurately)
called it "Computer Arts"?
 
T

Terry Hancock

I also see nothing to suggest that if the moon and the sun were removed
from the picture, there would be much in the way of tides at all. (The
page you quoted says the sun has about 46% the effect of the moon which,
if true, means the statement "the presence of the moon and the sun cause
tides" still seems pretty accurate, certainly not a "lie for children"
but merely a simplification, if anything.

Okay, I haven't read the book, but I suspect that "lies for children" means
very much that it is merely a simplification. Every simplification is a lie.
You have to distort the truth in some way to make it simpler.

This is done with the best intentions, and the understanding is that
next year, when the child is a little older, you will contradict that lie
with another lie that is a little closer to the truth. Trying to start with
"the Truth" is impossible because:

1) You don't know the Truth either, just a much higher-order lie.
2) Your pupil can't handle the Truth yet.

This has more to do with the nature of Truth than with the ethics
of teaching, you see. ;-)

Certainly, I have this understanding of how science is taught. This
is why I really, really hate "true-false" tests. Because, while they
may be easy for people who rely only on the knowledge learned in
class, they are extremely hard for people who learn on their own ---
which bit of the truth am I not supposed to know, I ask myself.

For example, is the statement "Viruses are made of DNA" true, or
false?

In high school, the answer might be "true", but in college it is
certainly "false", because some viruses are made of RNA, and most
are also made of protein, and even a few have a membrane or
"envelope" analogous to a cell.

Virtually everything is more complicated when you look at it closely.

For example, consider these statements:

"The Earth goes around the Sun"

No, actually the Sun, Earth, and all the rest of the planets go around
something called the "barycenter" or "center of gravity" of the whole
solar system. Now, since more than 99% of the mass in the Solar
System is in the Sun, that's pretty close to the Sun, but it isn't quite.
In fact, IIRC, it isn't even inside of the photosphere, due to Jupiter
being so massive.

"The Moon orbits the Earth"

See above, although the barycenter is beneath the Earth's crust. But,
more importantly, the Moon is only "loosely bound" to the Earth, it
never actually goes backward relative to the Earth-Moon orbit around
the Sun, and if the Earth were, say, destroyed to make way for a
hyperspace bypass, the Moon would settle pretty happily into almost
the same orbit as the Earth has now. In fact, the Moon isn't a moon,
the Earth-Luna system is really a binary planet. *Moons* are what
Mars and Jupiter have (for example).

"Plants consume CO2 and make O2"

Well, yes, but they also consume O2, just like animals. *On balance*,
the statement is *usually* true. But most plants would probably
die in a pure-CO2 environment (unless they can drive the atmosphere
to a better composition fast enough).

And as for the subject line, I'd say the Python list is very much
at high-tide here. ;-)
 
C

Claudio Grondi

Yes, both the sun and the moon have gravitational fields which affect
tides. But the moon's gravitational field is much stronger than the sun's,
so as a first-order approximation, we can ignore the sun.

Here we are experiencing further small lie which found its way
into a text written by an author probably not aware, that he is
creating it.
I have picked it out, not because I am so biased towards
the very detail, but because it is a good example of how hard
it is to discuss without creating small lies one after another.

The school books are filled with statements similar to the above
causing endless confusion and misunderstandings.

"the moon's gravitational field is much stronger than the sun's"
....
Sure it is the opposite, i.e. the gravitational field of the sun is
much stronger than that of the moon. What was intended to
state is probably, that the gravitational force caused by attraction
of the masses of earth and the sun applied to earth is lower
than the gravitational force caused by attraction of the masses
of earth and the moon (applied to earth).
I am sure, that if someone will analyse the statement above
deep enough he will find some more small lies originated
by the temptation to keep any statements short and simple
without giving a precise definition of all assumptions
required to be known in order to understand it right.

What leads to confusion is also the explanation that the water
of the oceans is attracted by the moon. It is only half of the
true. The another half is, that the moon is attracted by the
water of the oceans. It is very interesting, that in the minds
of many people the gravitational force acts only on one body.
Many think I am stupid, when I try to insist that the gravitational
force a human body exerts on earth is the same as that which
the earth exerts on a human body.
"the human body is so small, so the gravitational force it exerts
on earth can be neglected compared to the gravitational force
the earth exerts on the human body" is the explanation.

The problem of science is, that for communication of its findings
it has to use the same language which is used also for many other
purposes. The problem of text writers is, that it is so convienient
to use shortcuts to what one thinks, but has just forgotten to mention
before. It is also common to expresses own thoughts in an
inappropriate way because at the moment the right words are just
not there.

Hope this above has cleared away all what was clear before ;/)

What has it all to do with Python? To be not fully off-topic, I
suggest here, that it is much easier to discuss programming
related matters (especially in case of Python :) or mathematics
than any other subjects related to nature, because programming is
_so easy_ compared to what is going on in the "real world".
I see the reason for that in the fact, that programming is based
on ideas and rules developed by humans themselves, so it is
relatively easy to test and proove if statements are right or not.
Exception is when the source code is hidden like the rules
directing the behaviour of our Universe, what sure shouldn't be
interpreted, that people hiding source code behave more
like The Creator than others making it public ;/)

Claudio
 
R

Roel Schroeven

Terry said:
"Plants consume CO2 and make O2"

Well, yes, but they also consume O2, just like animals. *On balance*,
the statement is *usually* true. But most plants would probably
die in a pure-CO2 environment (unless they can drive the atmosphere
to a better composition fast enough).

Ha, finally one I can comment one with a reasonable level of confidence.
On balance, plants consume CO2 and produce O2 *as long as they are
growing*. You see, they use the C from the CO2 to build the material
they are made of. Once they are full-grown, the amount of O2 produced by
their photosynthesis is balanced by the amount of O2 consumed by their
respiration; the same goes for the CO2 produced in consumed in both
processes.

This can be generalized to whole forests too. Often people think that
the Amazon rain forests produce large quantities of O2, but that's just
not true. During their initial growth, they indeed produced large
quantities of O2. As long as they stay the same size (the same amount of
biomass actually), there is no net effect. Now that large areas are
burnt to make place for roads and agriculture, the CO2 comes back in the
atmosphere while O2 from the atmosphere is consumed in the flames.

It's very well possible that this is a simplification that glosses over
a few details such as other sources of carbon, but in general it's good
enough.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,768
Messages
2,569,575
Members
45,053
Latest member
billing-software

Latest Threads

Top