So, by looking at the graph, since z is approx 1 when v=c, you would observe light at half its original frequency. And the largest recession speed observable could be anything between 2c and 4c.
Thanks. But now I'm puzzled why the answer to the second question depends on things that intuitively seem irrelevant, and why it isn't an exact number. (After all, speed c isn't dependent on anything, and the metric expansion of the universe is just about changing geometry. Why would any of this depend eg. on the age of the universe?)
Basically the big concern for those that don't wanna read the article is that a company that is making new electronic polling booths for several states (including Ohio) is being directly funded by Mitt Romney and his family. To me this seems to be a MAJOR conflict of interest. Can we trust these to not be rigged? Will they be truly 100% fair? Or is this an attempt to compromise the integrity of the election? It's hard to say, but regardless of party, if this is the case, it should be investigated.
I think that's going to the conspiracy theory realm.
Politicians are often stupid, but not that stupid. Imagine if Romney were to really pull the strings to have the booths rigged, and it was later discovered. Nixon's Watergate scandal would be nothing compared to that. It would not only be a political suicide, it would be the end of his life. I don't think even Romney would be that stupid (no matter what you think of him.)
If the two objects are receding from each other faster than the speed of light, they cannot send light to each other.
That's not what I have understood, and it's precisely a big source of confusion and misunderstanding.
To understand why one object can send light to the other even though the latter is receding (slightly) faster then c, consider the classical "snail on a stretching rubber band" analogy:
Imagine that there's a hypothetical, infinitely stretchable rubber band, initially 1 m in length. A snail on one end starts moving towards the other end at 1 m/h. However, the rubber band is stretched at 1.1 m/h. Will the snail ever reach the other end?
Perhaps a bit surprisingly, the answer is yes. Did the snail at any point have a local speed larger than 1 m/h? No. Yet it still reaches the other end.
And perhaps a bit more surprisingly, light in an expanding universe behaves like the hypothetical snail on the hypothetical stretching rubber band. As the universe expands, it "drags" light with it, in the same way as the rubber band drags the snail. At no point is the local speed of the light different from 1c, but it still reaches its destination.
This means that if the universe were expanding at such a rate that two planets are receding from each other at eg. 1.1c, it means that one planet can send light to the other (and the light will eventually reach it.)
General Relativity and the metric expansion of the universe has two very unintuitive consequences:
1) Even though the maximum speed at which anything can move is c, it's still possible for two objects to recede from each other faster than c. 99% of people (a small percentage of which are scientists themselves) immediately reject this notion, even though it's a direct prediction of GR.
2) Even more unintuitively, and even if you accept the above, if two objects are receding from each other faster than c (due to an expanding universe), light can still travel from one object to the other, even though at no point does it travel (locally) faster than c. (This is easiest understood by using the snail-on-a-stretching-rubberband analogy.)
I have two questions about this:
1) If two objects are receding from each other slightly faster than c (due to the metric expansion of space) and the first object sends light to the other, what's the color of the light when it arrives? (I'm thinking about redshift here.)
2) I think there's a cutoff point for how fast the two objects can recede from each other before light can reach one from the other. In other words, if the two objects recede faster than a certain speed, light will never be able to travel between them. What is this speed?
Speaking of that...
Ok, Pitfall is possibly one of the best-known Atari2600 games ever (if we ignore ET and Pacman). However, is it a good game for TASing? IIRC the only thing you do is run to the right and sometimes jump. That's it. Nothing more.
If it gets published, it will be solely because it's a famous game.
Then I want to vote Obama, but he will stick to his Health care plan, so it's complicated.
Yeah, dammit if poor people get free (or even inexpensive) healthcare. It will be destruction of society! Just look at how Europe is in ruins because of the free healthcare system there! Poor and sick people must be kept poor and sick. Clearly this evil must be eradicated at its roots.
OTOH, otherwise Obama doesn't seem to be a good candidate, looking at what he actually accomplished during the past four years. (In some aspects he made matters worse than even Bush did... which is no small feat.) However, none of the other candidates are any better either. In fact, they are all worse. At least Obama isn't trying to create a totalitarian theocracy, like 90% of the other candidates.
(Although, thinking about it a bit more positively, probably 90% of what those politicians are promising is pure BS anyways. They are just pandering to the average voter and saying what they want to hear. With luck they will promise a theocracy but not actually deliver if they actually get elected. Ironically, in this case politicians not delivering what they promise would be a good thing.)
This was a time in video game history when game publishers thought that:
a) if it has something on screen that can be moved by pressing buttons, it will sell, and
b) if it has the same name as a hugely popular movie, it will sell.
A cynic could say that nothing has changed in the past 30 years.
I think that the question of whether to vote yes or no on this is difficult.
Are we comparing TASes of Atari2600 games to all other TASes, or are we comparing them to what Atari2600 has to offer? Do Atari2600 games get any better than this? If this game represents the average Atari2600 game (rather than being one of the worst ever made for it), I think it should be placed on that context, or else we won't publish any Atari2600 TASes at all.
Of course I know/have seen approximately 0 games for the Atari2600 (I think I once saw a playthrough of Pitfall, but that's all). Therefore I cannot judge if this is an average game for that system (and thus should be judged as such) or if it really is one of the worst games made for it.
Hard to vote without having such knowledge.
I think that's a bit too harsh of a measure, unless it has become clear that he's doing this on purpose to spam/vandalize the site or annoy people. It's possible he just doesn't understand the idea of the website.
While this is true when comparing 10-random-character passwords with half sentences, ElectroSpecter mentioned that his random-ASCII-character-password was max length. And when looking at identical length, the random password is preferable, as it is (or at least should be) immune to dictionary attacks.
The point is that when you have to remember your password (you can't use password manager software everywhere and in every situation), a password consisting of random English words is much easier to remember and more secure than a password consisting of random characters (which is short enough for a normal person to remember.)
Only stupid forum software keep password in a decryptable way. Most of them hash the passwords, so they are undecryptable (or at least they should; if they do not, then avoid that software).
While storing passwords as one-way hashes is certainly vastly more secure than storing them as plaintext or any format that's unencryptable, one should never consider it 100% safe (especially in environments where hundreds or thousands of passwords are stored, such as online websites.) Things like rainbow attacks (yeah, they are really called that) have been used successfully again and again to decrypt some/many passwords of such websites. (There are measures to make rainbow attacks much more difficult, if not almost impossible, but many websites do not use them.)
Of course a common form of "hacking" a password, which bypasses all forms of encryption, is social engineering. Countless people enter their login info and passwords to random places just because they are naive enough to believe a random email or scam website. (Some forms of social engineering are much more elaborate than that, especially if the hackers are resourceful and have a great interest in retrieving a particular password. These may involve things like physical phone calls and so on.)
Sometimes websites get hacked, and it may look to you like the regular old website, and you log in as normal, but in reality your login info and password is being passed to the hackers. There's little one can do to avoid this, as everything happens silently on the server side.
ElectroSpecter wrote:
I had one randomly generated: max length, and a mixture of lowercase and capital letters, numbers, and symbols.
Curiously, using normal English (or whichever spoken language) words in a password may be more secure than using random symbols, no matter how egregiously unintuitive that might sound. There was a strip at xkcd about this.
It's simple math, really. For example, let's assume that you use a 10-character password, using random alphanumeric characters, and random punctuation from the ASCII character set (let's say for a total of about 80 possible characters). There are about 1019 possible passwords.
In contrast, assume you make a password consisting of just 6 random English words. While English has a really vast dictionary, let's be really conservative and say that you are drawing from a pool of about 100 thousand words. The total amount of possible passwords is 1030. A vastly larger amount.
So, you see, using just 6 random English words results in a significantly more secure password than using 10 random ASCII characters. The advantage of using English is that it's far easier to remember.
Yet all security advisors out there recommend against using cleartext passwords.
Here's what can happen (and did to me). You signup for some site. You used the same password there as you do on other sites. The site's owner sells your password, along with everyone else's and hackers go crazy. The worst possible case is clear text passwords. Absolute failure of security.
Do you usually write your Xbox Live account name and password to random websites?
henke37 wrote:
How hard can it be to smash your keyboard and produce about twenty characters of noise? Just write the password down in a password manager application.
So you want your password to be retrievable in cleartext from your computer? (Also, a bit difficult to log into Xbox Live with your console using a password manager application...)
Some days ago I my xbox started spouting the "(my gamertag) was last signed in on another console". I searched the net for info on what that means, and reset my password. However, it was too late. I later noticed that 1000 MS points had been used from my account (I had 1040 in total) to make some purchases. Microsoft's technical support was quite helpful and competent handling the situation, and they investigated the incident and returned my lost points. (This was, I admit, a slight surprise, given all my prejudice against Microsoft.)
I do not know how they hacked my account, as Microsoft's report did not reveal any such information. I consider myself quite an experienced and savvy computer user, having been using Unix and Windows systems since the early 90's, and I know not to fall for eg. social engineering; not that I have had any attempt at such a thing done to me either. Yet it still happened. (Reading on the subject on the internet, it seems that at least some hackers hack Xbox Live accounts to make purchases and transfer them to some other account, which is possible at least with some purchases, and then they sell that account, which is full of games, for good money. Others might do it just for pure vandalism and egotripping.)
So it can happen. Here's some advice:
- If you ever get an unexpected "(your gamertag) was last signed in on another console" message on your xbox 360, take it seriously. It means what it says: Somebody else has logged into your xbox live account from another console. That should never happen (unless you yourself did indeed do that.)
- If that happens, go to www.xbox.com/security and reset your password. Remember to click the option "require a password to sign in from all consoles" (else the hacker will be able to keep signing into your account because they have most probably set the "remember password on this console" option.)
- Check at the xbox live website for your purchase history to see if anything has been purchased with your account that shouldn't be. If there is, contact Microsoft's technical support. At least in my case they were very helpful. Also check if anything has been changed in your account, such as your gamertag, friends list, etc. (You might want to contact Microsoft technical support even if nothing has changed, just in case.)
While I must admit I didn't quite fully understand the subtleties of the problem, I'd say that:
1) Using a game-breaking glitch should always happen to achieve the main goal of the TAS. For example, if the main goal is to simply reach the end of the game as fast as possible, then the glitch should be used in a manner that absolutely minimizes this time. Making a slower run that still uses that glitch for something else, is obviously suboptimal, as it does not fulfill this specific goal in the best possible manner.
The main goal doesn't always have to be fastest possible completion. Another typical goal is 100% completion (eg. finding all items in the game, if it keeps count of them), with the fastest completion being a secondary goal (iow. find all the items and then reach the end of the game, all this as fast as possible). In that case using the game-breaking glitch is ok if it's used to achieve the 100% completion as fast as possible.
2) Now, some TAS might use some (sensible) self-imposed limitation. A typical limitation is "does not use game-breaking glitches" (with the intention to show more of the game). This is a sensible limitation if it's unambiguous and results in a significantly different game that has high entertainment value on its own.
But what happens if the game-breaking glitch mentioned in the first point above conflicts in some manner with some imposed limitation (or makes the limitation pretty moot)? A hypothetical situation I can think of would be that the self-imposed limitation is "does not use death as a shortcut" (this limitation being imposed in order to show more of the game), but there's a game-breaking glitch that allows skipping the vast majority of the game without dying.
Does the implied goal of "showing more of the game" give a free pass to arbitrarily use the game-breaking glitch here and there, as long as it doesn't skip too much of the game?
My opinion is that it doesn't. It becomes a completely arbitrary rule, and basically sloppy play (because the usage of the glitch is suboptimal).
In my opinion: Either you use a certain glitch to its full extent to achieve the primary goal, or you don't use it at all. No secondary goals or self-imposed limitations should allow starting to use the glitch arbitrarily at a whim and without a well-defined goal or pattern.
And there's the change (certainty) that someone (or several someones) will be upset at any (many) particular judgement(s) and complain (loudly in every thread they can.)
You could say that from almost anything that involves someone making a decision. (Most prominently, perhaps, whether a TAS should be accepted for publication or not.)
If someone gets upset, it's their problem. Nobody forces them to visit this website. And if they get troublesome, they can be warned and banned.
Just because there's an innovation award doesn't mean that it must be awarded each year, no matter what. If some year there are no feasible candidates then it can simply be not awarded that year. However, I think it should still exist to be given to those who do something special or unique, alongside the other awards.
Just take nominations (with arguments why it's innovative). Even if there's just one nomination that deserves the award, give it to that one.
Now, remember how many molecules we're dealing with here. For example, a mol of iron typically weighs about 56g, and that's 6.02 * 10^23 atoms. A 1-mol sphere of iron would have a radius of a bit over 1cm (thus diameter about 2cm, or roughly the size of a golfball, for a neat bit of symmetry). Passing through a 2cm-block of iron requires passing a stupendous number of 1-in-6-billion chances. Eventually the odds will get you.
I don't think it works like that. You are talking like the entire mol of iron is in the path of the neutron. It isn't. Only a very small percentage of the atoms are anywhere near its path.
Sufficiently small objects can penetrate through matter more or less freely, though. Neutrinos pass through the entire Earth all the time because they interact so weakly with normal matter.
Why do neutrinos pass easily through any amount of matter (with extremely little chance of being stopped), but neutrons can only pass through a rather moderate amount of matter before being stopped?
Neutrons are electromagnetically neutral, so electromagnetic forces don't stop them. And why would they ever collide with an atomic nucleus, considering how vanishingly small they are compared to the space between nucleii? (I don't remember now the exact figures, but I have a faint memory that if atomic nucleii were the size of a golf ball, they would be separated in a typical molecule by at least the length of a football field, or even more.)
1) If I had a knife and somehow sharpened it to an atomic edge, would I be able to actually see the edge of the knife or would it become transparent?
I have no idea, but I know that it's not possible to "see" individual atoms, and this has something to do with the fact that atoms are smaller than the wavelength of visible light.
I don't know what happens if you have an entire layer of individual atoms. Would light pass through? (Btw, such a layer is called a monolayer. The article might have more info on that subject.)
3) If the knife was unbreakable and I dropped it blade down (and there was no handle, to make my question less complicated), would it just keep cutting through the earth until it melted?
A physically impossible object meeting a physical object... I don't know if there is an answer.
Learning assembly is not meant to program in it, IMHO. As Warp suggested, compilers do a much better job at code optimisation than people. It is meant to understand why the computer behaves like it does when there's a problem in your code. Only learn a few basic operands, the different addressing modes and registers, how higher level languages call functions and how the the call stack works and that's enough.
Ok, let's try it like this:
Assume that someone is learning, let's say, C# as their first language. Please give me a concrete example of how learning asm would help understanding C# in any way?
(Note that C# is actually quite abstract. It's not compiled directly to machine code. Instead, it's compiled to a byte code format which gets interpreted by a virtual machine. This virtual machine usually JIT-compiles this byte code to machine code on the fly for increased efficiency. However, there are so many steps and so many layers of abstraction between the C# source you write and what ends up being run by the CPU, that it basically has nothing to do with asm. In fact, it's perfectly possible to purely interpret C# bytecode, without even a single thing you wrote being compiled into actual machine code.)
Even so, all these topics are really, really advanced stuff. You most certainly do not need to know them when you are learning to program for the first time. (Suggesting learning asm to a newbie programmer is just inane.)
Moreover, even if after you become fluent at programming you would like to know more in depth about the details, for example about why this data container consumes this amount of RAM and why that data container causes so many CPU cache misses, and why this container causes so much memory fragmentation, you still don't need to know any asm for this. You only need to know how the CPU addresses memory, how the CPU caches work, and how the OS and/or the runtime environment of your program allocates memory.
Even if you were learning C++ (or even C), you still wouldn't need asm for any of that.
Now, if you were for example programming for a PIC controller that has 2 kilobytes of program memory and 128 bytes of RAM, and for which there exists basically no optimizing C compiler (or, more precisely, there exist optimizing C compilers, but they are able to optimize only certain things, but do a very poor job at others), that would be a quite different story. In that case understanding what the compiler is producing becomes a lot more important, especially since you need to do a lot of hand-optimization if you want any speed. (Even then, the PIC asm is quite different from your regular x86 asm...)
(or your program really, really needs all the speed and memory efficiency you can possible squeeze out of it, there's some things compilers just can't do for you)
Something programmed directly in asm being faster than what a compiler can produce is in general a misconception.
My personal hypothesis of where this misconception comes from is from the 80's and the 8-bit computers of that era. Usually you had two choices: BASIC or asm. And no matter what you wrote, if it was written in asm it was usually at least 10 times faster than the equivalent BASIC program. This birthed a very popular concept that anything written in asm is automatically faster than anything written in an abstract, high-level language.
For a long time this was perhaps true even for low-level compiled languages like C, and possibly even FORTRAN (although I wouldn't bet my life on the latter case.) Back in the 70's and 80's C and C++ compilers were not all that good at optimizing. Maybe even in the early 90's.
However, during the 90's and especially in the 2000's compilers have got a lot better at it. Also, hardware has progressed so rapidly that it's very hard for an asm coder to keep up, and to keep beating compilers. (What was an efficient way to implement something in the early 90's might well not be the most efficient way of implementing it today.) Unlike in the early 90's, today processors are extremely complicated and it's very hard to optimize for them manually. Compilers have got pretty competent at optimizing for them.
This doesn't mean there aren't cases where implementing some subroutines in asm wouldn't result in something that's measurably more efficient than anything the compiler can produce. However, these cases are relatively rare. (The disadvantage of doing this is, of course, that it's absolutely not portable.)
I also recommend learning some of 6502, Z80 or ARM assembly. Not to be able to actually write programs with it, but to be able to grasp how the higher level code work under the hood. It makes it much easier to understand data structures (stacks, lists, trees, etc.) when you can see that it references actual memory in a structured way and is not only some abstract drawing that a teacher put on a whiteboard.
I honestly cannot understand how learning asm helps you understand data structures in any way.
Firstly, you don't need to know anything at all about asm or machine code in order to understand how a certain data structure works inside and out (its efficiency, its memory usage, its advantages and disadvantages, where it's good and where it's inappropriate, and even how it's implemented at a low level.)
Secondly, even if you wanted to know how the data structure works on the hardware level (at least if we are talking about low-level languages), you don't need to learn asm for that. You only need to learn a few concepts of how memory works, how it's allocated by the system and what are memory addresses. Zero asm required for this. Even if you wanted to know what's the difference between actual physical RAM and virtual RAM (ie. how the CPU and the OS map virtual memory addresses to actual physical RAM addresses) you still don't need any asm whatsoever. (And while all this can be interesting, it has little value in actually understanding data structures and how they are used.)
The futility of learning asm to understand data structures becomes even more prominent with higher-level languages like Java or Haskell, where references are not raw memory addresses, but are much more abstract than that. The disconnect between asm and these abstract references is quite large. (You can study how these references work at machine code level, but that info doesn't help you understand the data structure itself at all.)
You don't learn how to repair a car by buying a book on chemistry and molecular physics.
EEssentia wrote:
And believe it or not, it's easy to write safe, modern, flexible and powerful C++ code with few to no consequences.
Yes, but getting to the point where you can fluently write simple&safe C++ requires quite a lot of practice and experience. It's not like you can just grab a C++ book and in a week start writing safe C++ like a pro.
Not that there's anything wrong with such a discussion, but the point of this topic was to help a noob such as myself learn how to program at a level where I can become financially independent. Not that my only reason for programming is mercenary (I LOVE coding) but I haz bills to pay.
Programming is not something that can be learned in a couple of weeks or even months (very much unlike people thought in the 80's and, unfortunately, some even today). It takes years. You won't be paying any bills in your near future with programming.
(Ok, of course there are some employers out there who have no idea whatsoever about programming and believe someone is a programmer just because they say so, and might even be one of those who think that programming is something that even a kid can learn in a few days(*), so you never know...)
(*) I think that many people in the 80's and 90's had, and some even today still do, even though probably to a lesser extent, the misconception that programming is something akin to, for example, writing a transcript of a company meeting: Just mechanical writing down of what you want. Something that anybody having the skills to write can learn easily and quickly.
