It may be that electrons and quarks are made up of smaller particles. However, there is thought to be a limit to how small a particle can be, called the Planck Length, which is 1.6160e-35m. I don't pretend to fully understand the reasons behind this, but essentially under our current theories, that's the smallest length that makes any sense.
There's also some evidence to suppose that the Universe may be more discrete than continuous. We know energy is divided into packets of energy, called quanta, rather than a continuous flow. Because energy does not appear to be able to be subdivided beyond a certain point, it makes sense that matter would adhere to the same principles.
Since the Universe we live in is finite in size and mass, and that all calcuations for size in our theories are multiples of the Planck length, one might suppose there is also a lower limit.
There's also an upper limit for density, of course. A particle that is too dense would collapse into a black hole. So a particle with a certain mass can only get so small.
However, that might be all wrong; there's no current way to tell.
I mean why does light behave differently when its made up of the same 'matter' (i.e electron/proton) as you and me? Why will it travel at the same speed no matter whats the speed of the observer is?
Photons, the particles that make up light, have zero mass. According to relativity, any particle with zero mass travels at the speed of light when in a vacuum.
We, on the other hand, do have mass, which prevents us from travelling faster than light, and the reason for this lies in E = mc^2.
This equation essentially says two things. One, that mass can be converted into energy, such as in a nuclear bomb. Two, that if you give a particle energy (ie. accelerate it), its mass increases (or rather, multiplies by what's known as the Lorentz factor. Hence the reason why particles of zero mass aren't subject to this; any number multiplied by zero is still zero).
So as you accelerate, you gain mass, although this is only really noticable at velocities approaching the speed of light. The nearer to light you get, the more mass you have, and the more energy you need to accelerate further. To accelerate a particle with mass to the speed of light would require an infinite amount of energy.
In other words, the only reasons photons travel at the speed of light is only because they're massless. We cannot because we have mass. But why this strange cosmic speed limit exists in the first place is, as far as I know, unknown.
Time dilation on the other hand...if you wave your arms around, your hands age a tiny bit slower than your torso...does that make sense?
Unfortunately when you start to get into General Relativity and Quantum Theory, things start making a lot less 'sense' than we are used to. Our experiences of the Universe are just experiences gained from a very small part of it, and the Universe doesn't always behave the way we would expect it.
For instance, if you were travelling 55mph, and following a car doing 60mph, you'd expect to see that car moving away from you at 5mph. That's commmon sense.
But common sense doesn't always work. If you were travelling at 95% of the speed of light, following a light ray travelling at 100% of the speed of light, you'd expect it to see it moving away from you at 5% of the speed of light. Actually, the light ray moves away from you at 100% of the speed of light. No matter how fast you go, the light ray will alway move away from you at the same speed.
This is strange behavour, but it's been proved again and again. When people first discovered this, the experiments were run again and again, but the results always turned out the same. And from this result, Einstein pointed out that time dilation was a logical consequence. If the speed of light is constant, then time dilation must be taking place.
Realise that our ideas about what makes 'sense' are derived from the world around us. In the realm of the very large, or the very small, things are very different. For instance, we know that in space things don't slow down, because there's no air resistance or friction. This seems obvious to us now, but in the past it was 'common sense' that in order to keep something moving, you had to keep pushing it.
Look at it another way, then. Imagine you're in a transparent glass train carriage, idly bouncing a tennis ball upon the floor. From your perspective, the tennis ball just goes up and down.
Now imagine an observer standing on a train platform. He sees you as you zip past in your expensive transparent train carriage, and observes the way your tennis ball moves. To the observer, the tennis ball appears to follow a parabola, because from the time the ball hits the floor to the time the ball gets back to your hand, your train carriage has moved on.
Now think about the distances involved. From your perspective, the tennis ball has just travelled up and down. If you're bouncing it from a metre's height, then the total distance of one 'bounce' is two metres; from your hand to the floor and back again.
Assume the train travels 10m in the time it takes you to bounce the ball once. Then to the observer upon the platform, the ball has travelled 2m in the vertical direction, and 10m in the horizontal direction. Whilst you might insist the ball has only travelled 2m vertically, the observer will insist the ball traveled much further, because the train was moving at the time.
Light is always a constant speed. This differs from the way we're used to the world working. If a car is doing 60mph, and you're chasing it doing 50mph, then the car you're chasing will appear to move away from you at 10mph.
Light is different. Light travels at c, which is 299'792'458 m/s. If you were in a spaceship chasing after a light-ray, and your speedometer says you're doing 90% of c, then you might expect the light ray to move away from you at 10% of c. But this isn't what happens. Light is always a constant speed, so the light ray moves away from you at c. No matter how fast you go, you'll never seem to gain upon the light ray.
Lets go back to our balls on the train. Instead of a ball, imagine a light ray bouncing between two mirrors. To a person on the train, the light ray appears to be travelling vertically, whilst to a observer at the station, the motion of the (very fast) train makes the light beam appear to bounce diagonally. This diagonal distance the observer sees is longer than the straight-up vertical distance you see, so to the observer, the light ray takes longer to bounce between the two mirrors. In other words, for the observer, time inside the train appears to move more slowly.
Time dilation is absurd. The idea that time is a physical object that can be manipulated is an extreme claim. Those require extreme evidence. If you think it happens
show me.
You seem to be a very skeptical person, or perhaps you have not looked very far, In 1971, experiments were carried out using four caesium beam atomic clocks (The Hafele-Keating Experiment). Two of the atomic clocks were put on commercial jets and flown in opposite directions around the world. The predicted time dilation matched up to the difference in the atomic clocks.
I find it rather unlikely that this is a coincidence. What are the chances that two pairs of atomic clocks would fail, and fail by exactly the same amount as theory predicts. Pretty slim.
Of course, this was an experiment done on the macroscopic scale. In particle accelerators, time dilation directly affects the half-life of particles such a muons. Thousands of experiments have confirmed that the half-life of particles is affected by velocity in the exact way that Einstein predicted. Again, this is very hard to chalk down to coincidence.
Furthermore, experiments with the speed of light show that the speed of light is constant. Albert Michelson and Edward Morley tested the speed of light parallel to the Earth's velocity, and perpendicular to it; there was no difference in the results. From this we can conclude that either the experiment, and all the hundreds similar experiments performed after, were fundamentally flawed in precisely the same way (a stretch of the imagination). That the earth does not move around the sun. Or that the speed of light is independant of one's velocity. Indirectly, if these experiements are correct, this proves time dilation.
How? Consider a man on a spaceship travelling at high speeds. Upon the floor of his spaceship is a laser, a light sensor, both connected to a very accurate stopwatch. Upon the ceiling is a mirror. When the man presses a button, the laser beam is fired up at the mirror, and the stopwatch starts timing. The laser beam will bounce off the mirror, hit the light sensor, and the stopwatch will stop. Thus, the man will now know the time it takes for a laser beam to cover the distance between the laser beam, the mirror, and the light sensor.
With me so far? The problem comes when an observer upon the earth watches the spaceship zip past. To the man inside, the laser beam heads straight up and down, taking a purely vertical path. To the observer on earth, the spaceship moves horizontally whilst the experiment takes place, so to the observer, the laser-beam takes a longer, diagonal path. Because light is a constant speed, to the observer, the light beam travels at the same speed for both the observer and the man in the spacecraft. However, for the observer, the light beam travels a further distance than for the man in the spaceship, and therefore takes a longer time. So to the observer, the whole event takes a longer time than it does for the man inside the spaceship. That's time dilation.
In case you're interested in looking at the source, main.py is the best place to start to figure out what things do. Some interesting things to do are:
That should make it easier to see what the code is doing, without the many randomising gaussian functions getting in the way. The above functions are used to control the tree's formation.
branch_number() defines the number of branches at any one depth (ie. the number of generations away from the root). In the above case, branch_number() will give each branch three children up to the fouth generation.
angle() defines the angle that a branch differs from its root. In this case the yaw is always 30 degrees, and the branches are spread equally throughout the roll.
length() defines the length of the branches based upon their depth and their life (number of generations until a branch tip).
make_polygon() defines the encompassing rings that flesh out the tree. The number of edges and the radius of the ring decreses as the branch thins out to a tip (where life = 0).
When I end a {}, I always append a statement about what I'm ending:
//... 100 lines of code...
}// End wombat smacking block.
How would you do that in a language with no explicit block delimiter?
Um, like this?
def wombatsmack():
100
lines
of
code... # end wombatsmack block
I can't see what readability a single brace adds to a program.
I find languages like Ada the ideal, since they force you to say what block element you are terminating. Does that mean they're inherently better, somehow? Sure, it's more "clutter", but it conveys meaning. You sound like the kind of person that may describe commenting as clutter - in which case, stay away from me, foul beast.;)
It's true that I tend to use very little comments in Python, but that's because doc-strings are often enough. I tend to be of the school of thought that favours splitting a program into many small functions that do one thing and one thing only.
Clutter I define as elements of a program that don't add much information to your code. Semicolons are often clutter; you only truly need them in the very rare instances where you might want to put more than one instruction upon one line. Braces are clutter, at least to me, because whitespacing does the job much better. I suspect I'd have no objection to languages like ADA in theory, but I suspect I'd soon grow weary of typing out end block delimiters:)
I've also never had a problem with knowing where Python blocks end, either. But then again, I've never had a situation where I've had a blocks that are 100 lines long (except with classes, but it's pretty simple to see where they end:). Python's whitespacing method is optimum for me, but your mileage may vary.
How about encryption and security, SOAP, ORB, web services, directory services, messaging services? You know, all those things that distinguish large enterprise applications from normal business applications.
I do suppose if your definition of a good enterprise language is one with all such libraries included, then Python isn't a very good enterprise language. Of course, one could argue that the benefits of Python outweigh the disadvantages at having to download extra packages to handle SOAP, ORB etc.
The difference between Java and Python is similar to the difference between C# and Visual Basic.
I'm a little confused. Are you saying that Python is inferior to Java because Java comes with library X included, whilst with Python library X has to be downloaded separately?
Python is slower than Java and higher level than Java, but beyond that I can't say that there's too much separating Java and Python as languages. Personally, I find programming in Python more efficient, despite having more years experience with Java, but that may be just me.
I used to use Perl extensively. Now I hardly ever do, except in the case of a shell-script substitute. I find that Python programs tend to be easy to read. They feel less hacky.
However, I think you're correct about sort(), and int() does indeed fail with strings representing floating points. But I've never found the practice of exception throwing in Python at all objectionable, and I've never had an experience where I've had to use 'try' too much.
The lack of auto-initialisation is of debatable worth. I've always used 'use strict' under Perl; initialising one's variables is preferable to plucking them out of the ether - at least in most circumstances.
As for the slowness of Python, I've never come across a situation where it would be noticable. Unless you're trying to design a cutting edge 3D game engine totally in Python, I should think Python's speed wouldn't be a problem.
Truncate. But it shouldn't matter except for very large values of N, because it's just to remove the slight rounding errors one gets when...
Come to think of it, it should really round. Otherwise 4.9999999999999999 would come out as 4.
Well, slap a 'round' in before the int, and it should all be okay:)
I can't think of many instances when one would have to rewrite a part in C. I do suppose that if you were using Python to develop a 3D game, then you might want to write the engine in C. But I can't think of many other cases when you absolutely need the speed of compiled C.
I find it reduces clutter in my code. For instance:
if (x == 2) {
printf("Blah blah"); }
As opposed to:
if x == 2:
print "Blah blah"
The question is not so much why one should have a language with whitespace significance, but why one should not. Since the vast majority of well-written programs use whitespacing in this manner already, it makes some sense to do away with braces and semi-colons when they're not really needed.
Assume for a moment that programmers can code more effectively in Python than in Java. Then those companies that use Python over Java will have an advantage. If a company dismisses Python as just 'a cute scripting language', then they might find themselves losing out to their competitors that do use Python.
So I don't think it's inconceivable that Python might replace Java eventually, at least in the more successful companies. It's also early days for.NET too. I wouldn't rule out Microsoft just yet.
Perhaps I'm a little naive, but I do believe that eventually programming practises will improve. I'm sure they can't get much worse!:)
But I do understand your point. Different languages have different ways of doing things. The most efficient algorith in C, for instance, may not directly translate to the most efficient algorithm in Python.
I've never had any problems with Python's speed. It's fast enough for web applications. It's fast enough to use GUI toolkits. It's even fast enough for simple OpenGL demos (a shameless plug, I know, but it seemed relevant).
If you come across a situation where Python is too slow for what you want to do, then Python can work happily enough with libraries programmed in C. If that's still not fast enough, then use a different language. But I suspect that for 95% of all programming tasks, Python is fast enough.
Actually, I believe that JScript, which IE uses, is a superset of ECMAscript (AKA 'standard' javascript). In other words, IE uses Javascript with extras.
I'm not too sure where Firefox lacks in Javascript support; so far as I know it does have 100% compatibility. However the only problems I have ever had with javascript and Firefox is when the javascript is coded incorrectly. IE is more tolerant of broken code than Firefox is.
For instance, the UK Job Centre's job-search webpage uses javascript that works in IE but not in Firefox. The root of the problem in this case is bad coding. In Firefox, the function getElementById it does exactly what it says and no more; it returns an element object dependant on the id attribute. In IE, getElementById gets elements by their id or by their name. Presumably this is to help compensate for shoddy developers mistakes, yet it has the added disadvantage of producing invalid javascript.
I'm curious to know; what sites that use javascript have you found that don't work in Firefox? If I were a betting man, I'd be willing to wager that all the problems you find are down to shoddy javascript errors that IE glosses over. In other words, the problem lies with the website developer.
Apparently this is not a black hole, merely an object that exhibits some black-hole like properties. However, so far as I know, the formation of a black hole depends only on the volume to mass ratio being small enough. I assume that as one pushes matter together, even on the subatomic scale, there comes at point where the gravitational force will become dominant. Certainly this Black Hold FAQ answer seems to indicate that subatomic black holes are theoretically possible.
You are also correct to assume that Hawking Radiation does not happen in a true vacuum, i.e. a piece of space devoid of mass and energy. However, quantum physics suggests that there is no such thing as a true vacuum; on the subatomic scale, the fabric of space froths. Particle/anti-particle pairs are created from nothing. These virtual particles zip apart, then are pulled back together again and annihilate themselves. The total mass/energy gained through these interactions always remains at zero.
However, in my rough, layman's grasp of Hawking Radiation, this changes near the event horizon of a black hole. If one of a virtual particle pair crosses the event horizon, and the other does not, then a curious thing happens (at this point, my understanding of the process breaks down quite a bit). As far as I know, the virtual particles are created in a sort of quantum flux; because they haven't been observed, the particles have not 'decided' which of them is to be the anti-particle, and which is to be made of normal matter. The act of falling into a Black Hole makes a virtual particle into an anti-particle, and thus, the virtual particle outside the black hole becomes a piece of normal matter.
The overall effect is that a black hole gives off radiation, and shrinks due to small particles of antimatter passing through the event horizon.
Note that IANAP, and thus I am probably mostly wrong:)
I have to disagree. The lack is not in code or tools to produce code... The lack is in content
I agree. From my experiences, programming on Linux is generally easier and less expensive than Windows. Almost all Linux distributions come with a whole host of development tools (kdevelop, gcc, etc), and Linux has a lot of libraries already included (libpng, zlib, etc).
Next on the list is NetHack. NetHack is a terminal-based game (not that I think that this inhibits gameplay, as I just finished a four-hour stint playing Tales of Middle Earth), with extremely simplistic tile-based graphics. There have been a few attempts to improve things -- Falcon's Eye is a notable NetHack fork, with music and alpha-blended graphics -- but still nowhere near modern commercial-quality graphics. Now, as the NetHack aficionados among you know, NetHack can be a lot of fun, and while long-term replayability depends more on game logic than graphics, anyone who thinks that graphics and sound don't play a key role in making a game enjoyable is simply not being honest with themselves (and I would suggest that they try watching a horror movie with the sound off).
Whilst I like eye-candy, I actually prefer text-mode Nethack over graphical Nethack interfaces like Falcon's Eye. Text-mode is a lot easier to play; the entire dungeon is on one screen (unlike Falcon's Eye), so you can't get lost. And once you get to know the symbols, it's a lot easier to tell a 'c' from an 'D' or an 'O' than it is with a small sprite (like in Qt-hack).
Or a Telnet interface with a password of "private" (DLink ADSL routers as of 2002)
It is my understanding that the telnet port isn't accessable outside the local network for D-Link routers. However, if you have evidence to the contrary, I'd really like to know:)
They already have a more fine-grained file permissions model than Linux.
If I recall, the only practical difference between the Linux and Windows permissions systems is that in Linux, only the owner of a file and the root may change the permissions. In Windows, one may set it up so that other groups can edit the permissions. I suspect situations where you need to give a group of people access to change the permissions on files is far and few between.
They released a service pack with a soft firewall. That "breaks things" if they happen to require total network access. They're not afraid to break things for security.
You do realise that Linux has had a built-in firewall long before Microsoft introduced theirs.
Part of that service pack also gives users a nag screen every time they boot up if they don't have virus protection.
Which Windows really needs because of the large number of viruses that can infect the Windows platform:)
They support the NX bit.
Yep. So does Linux. Your point?
They are buying Anti-Spyware and AntiVirus firms right and left.
Because Windows is such an easy platform to infect with spyware, especially if you're using IE.
It's like IE. MS said they'd have the best browser, and IE was a joke for a while.
We've come full circle; IE's a joke again.
I'd even venture to say that if Free OS's had the same installed base, the same virus-target-area, as MS today, a new WinXP (SP2) system would be more secure than a new RedHat system. Why? Because if Linux had the same base as MS, it would have the same number of viruses, and RH doesn't come with virus software, and Windows (when you buy from most OEM's) does.
So, let me get this straight; if virus writers started targeting Linux more, RH wouldn't bundle in anti-virus software. Might I enquire as to why you think they wouldn't?
I would have given Python a bit of Lisp influence, myself, what with the lambda forms, and typical functioncal programming functions such as map and filter.
"Internet privacy" still feels like an oxymoron, and technology like quantum computers may soon crack encryption like SSL, so I'm doubting we can stay private for very long. (Please correct me if SSL/other forms of "https" can never be cracked.)
As I understand it, SSL is an encryption wrapper that can use any number of assymetrical (AKA public key) cryptographical algorithms. So if there is a problem with algorithm A, then all of the banks and such can switch to B.
Public key cryptography is based on mathematical puzzles that easy to construct but difficult to reverse. For instance, one method used is factoring primes: multiplying the two primes 7 and 19 together is pretty easy (especially for computers); the answer is 133. However, reversing such an operation is a lot harder - can you work out which two primes multiply together to make the number 391?
The RSA algorithm uses the factoring of primes, I believe, although the primes used are very, very big. 128-bit encryption uses primes up to 2^128 (3.4 * 10^34).
All puzzles like this can be classified as NP-complete, which basically means that there is no known algorithm to solve these puzzles in a reasonable amount of time. However, interesting enough, it was proven that were one to find a quick way of breaking just one NP-Complete puzzle, then all NP-Complete puzzles would be broken. In short, if some genius came up with a mathematical solution to solve NP-Complete problems, all public-key crypography would be wide open.
However, no-one has yet found an algorithm to solve NP-Complete problems in reasonable time, despite many attempts. Most mathematicians believe there is no such solution.
That said, we're all human, and sometimes flaws creep in. Sometimes people think their encryption algorithm is NP-Complete, when actually it is subtly not so. Fortunately, SSL can switch encryption schemes.
Quantum computers aren't as much a problem as you might think. Whilst a quantum computer of significant size could break any public-key encryption, building such a quantum computer is currently out of our reach. It's unlikely quantum computers will threaten encryption soon.
However, even if powerful quantum computers are just around the corner, we've already perfected quantum encryption, and quantum encryption is theoretically utterly impossible to break,
Quantum encryption works thus: you send to your friend a number of polarised photons across a special fiber-optic link. Due to the Heisenburg Uncertainty Principle, it is absolutely impossible to observe the stream without corrupting the message; thus, if the CIA were to intercept the stream, your friend would know about it.
So what you do is you first get some sort of radioactive source to generate a set of true random numbers for you, This is your one-time pad. You send this to your friend, and you can be sure if he got it unobserved. Once he has the pad, you and he can exchange messages in perfect security.
Dude, even if you go from 0 miles/hour to the speed of light you're still accelerating
Unless the particle was created with an initial speed of greater than the speed of light. The relativity equations are mirrored, in that a particle travelling slower than light cannot accelerate past C, and a particle travelling faster than light cannot decelerate past C.
These faster-than-light particles are called tachyons, and though they are theoretically possible, no-one has ever detected them. Apparently, they'd be fairly easy to detect as well; since Tachyons travel backwards in time, one would have to look for an "effect-and-cause", rather than a "cause-and-effect", or so I've been told.
I've NEVER used Calculus outside of college. It's all academic mumbo-jumbo. Quit acting all high-and-mighty about it. I have far more respect for plumbers than mathematicians.
You do realise that the engineers that designed the circuits in that computer you're using, could not have done their job without that "academic mumbo-jumbo" that is calculus.
And, of course, computers, or indeed any electrical technology more advanced than a lightbulb, could not have been designed without mathematics and mathematicians.
However, I do realise you're an ignorant troll, so I doubt my words will have much effect.
Slashdot Mirror
It may be that electrons and quarks are made up of smaller particles. However, there is thought to be a limit to how small a particle can be, called the Planck Length, which is 1.6160e-35m. I don't pretend to fully understand the reasons behind this, but essentially under our current theories, that's the smallest length that makes any sense.
There's also some evidence to suppose that the Universe may be more discrete than continuous. We know energy is divided into packets of energy, called quanta, rather than a continuous flow. Because energy does not appear to be able to be subdivided beyond a certain point, it makes sense that matter would adhere to the same principles.
Since the Universe we live in is finite in size and mass, and that all calcuations for size in our theories are multiples of the Planck length, one might suppose there is also a lower limit.
There's also an upper limit for density, of course. A particle that is too dense would collapse into a black hole. So a particle with a certain mass can only get so small.
However, that might be all wrong; there's no current way to tell.
I mean why does light behave differently when its made up of the same 'matter' (i.e electron/proton) as you and me? Why will it travel at the same speed no matter whats the speed of the observer is?
Photons, the particles that make up light, have zero mass. According to relativity, any particle with zero mass travels at the speed of light when in a vacuum.
We, on the other hand, do have mass, which prevents us from travelling faster than light, and the reason for this lies in E = mc^2.
This equation essentially says two things. One, that mass can be converted into energy, such as in a nuclear bomb. Two, that if you give a particle energy (ie. accelerate it), its mass increases (or rather, multiplies by what's known as the Lorentz factor. Hence the reason why particles of zero mass aren't subject to this; any number multiplied by zero is still zero).
So as you accelerate, you gain mass, although this is only really noticable at velocities approaching the speed of light. The nearer to light you get, the more mass you have, and the more energy you need to accelerate further. To accelerate a particle with mass to the speed of light would require an infinite amount of energy.
In other words, the only reasons photons travel at the speed of light is only because they're massless. We cannot because we have mass. But why this strange cosmic speed limit exists in the first place is, as far as I know, unknown.
Time dilation on the other hand...if you wave your arms around, your hands age a tiny bit slower than your torso...does that make sense?
Unfortunately when you start to get into General Relativity and Quantum Theory, things start making a lot less 'sense' than we are used to. Our experiences of the Universe are just experiences gained from a very small part of it, and the Universe doesn't always behave the way we would expect it.
For instance, if you were travelling 55mph, and following a car doing 60mph, you'd expect to see that car moving away from you at 5mph. That's commmon sense.
But common sense doesn't always work. If you were travelling at 95% of the speed of light, following a light ray travelling at 100% of the speed of light, you'd expect it to see it moving away from you at 5% of the speed of light. Actually, the light ray moves away from you at 100% of the speed of light. No matter how fast you go, the light ray will alway move away from you at the same speed.
This is strange behavour, but it's been proved again and again. When people first discovered this, the experiments were run again and again, but the results always turned out the same. And from this result, Einstein pointed out that time dilation was a logical consequence. If the speed of light is constant, then time dilation must be taking place.
Realise that our ideas about what makes 'sense' are derived from the world around us. In the realm of the very large, or the very small, things are very different. For instance, we know that in space things don't slow down, because there's no air resistance or friction. This seems obvious to us now, but in the past it was 'common sense' that in order to keep something moving, you had to keep pushing it.
Look at it another way, then. Imagine you're in a transparent glass train carriage, idly bouncing a tennis ball upon the floor. From your perspective, the tennis ball just goes up and down.
Now imagine an observer standing on a train platform. He sees you as you zip past in your expensive transparent train carriage, and observes the way your tennis ball moves. To the observer, the tennis ball appears to follow a parabola, because from the time the ball hits the floor to the time the ball gets back to your hand, your train carriage has moved on.
Now think about the distances involved. From your perspective, the tennis ball has just travelled up and down. If you're bouncing it from a metre's height, then the total distance of one 'bounce' is two metres; from your hand to the floor and back again.
Assume the train travels 10m in the time it takes you to bounce the ball once. Then to the observer upon the platform, the ball has travelled 2m in the vertical direction, and 10m in the horizontal direction. Whilst you might insist the ball has only travelled 2m vertically, the observer will insist the ball traveled much further, because the train was moving at the time.
Light is always a constant speed. This differs from the way we're used to the world working. If a car is doing 60mph, and you're chasing it doing 50mph, then the car you're chasing will appear to move away from you at 10mph.
Light is different. Light travels at c, which is 299'792'458 m/s. If you were in a spaceship chasing after a light-ray, and your speedometer says you're doing 90% of c, then you might expect the light ray to move away from you at 10% of c. But this isn't what happens. Light is always a constant speed, so the light ray moves away from you at c. No matter how fast you go, you'll never seem to gain upon the light ray.
Lets go back to our balls on the train. Instead of a ball, imagine a light ray bouncing between two mirrors. To a person on the train, the light ray appears to be travelling vertically, whilst to a observer at the station, the motion of the (very fast) train makes the light beam appear to bounce diagonally. This diagonal distance the observer sees is longer than the straight-up vertical distance you see, so to the observer, the light ray takes longer to bounce between the two mirrors. In other words, for the observer, time inside the train appears to move more slowly.
You seem to be a very skeptical person, or perhaps you have not looked very far, In 1971, experiments were carried out using four caesium beam atomic clocks (The Hafele-Keating Experiment). Two of the atomic clocks were put on commercial jets and flown in opposite directions around the world. The predicted time dilation matched up to the difference in the atomic clocks.
I find it rather unlikely that this is a coincidence. What are the chances that two pairs of atomic clocks would fail, and fail by exactly the same amount as theory predicts. Pretty slim.
Of course, this was an experiment done on the macroscopic scale. In particle accelerators, time dilation directly affects the half-life of particles such a muons. Thousands of experiments have confirmed that the half-life of particles is affected by velocity in the exact way that Einstein predicted. Again, this is very hard to chalk down to coincidence.
Furthermore, experiments with the speed of light show that the speed of light is constant. Albert Michelson and Edward Morley tested the speed of light parallel to the Earth's velocity, and perpendicular to it; there was no difference in the results. From this we can conclude that either the experiment, and all the hundreds similar experiments performed after, were fundamentally flawed in precisely the same way (a stretch of the imagination). That the earth does not move around the sun. Or that the speed of light is independant of one's velocity. Indirectly, if these experiements are correct, this proves time dilation.
How? Consider a man on a spaceship travelling at high speeds. Upon the floor of his spaceship is a laser, a light sensor, both connected to a very accurate stopwatch. Upon the ceiling is a mirror. When the man presses a button, the laser beam is fired up at the mirror, and the stopwatch starts timing. The laser beam will bounce off the mirror, hit the light sensor, and the stopwatch will stop. Thus, the man will now know the time it takes for a laser beam to cover the distance between the laser beam, the mirror, and the light sensor.
With me so far? The problem comes when an observer upon the earth watches the spaceship zip past. To the man inside, the laser beam heads straight up and down, taking a purely vertical path. To the observer on earth, the spaceship moves horizontally whilst the experiment takes place, so to the observer, the laser-beam takes a longer, diagonal path. Because light is a constant speed, to the observer, the light beam travels at the same speed for both the observer and the man in the spacecraft. However, for the observer, the light beam travels a further distance than for the man in the spaceship, and therefore takes a longer time. So to the observer, the whole event takes a longer time than it does for the man inside the spaceship. That's time dilation.
In case you're interested in looking at the source, main.py is the best place to start to figure out what things do. Some interesting things to do are:
Replace:With:Or:Or:To remove the random elements from the tree, comment out:And then change branch_number(), angle(), length() and make_polygon() to:That should make it easier to see what the code is doing, without the many randomising gaussian functions getting in the way. The above functions are used to control the tree's formation.
branch_number() defines the number of branches at any one depth (ie. the number of generations away from the root). In the above case, branch_number() will give each branch three children up to the fouth generation.
angle() defines the angle that a branch differs from its root. In this case the yaw is always 30 degrees, and the branches are spread equally throughout the roll.
length() defines the length of the branches based upon their depth and their life (number of generations until a branch tip).
make_polygon() defines the encompassing rings that flesh out the tree. The number of edges and the radius of the ring decreses as the branch thins out to a tip (where life = 0).
Um, like this?I can't see what readability a single brace adds to a program.
It's true that I tend to use very little comments in Python, but that's because doc-strings are often enough. I tend to be of the school of thought that favours splitting a program into many small functions that do one thing and one thing only.
Clutter I define as elements of a program that don't add much information to your code. Semicolons are often clutter; you only truly need them in the very rare instances where you might want to put more than one instruction upon one line. Braces are clutter, at least to me, because whitespacing does the job much better. I suspect I'd have no objection to languages like ADA in theory, but I suspect I'd soon grow weary of typing out end block delimiters
I've also never had a problem with knowing where Python blocks end, either. But then again, I've never had a situation where I've had a blocks that are 100 lines long (except with classes, but it's pretty simple to see where they end
How about encryption and security, SOAP, ORB, web services, directory services, messaging services? You know, all those things that distinguish large enterprise applications from normal business applications.
I do suppose if your definition of a good enterprise language is one with all such libraries included, then Python isn't a very good enterprise language. Of course, one could argue that the benefits of Python outweigh the disadvantages at having to download extra packages to handle SOAP, ORB etc.
The difference between Java and Python is similar to the difference between C# and Visual Basic.
I'm a little confused. Are you saying that Python is inferior to Java because Java comes with library X included, whilst with Python library X has to be downloaded separately?
Python is slower than Java and higher level than Java, but beyond that I can't say that there's too much separating Java and Python as languages. Personally, I find programming in Python more efficient, despite having more years experience with Java, but that may be just me.
I used to use Perl extensively. Now I hardly ever do, except in the case of a shell-script substitute. I find that Python programs tend to be easy to read. They feel less hacky.
However, I think you're correct about sort(), and int() does indeed fail with strings representing floating points. But I've never found the practice of exception throwing in Python at all objectionable, and I've never had an experience where I've had to use 'try' too much.
The lack of auto-initialisation is of debatable worth. I've always used 'use strict' under Perl; initialising one's variables is preferable to plucking them out of the ether - at least in most circumstances.
As for the slowness of Python, I've never come across a situation where it would be noticable. Unless you're trying to design a cutting edge 3D game engine totally in Python, I should think Python's speed wouldn't be a problem.
Truncate. But it shouldn't matter except for very large values of N, because it's just to remove the slight rounding errors one gets when... Come to think of it, it should really round. Otherwise 4.9999999999999999 would come out as 4. Well, slap a 'round' in before the int, and it should all be okay :)
I can't think of many instances when one would have to rewrite a part in C. I do suppose that if you were using Python to develop a 3D game, then you might want to write the engine in C. But I can't think of many other cases when you absolutely need the speed of compiled C.
Assume for a moment that programmers can code more effectively in Python than in Java. Then those companies that use Python over Java will have an advantage. If a company dismisses Python as just 'a cute scripting language', then they might find themselves losing out to their competitors that do use Python.
.NET too. I wouldn't rule out Microsoft just yet.
:)
So I don't think it's inconceivable that Python might replace Java eventually, at least in the more successful companies. It's also early days for
Perhaps I'm a little naive, but I do believe that eventually programming practises will improve. I'm sure they can't get much worse!
I've never had any problems with Python's speed. It's fast enough for web applications. It's fast enough to use GUI toolkits. It's even fast enough for simple OpenGL demos (a shameless plug, I know, but it seemed relevant).
If you come across a situation where Python is too slow for what you want to do, then Python can work happily enough with libraries programmed in C. If that's still not fast enough, then use a different language. But I suspect that for 95% of all programming tasks, Python is fast enough.
However, revelations about their handling of pre-war Iraq journalism has tainted them. Out of curiousity, what do you mean by this?
Actually, I believe that JScript, which IE uses, is a superset of ECMAscript (AKA 'standard' javascript). In other words, IE uses Javascript with extras.
I'm not too sure where Firefox lacks in Javascript support; so far as I know it does have 100% compatibility. However the only problems I have ever had with javascript and Firefox is when the javascript is coded incorrectly. IE is more tolerant of broken code than Firefox is.
For instance, the UK Job Centre's job-search webpage uses javascript that works in IE but not in Firefox. The root of the problem in this case is bad coding. In Firefox, the function getElementById it does exactly what it says and no more; it returns an element object dependant on the id attribute. In IE, getElementById gets elements by their id or by their name. Presumably this is to help compensate for shoddy developers mistakes, yet it has the added disadvantage of producing invalid javascript.
I'm curious to know; what sites that use javascript have you found that don't work in Firefox? If I were a betting man, I'd be willing to wager that all the problems you find are down to shoddy javascript errors that IE glosses over. In other words, the problem lies with the website developer.
Apparently this is not a black hole, merely an object that exhibits some black-hole like properties. However, so far as I know, the formation of a black hole depends only on the volume to mass ratio being small enough. I assume that as one pushes matter together, even on the subatomic scale, there comes at point where the gravitational force will become dominant. Certainly this Black Hold FAQ answer seems to indicate that subatomic black holes are theoretically possible.
:)
You are also correct to assume that Hawking Radiation does not happen in a true vacuum, i.e. a piece of space devoid of mass and energy. However, quantum physics suggests that there is no such thing as a true vacuum; on the subatomic scale, the fabric of space froths. Particle/anti-particle pairs are created from nothing. These virtual particles zip apart, then are pulled back together again and annihilate themselves. The total mass/energy gained through these interactions always remains at zero.
However, in my rough, layman's grasp of Hawking Radiation, this changes near the event horizon of a black hole. If one of a virtual particle pair crosses the event horizon, and the other does not, then a curious thing happens (at this point, my understanding of the process breaks down quite a bit). As far as I know, the virtual particles are created in a sort of quantum flux; because they haven't been observed, the particles have not 'decided' which of them is to be the anti-particle, and which is to be made of normal matter. The act of falling into a Black Hole makes a virtual particle into an anti-particle, and thus, the virtual particle outside the black hole becomes a piece of normal matter.
The overall effect is that a black hole gives off radiation, and shrinks due to small particles of antimatter passing through the event horizon.
Note that IANAP, and thus I am probably mostly wrong
I have to disagree. The lack is not in code or tools to produce code... The lack is in content
I agree. From my experiences, programming on Linux is generally easier and less expensive than Windows. Almost all Linux distributions come with a whole host of development tools (kdevelop, gcc, etc), and Linux has a lot of libraries already included (libpng, zlib, etc).
Next on the list is NetHack. NetHack is a terminal-based game (not that I think that this inhibits gameplay, as I just finished a four-hour stint playing Tales of Middle Earth), with extremely simplistic tile-based graphics. There have been a few attempts to improve things -- Falcon's Eye is a notable NetHack fork, with music and alpha-blended graphics -- but still nowhere near modern commercial-quality graphics. Now, as the NetHack aficionados among you know, NetHack can be a lot of fun, and while long-term replayability depends more on game logic than graphics, anyone who thinks that graphics and sound don't play a key role in making a game enjoyable is simply not being honest with themselves (and I would suggest that they try watching a horror movie with the sound off).
Whilst I like eye-candy, I actually prefer text-mode Nethack over graphical Nethack interfaces like Falcon's Eye. Text-mode is a lot easier to play; the entire dungeon is on one screen (unlike Falcon's Eye), so you can't get lost. And once you get to know the symbols, it's a lot easier to tell a 'c' from an 'D' or an 'O' than it is with a small sprite (like in Qt-hack).
Or a Telnet interface with a password of "private" (DLink ADSL routers as of 2002)
:)
It is my understanding that the telnet port isn't accessable outside the local network for D-Link routers. However, if you have evidence to the contrary, I'd really like to know
They already have a more fine-grained file permissions model than Linux.
:)
If I recall, the only practical difference between the Linux and Windows permissions systems is that in Linux, only the owner of a file and the root may change the permissions. In Windows, one may set it up so that other groups can edit the permissions. I suspect situations where you need to give a group of people access to change the permissions on files is far and few between.
They released a service pack with a soft firewall. That "breaks things" if they happen to require total network access. They're not afraid to break things for security.
You do realise that Linux has had a built-in firewall long before Microsoft introduced theirs.
Part of that service pack also gives users a nag screen every time they boot up if they don't have virus protection.
Which Windows really needs because of the large number of viruses that can infect the Windows platform
They support the NX bit.
Yep. So does Linux. Your point?
They are buying Anti-Spyware and AntiVirus firms right and left.
Because Windows is such an easy platform to infect with spyware, especially if you're using IE.
It's like IE. MS said they'd have the best browser, and IE was a joke for a while.
We've come full circle; IE's a joke again.
I'd even venture to say that if Free OS's had the same installed base, the same virus-target-area, as MS today, a new WinXP (SP2) system would be more secure than a new RedHat system. Why? Because if Linux had the same base as MS, it would have the same number of viruses, and RH doesn't come with virus software, and Windows (when you buy from most OEM's) does.
So, let me get this straight; if virus writers started targeting Linux more, RH wouldn't bundle in anti-virus software. Might I enquire as to why you think they wouldn't?
I would have given Python a bit of Lisp influence, myself, what with the lambda forms, and typical functioncal programming functions such as map and filter.
"Internet privacy" still feels like an oxymoron, and technology like quantum computers may soon crack encryption like SSL, so I'm doubting we can stay private for very long. (Please correct me if SSL/other forms of "https" can never be cracked.)
As I understand it, SSL is an encryption wrapper that can use any number of assymetrical (AKA public key) cryptographical algorithms. So if there is a problem with algorithm A, then all of the banks and such can switch to B.
Public key cryptography is based on mathematical puzzles that easy to construct but difficult to reverse. For instance, one method used is factoring primes: multiplying the two primes 7 and 19 together is pretty easy (especially for computers); the answer is 133. However, reversing such an operation is a lot harder - can you work out which two primes multiply together to make the number 391?
The RSA algorithm uses the factoring of primes, I believe, although the primes used are very, very big. 128-bit encryption uses primes up to 2^128 (3.4 * 10^34).
All puzzles like this can be classified as NP-complete, which basically means that there is no known algorithm to solve these puzzles in a reasonable amount of time. However, interesting enough, it was proven that were one to find a quick way of breaking just one NP-Complete puzzle, then all NP-Complete puzzles would be broken. In short, if some genius came up with a mathematical solution to solve NP-Complete problems, all public-key crypography would be wide open.
However, no-one has yet found an algorithm to solve NP-Complete problems in reasonable time, despite many attempts. Most mathematicians believe there is no such solution.
That said, we're all human, and sometimes flaws creep in. Sometimes people think their encryption algorithm is NP-Complete, when actually it is subtly not so. Fortunately, SSL can switch encryption schemes.
Quantum computers aren't as much a problem as you might think. Whilst a quantum computer of significant size could break any public-key encryption, building such a quantum computer is currently out of our reach. It's unlikely quantum computers will threaten encryption soon.
However, even if powerful quantum computers are just around the corner, we've already perfected quantum encryption, and quantum encryption is theoretically utterly impossible to break,
Quantum encryption works thus: you send to your friend a number of polarised photons across a special fiber-optic link. Due to the Heisenburg Uncertainty Principle, it is absolutely impossible to observe the stream without corrupting the message; thus, if the CIA were to intercept the stream, your friend would know about it.
So what you do is you first get some sort of radioactive source to generate a set of true random numbers for you, This is your one-time pad. You send this to your friend, and you can be sure if he got it unobserved. Once he has the pad, you and he can exchange messages in perfect security.
Dude, even if you go from 0 miles/hour to the speed of light you're still accelerating
Unless the particle was created with an initial speed of greater than the speed of light. The relativity equations are mirrored, in that a particle travelling slower than light cannot accelerate past C, and a particle travelling faster than light cannot decelerate past C.
These faster-than-light particles are called tachyons, and though they are theoretically possible, no-one has ever detected them. Apparently, they'd be fairly easy to detect as well; since Tachyons travel backwards in time, one would have to look for an "effect-and-cause", rather than a "cause-and-effect", or so I've been told.
I've NEVER used Calculus outside of college. It's all academic mumbo-jumbo. Quit acting all high-and-mighty about it. I have far more respect for plumbers than mathematicians.
You do realise that the engineers that designed the circuits in that computer you're using, could not have done their job without that "academic mumbo-jumbo" that is calculus.
And, of course, computers, or indeed any electrical technology more advanced than a lightbulb, could not have been designed without mathematics and mathematicians.
However, I do realise you're an ignorant troll, so I doubt my words will have much effect.