Schrödinger's hat

@John: I get the impression from chinmayrshah that someone was referring to it as octagonal. I don't know who though. Answering this here in case the answer is useful to someone else That's a good question, I hadn't considered different order of digits. Let's have a look again at the problem: Looking at the first sum, we could try the digits being reversed. Start with 1+2,=3 Do we see a 3 in the left-most place in the answer? No. Perhaps the left hand side is reversed and the right hand side isn't? This would be extremely odd, but let's consider it for completeness. No, that doesn't work either. So we can reject the idea of it being reversed digits, it didn't work. (Aside: We could try it with the second sum as well, just for fun. 7+6=13, we have a 3. That fits 1403 and 1623 if the question is reversed and the answer isn't, but we have a carry 7+3+1(carry) gives 11, that doesn't fit either.) We can instead explore the idea of a different (but unknown) radix (ie. binary or octal or something). My thought process went: It's not decimal. No letters, try octal first (also you'd mentioned octagonal, so I thought octal quite likely). Octal works for the first sum, try the second. Correct answer. If I'd seen something like 1A34 (or even if I hadn't had the octagonal clue), I'd try hexadecimal first (base 16, you run out of numbers at 9 so the ones after go A B C D E F, F corresponds to the decimal 15). Hex is probably the most common base humans use after decimal (it's good for talking to computers as it's easily converted to/from binary). I'd try these because I already knew that hex and octal are very common in programming, and without further context I thought they'd be the most probable. A more general strategy would go something like this (assuming knowledge of modulo arithmetic, feel free to ask if you don't understand): The word radix means the base of your arithmetic, decimal is radix 10, binary radix 2 etc. Look at: 137+276=435 Assume left is the most significant digit. Assume the digits have the same meaning as they do in decimal (ie. 5 is this many ..... ) Assume + is addition. 6+7 = 5 (mod radix) I also know that 6+7 is less than twice the radix, because 6 and 7 individually must be less than the radix. So either radix + 5 = 6 + 7 or 5 = 6+7 I know 5 is not 6+7, so take the first one, then rearrange to get radix = 6 - 5 + 7 = 8 I know there is a carry, so try the next digit 3 + 7 + 1 (mod 8) = 3 Carry again 1 + 2 + 1 (mod 8) = 4 435 So either one of my assumptions is false, or it is octal.

Hahah, I know what you mean. Java's reputation for slowness is no longer all that justified. There is (and probably always will be) a lot of overhead, but once you get something started, arguing about performance vs. C is probably splitting hairs. W/ regard to standards, I gather there is a standard for the language, but it's not controlled by any of the standards organisations. With the amount of code (and business code) written for Java, I doubt it's going to go anywhere, and any compatibility breaking changes would result in mass migration to one of the non-official implementations. Python has a ways to catch up for most applications. Concerns about bit rot are probably fairly valid here, it's a young language and is still changing (major version numbers will break code). There seems to be fairly wide (and increasing) support for python among the scientific community, so I expect it to last a long time and wouldn't be surprised if it becomes the next fortran. By all means. I was just checking that you were aware of/had considered the alternatives. If your goal is for it to work anywhere and any time, I can't think of a better solution (with the possible exception of forth for the anywhere bit. Then again, even your fridge or kettle probably have C compilers written for them these days). If your goal had just been for it to work on most current systems, then one of my suggestions may have been worthwhile.

To other readers: Explained base conversion and the process of addition and carry in another base in chat. Posting to save someone covering the same ground. For your entertainment, here's Tom Lehrer:

What if it's just a really good simulation, such that all possible states that obey the rules are within the specs of the hardware? What if the glitches are actually just limitations of the universe? I often think quantum physics is a bit like an artefact of the universe being programmed in Haskell (with lazy evaluation) and some functions have side-effects that the author didn't think of, but taking it seriously isn't really productive.

A capacitor releases energy any time the voltage across whatever it is connected to is less than the voltage across the terminals. Consider the following: Charge a capacitor to 1V by attaching it to a power source momentarily. If you attach it across a piece of wire, or LED, it will release energy into the circuit. If you attach the positive terminal to the positive terminal, (and - to -) of a 1.4V batter, the capacitor will instead continue charging. Capacitors that are charged will also leak a small amount of energy because the dielectric is not a perfect insulator. The amount lost depends on how charged the capacitor is. This is (one of the reasons) why we don't use capacitors instead of batteries for long term storage.

