Schrödinger's hat

Just chiming in to, hopefully, get this discussion back on topic. I've read some of the thread and only skimmed others. I am also probably not as knowledgeable about GR as xyzt is. First note, primarily to Iggy: Aside from any reasoning mistakes you may or may not have made, you appear to be using fairly specific (but not widely used) definitions of a number of terms that become somewhat ambiguous in general relativity. If these terms are used at all, they will often be context dependent and should be defined for the purposes of a discussion if they are to be used at all. Velocity (outside of local velocity) is one such. You are also using terms like simultaneous and proper distance to refer to events relating to events that do not share an obvious inertial reference frame as if we are all on the same page (doing so is going to require further qualification). Thirdly, you appear to be privileging results derived from a specific coordinate system. The words/definitions/results derived are frequently only going to be useful within said coordinate system. These are all things that aren't really appropriate in a response to someone asking a question when they are learning SR/GR. Also presenting natural language interpretations/explanations of mathematical results that differs from the mainstream one is not really appropriate in a thread like this; regardless of whether or not the result is internally consistent with the definitions you've chosen. xyzt: If you encounter someone saying something that is likely to cause confusion or derail the thread, it can be better to suggest they take it up in private messages or another thread with you until you figure out your disagreement, or inform the mods early if this fails. The main thing I can see about Iggy's posts which is disruptive is his unstated assumptions and definitions which are a good reason to ask him to take his discussion elsewhere independently of whether his reasoning is internally consistent.

Your copper wire is insulated so that the electricity travels around many times. This is what causes the strong magnetic field. A tube would allow the electricity to flow in any direction along the surface. Electriciy follows the path of least resistance, so it would make (at most) half a turn (or maybe one). For your second question, that is within the realm of possibility, but it would be a substantial engineering challenge.

Just discovered www.maa.org/devlin/lockhartslament.pdf and thought it worth sharing/possibly stickying.

People are more likely to be able to help you if you add a little more context. Maybe a few sentences around where you encountered it, or the name of the book/chapter/section/article/etc

Imfataal, the reason you're having trouble is: Assuming his radix is an integer. [math]23_x = 2x + 3 = 2(x+1) + 1 = 2n+1 [/math] Is odd. [math]111100010_2[/math] is even. Either his radix is not an integer (rational solution to [math]2x+3 = 482[/math]) or there's a transcription error somewhere.

Fun concept to play with: I find these help the imagination a bit. https://launchpad.net/4dtris/ http://www.urticator.net/maze/ Unfortunately it's quite hard to wrap your head around anything more complicated than simple rectangular type rooms/object. Also what you are viewing is a 2d projection of a 3d projection (or 3d slice) of a 4d scene. There are plenty of animations around youtube in a similar vein. Edit: Also worth noting is that these are euclidean spaces. There are other possible geometries, 4d (flat) spacetime is one (minkowskian rather than euclidean) and is dissimilar enough that you still have to do a fair bit of work to imagine it once you get the 4d euclidean thing. On a more serious note, there are some things which are kinda special to 3d. It's the lowest dimension in which you can have a hollow thing with two openings (in 2d if you try to have a tube through the middle so you can digest, you instead have two objects). Stable orbits don't work very well in other numbers of dimensions (i cannot remember if it's all other dimensions or just all low numbers) so we likely wouldn't have a universe full of swirly stuff.

Also worth noting is that your muscles consume energy both when lifting the object up, and lowering it down again gently.. This is not a necessity. A machine could be built which re-absorbed some or most of the energy it used to lift the object, it's just the way muscles work (resisting motion is close to the same process as moving in the first place). They also consume some energy when exerting a constant force (ie. just holding something heavy). A table (or even electric motor if it has some kind of lock/ratchet/etc) does not have to do this.

Distance squared makes a lot of sense if you stop to think about it. If you have somekind of quantity which is conserved or preserved, and you are spreading it out over a three dimensional volume, and the source is in the middle and it's coming out in a roughly spherical shape, then your quantity will be spread over a spherical area that gets bigger at the same rate a sphere gets bigger. This rate is r^2. I don't think/know whether Newton used this reasoning (unlikely as he came up with some of the maths which was later used to prove this principle and talk about the idea of conserved fields in general), but it's a very simple argument that can be stated and proved with calculus, providing the premise is assumed (spherically symmetric and conservative field). There is some level of ad-hoc reasoning and intuition in any physical theory, but this is perfectly acceptable. As long as the theory is internally consistent (mashing symbols together is fine -- if often unproductive -- as long as you follow the rules. Because following the rules of maths _is_ logical reasoning, even if you have no idea what you're doing). However, the assumptions you are working with are completely up to you. If these assumptions are small in number, differ from existing assumptions minimally, are provably consisting with all known results and -- this is the important bit -- yield novel, specific and preferably precise predictions about things that are presently unknown (often also unexpected) which then prove correct, you have a good physical theory. Both Newtonian mechanics and relativity did this. And understanding the difference between this and just pulling something from your posterior and kneading it until it fits the data is important.