Interesting. Why the requirement for absolute adherence to standards? Do you have some exotic platform it has to run on, or is it just a matter of principle? If it were just a pragmatic concern (having it run on 99.9% of personal computers), then I would have thought using a couple of platform specific libraries (with similar API), or some cross platform library where other people take care of the hairy details would be the path of least resistance. I realise nothing can beat the portability and speed of standard C, but everything comes at a cost -- in this case the amount of code you'll need to write. If write once run (almost) anywhere and few hassles are what you are after, have you considered a slightly more modern language? Python and Java have runtimes for almost any platform you can poke a stick at, and you don't even have to think about what you're running on top of unless you want a GUI (with the possible exception of endianness stuff). They also both have performance within an order of magnitude or so of native code, and a wealth of numeric libraries which are available for most/all platforms they are available for. (Not that it's the place for a young upstart who probably doesn't even know what he's talking about to tell you what to do; it's just that sometimes we forget/don't realise there are other tools about when we reach for the trusty ol' hammer.)

Apologies about the missing L. pcurses/pdcurses/ncurses all have a fairly similar API, and one of them should be available no matter what platform you're on. They should help reduce the amount of code required for portability along with providing features that may otherwise be somewhat cumbersome. ( pdcurses doc here http://pdcurses.sourceforge.net/doc/PDCurses.txt available at http://pdcurses.sourceforge.net or most likely through your package manager ) Combine them with one or two #ifdef statements (if that, PDcurses looks like it's fairly cross-platform out of the box) and you should be right. The requirement of FreeDOS rules out QT/GTK which are otherwise quite cross-platform (but run on top of a window manager). Out of curiosity, may I ask what you are doing?

I've little to no experience with c, but a quick cast around the internet turned up this: http://www.utas.edu....n/C/CStdLib.htm Also if you're on some form of unix, chances are you can use 'man stdio', 'man sprintf' or similar to bring up the relevant docs locally. And the prevailing opinion on a good answer to your second question seems to be to use ncurses (if you want to do it fairly portably): http://www.delorie.c...s_getch.3x.html http://www.delorie.c...rses-intro.html If you need lighter weight than ncurses for some reason, you'll probably have to do something dependant on the terminal you're using, http://stackoverflow...-enter-to-be-pr Outlines a few ways for various platforms. If you're looking for something flashier/more graphical in terms of output, then something like GTK or QT (or insert_OS_here api) would seem appropriate for your input, too. I think SDL also has some keyboard handling stuff if what you're doing is more game-ey.

Not always. ~> touch Empty.java ~> javac Empty.java ~> java Empty Error: Could not find or load main class Empty Some compilers/interpreters will choke (giving you output that is not in your source in the form of error messages), or not produce any program output. The latter could be argued to be a Quine, but it all gets rather philosophical. What is the output of a program that does not exist? I'd say it's undefined, rather than nothing. Mysticism aside, I should address the OP. Equilibrium: My own favourite source of problems of this type is project euler http://projecteuler.net/ They're very math oriented, so may or may not be to your liking. Other than that, some 3D programming as has been suggested would be the way to go.

Now I have to go digging in the memory banks. :/ I think PLU decomposition, then reading off your determinant by multiplying along the diagonal is faster in most of the cases that you'd care about speed (unless you're calculating determinants for very large numbers of small matrices). But then again I could be entirely talking out my posterior. There are even tricksier methods, but I can't recall off hand what they are. If you're just after determinants and don't care about how it's done, I'd highly recommend looking up some kind of linear algebra library or class, as this is the kind of work done in any given language by people much smarter than I am. If you're interested in the implementation, maybe tell me a little more about what you're doing and I'll see if I can find some relevant resources.