Your computer is made of that same set of elements. If I hit it with a sledgehammer, can you turn it back into a computer? Why not? The thing that's missing in each case is a very precise and hard to achieve arrangement of the components. Nothing to do with what they're made of. Re. Life, chemists are getting better at it. They are approaching creating an artificial cell from both a top down (get an existing cell and hijack it to produce a new cell to your design) and bottom up (starting from scratch). There is a way to go yet, but here is a release about creation of something very similar to a cell membrane (the latter): http://www.sciencedaily.com/releases/2012/01/120125132822.htm And the Craig Venter institute who do the former: http://www.jcvi.org/cms/research/projects/first-self-replicating-synthetic-bacterial-cell/overview/ Note that this is not an entirely new genome. It's more like they got the existing blueprints, cut as much stuff that they didn't need out, added a few bits, and then hijacked someone else's factory to build the thing. Neither of these count as a fully synthetic life form in many people's books, but it is getting pretty close.

An interpreted language at its simplest just runs through the instructions that you give it one by one, in the order that you've written them and executes them. There's usually a 1:1 or 1:many relation between things you write and actual machine code, and the order is preserved. This tends to be quite slow. If your program isn't looking ahead and finding out what bits of data it needs where, you can spend a lot of time waiting on memory or something on the hard drive. One improvement is to look ahead a few instructions and bring stuff into memory or a cache on the CPU, but dynamic languages often don't know what they need ahead of time as the meaning of references can change or arrays can grow etc etc so the benefit of this is limited. It also passes up opportunities to switch out what you wrote for harder to read/understand stuff that is equivalent and faster. A JIT or just in time compiler presents itself as a simple interpreter, but actually does some compilation on your program before running it. Often this is to another interpreted, but easy for the machine to read (and hard for a human to read) language called a bytecode. Sometimes it is to actual machine code.

You seem to have realised at least some of the following, but I shall state it for the record. Matlab is an interpreted language. I think modern versions have a JIT compiler and some kind of bytecode, but the importance of accuracy means they don't tend to get too tricky. Some things that may allow you to utilize more of your computer's resources: Use builtin, library and vectorised operations wherever you can, these tend to be written in C/java/fortran and are highly optimized: A.*B is far faster than doing it with a for loop. Unroll tight loops (any with <10 instructions) if you can -- manually make it do several operations before looping, even eliminate the loop entirely if it's a set small number of instructions. The JIT may take care of this, but it helped on the last version of matlab I was using. You may be able to refactor or vectorize your equations somewhat so that more calculations can be done before you need to use them, sometimes even adding steps/temporary variables can help if it makes it more parallelizable (and memory bandwidth isn't the issue at hand). Pre-allocate memory where you can.It can be hard to tell with a language like matlab when you are allocating memory, but if you know ahead of time how big a vector/matrix is going to be, pre-set it to a zero array of that size before using it. Whatever you do, avoid incrementally increasing its size in a loop. (again, the jit can sometimes fix this for you, but don't rely on it). Factorise out and pre-calculate invariants. Explicitly set performance intensive loops to certain lengths if you know what they will be rather than calculating as you go or using a while loop. If there is a number you are calculating repeatedly that is the same or periodic in some way, see if you can pre-calculate it. The most important part is probably the first (built in functions and vectorization) which will tend to overwhelm the effect of the others. Also your algorithmic efficiency will in turn overwhelm effects from this. There is almost always a way of making an algorithm (asymptotically) faster, or making a tradeoff between time and space which is in your favour. The only question is whether the amount of effort required on your part is worth it.

Modern CPUs will tend to do about as much as you can fit in cache as quickly as you put it there for simple n or n^2 algorithms. Also if you don't exceed word length the computer probably won't know the difference. Also -- as Tiberius said -- there will be larger numbers on the constant and first order terms that change the results significantly for small n. Try it again with a few thousand bits and then double that (may have to use assembly unless you want to go shuffling things between different words -- not sure -- my C knowledge is rather weak).