For one, use the code tags. There's a button that says 'insert code snippet, or just enclose the code in [code] and [ / code ] (without the spaces) tags. Unfortunately the forum software seems to like going completely bugnuts on the indentation unless you go for silly 8 space tabs, but it helps with readability regardless. private static void Fraction(int n1, int d1, int n2, int d2){ int ntotal, wholenum=0; int dnew1=0, dnew2=0; if(d1!= d2){ dnew1 = LCM(d1, d2); dnew2 = dnew1; } n1 = n1 * (dnew1/d1); n2 = n2 * (dnew2/d2); ntotal = n1 + n2; if(ntotal >= dnew1) { while(ntotal >= dnew1) { wholenum++; ntotal = ntotal - dnew1; } } I can't see exactly what you're trying to do from here (some comments might help?), but I do see there's no closing parenthesis. This last step looks like it's for turning an improper fraction into a whole number + proper fraction. Perhaps you can explain what isn't working?

Bear in mind this isn't the best way of calculating a determinant for a very large matrix.<br> If you're doing it for non-performance critical stuff, or an exercise, it's fine, but there are better methods for large matrices (available in many maths/linear algebra libs).

I guess you could have a big ol' magnetic track (at immense expense) and superconductors on the bikes. Thinks would not go well if they got too close though.... You would....melt the skirt? I think the concept of a ground effect vehicle (pretty much an aircraft, but the aerodynamics are such that it has trouble getting more than 20ft off of the ground) race would be pretty neat. Ludicrously dangerous though. Again this is somewhat incompatible with an extremely high power/thrust to weight vehicle. Given sufficient thrust and energy, you don't really care about the ground, other than avoiding it.

I would conjecture that on a similar track (number and tighness of corners even if they're made of different materials), something with tires would be faster for a given weight/engine power. Maglevs -- as far as I've seen -- produce low thrust and rely on the lack of friction and low frontal surface area for high speed. I don't know whether this is strictly because of weight/energy issues or whether it's also a matter of not needing the extra power in existing implementations. If you had enough thrust from some kind of thruster to out-manouvre modern wheeled vehicles, then the vehicle would be more helicopter than hover vehicle. Staying on the ground would only be a matter of control systems rather than any limitations of the vehicle. Something with wing-like control surfaces may be manouvrable without needing to produce that much thrust. I'd imagine it would be difficult to control though, and getting near another such vehicle would be exceedingly dangerous/difficult to manage.

Could you outline the situation and derivation you are speaking of? It's unlikely that we'll all have that specific book. I would also think that uploading a photo of the page, or some sections of the pages in question would fall under fair use.

There are thing you can do to make a conventional motorcycle go faster. There were some experiments with using aerodynamics to help cornering, but the extra expense (and potential dangers of travelling faster) resulted in it being banned. There are also engine technologies and materials that are banned from conventional racing, again largely for reasons of cost (otherwise even fewer groups could compete) and to reduce top speeds slightly (safety). (Think a turbine powered vehicle with flaps to help it corner made out of exotic, toxic and expensive alloys). If we ever get a good solution to the battery problem, the fastest vehicles will be electric; electric motors have been better than anything involving combustion for a very long time. This being said, there are only certain levels of acceleration a human being can endure, and races are boring without corners. Look at the Formula 1 cars for something approaching the extremes of what could be achieved and have the rider keep hanging on. You could get higher speeds, but your races would wind up as boring as the nascar go straight turn left. Traction is a big issue, getting the acceleration required to corner would require a lot of thrust (something maglevs are not great at, and very expensive fuel-wise if you're doing it with rockets or directed air). So tires are probably the best bet, and as moontanman said, tire technology is one of the limiting factors there. Short of the long: Anything 'like motorcycle racing' will be like motorcycle racing. If it's all about speed and less about corners, you could probably do something with maglev/mhd/some kind of ground effect vehicle, but I don't see how anyone rational would make a vehicle that travels much over 400km/h with an open top.

Most of the magnetic field would be produced by the bike. You could use relatively weak permanent magnets (or possibly something involving diamagnetism, although this is mere conjecture and I'd have to investigate it) on the ground to keep it airborne. Read up about magnetohydrodynamic drives. They're based on fairly sound physical principles. The main reasons we don't have them are: Incomplete understanding/ability to model turbulence and plasma physics. Lack of power sources Lack of powerful enough magnets. It's fairly reasonable to ignore these limitations in scifi.

As you're the author, you're going to have to draw the line between science and fiction, along with practicality vs whatever is important to your story. The idea of an MHD drive would simultaneously explain the ability to hover with a low cost track, the ability to overcome drag to an extent and the ability to move fast without becoming unstable. As I said it would probably be impracticle/dangerous to have an open canopy in this case, but this could be handwaved away easily enough (someone willing to move close to mach 1 at low altitude may not baulk at having to be careful where they put their hands around a possibly lethal electric field). If this was the case, the pilot wouldn't even need a windscreen/complete windscreen (although it would probably be helpful), as the same mechanism which guides the air around the craft could be used to deflect the air flow. The only problem I see with this is that an MHD drive this powerful would probably allow you to fly, so again it comes back to justifying why the pilot isn't at higher altitude.

The speed of sound would be an obvious hard to overcome limit. I'm not sure how harmful the shockwave would be if you were that exposed, but it would not be pleasant. That still leaves us with the range 400-1000km/h. A quick look at motorcycle speed records reveals many in this range. Although further investigation indicates that most of the vehicles travelling faster than about 400km/h are fully enclosed. This indicates two things: Going fast without a fully streamlined vehicle is hard Those people who want to go fast prefer the extra speed (or convenience) an enclosed vehicle provides. I would thus conjecture that the limits on drag and stability imposed by having an open canopy like the one you show are important at lower speed than the limits wheels impose. Further, if someone was going to go to the expense of doing this on a specialised track or arena, they would do it on the existing salt flats which can be found in many countries rather than building a dedicated (and very large and expensive) track for superconductors. They might build these specialised tracks for higher speeds than wheels allow, but reaching such speeds without good streamlining (including a closed cock-pit seems unlikely. Also at these speeds, it tends to be staying on the ground that is difficult (especially around or above the sound barrier). If you had a power/thrust source capable of keeping you at supersonic speeds for prolonged periods (this is difficult with wheels) then you would probably just fly. Maglev seems more feasable in this case, but the main attraction of magnetic levitation is that it is extremely energy efficient. This is completely at odds with the idea of a small, high frontal surface area to volume/weight vehicle with a single occupant, you would be using so much energy overcoming drag that the extra required to keep you fully airborne would not really factor into it. So again, you'd be more inclined to fly. Flying would also be safer. Thrill-wise it may not be quite as desirable, but you might depict pilots getting thrills by flying at lower and lower altitudes. One final concept that could be used is some kind of MHD based drag reduction. In this case your vehicle would also contain extremely powerful (far more compact and more powerful than we have today or know how we might build) magnets. It would also have highly sophisticated control for the field generated. As such, some kind of magnetic levitation would be the obvious choice. This would require smaller expense for the track; permanent magnets could be used. I don't really see such a vehicle being open-topped. It would necessarily be surrounded in plasma, and electric and magnetic fields powerful enough to be dangerous.

To elaborate a bit on moontanman's explanation: This is, in fact, the premise upon which the theory of special relativity is based. No matter what your speed relative to anyone else, any light you measure to be moving through a vacuum with travel at the same speed of 3*10^8m/s. In addition to this, there is no concept of absolute speed or velocity. Your car moving at 99.999999...% the speed of light is stationary in its own frame. This frame is exactly as valid as the one from which it is moving. Travelling exactly at the speed of light is not very well defined, but at any speed below you will observe a light beam that you emit moving at the same speed as a light beam someone passing you (at 0m/s in their on frame, or 99.999999...% the speed of light in yours) emits (in either direction).

So you are saying that the direction of the earth's orbit changes arbitrarily depending on 'frame of reference'? Realism states that it must either be clockwise or anti-clockwise. Hundreds of years of observations have measured earth to be orbiting anti-clockwise. So which is it? Has earth always been orbiting anti-clockwise or do you subscribe to subjective idealism?

Good point, although technically I only quoted one sig fig But yes, the electrons could become quite important if you were doing precise work.

I'd be wary of using something as imprecise as a spark plug tester, but as long as it is withing fifteen picokelvins of optimal, you should be alright. Trundling fluid is good, or you can use ordinary fromulgating powder from the supermarket mixed with a little aqua crinitus if you don't have any. It couldn't hurt to try. Worst that will happen is you'll blow one of the tidal coils in the Alcubierre drive. Make sure you put the tachyon shielding on after you switch it on to protect yourself from radiation in the event of a blowout.

Not all of them, I couldn't even get a bingo http://crackpotbingo.com/full?theme=crank&card_id=1191 But yes, it certainly does bear the hall-marks of a fine vintage of crackpottery.

Huh, never knew it was called a Dalton. I always just used atomic mass unit or proton mass (although I guess this last is not exactly the same). It's a unit of mass. Just like a kilogram or ounce, but it's a convenient size for molecules and similar sized things. If a protein is 1MD in mass, then it has 1 million nucleons (protons or neutrons).