Re: I've already got a working fusion power source
Or... we could _decrease_ the power output of the sun, thereby eliminating global warming, then use more fossil fuels to bring the temperature back up. Simples!
273 posts • joined 12 Aug 2014
I think the idea that denizens of a cloudy planet wouldn't know about space was common in science fiction before the Mariner 2 flyby in 1962, when it was still thought that Venus might be a hot, swampy, inhabited planet. The only two examples I can think of are :
- _Tumithak of the Corridors_, written in the 1930s (humans land on Venus, are immediately killed, Venusians realize there's an outside universe, build spaceships and invade Earth). Don't remember the author.
- Don't remember the title, but Heinlein wrote a story in the 1940s in which humans have colonized the poles of Venus, the equator being uninhabitably hot. One character explains to another that the natives near the north pole think humans came from the south pole, and vice versa; tell them about Earth, and they think you're explaining your religion.
Both predate Douglas Adam's fine work, and I think Asimov and/or Clarke may have touched on this subject as well.
A simple divide-by-four will work between 1900 March 1 and 2100 February 28. Which might have led the above to be expanded to...
3) What's the likelihood this will be used after 2100 February 29?
The nature of the assignment isn't mentioned, but if it involved birth dates... in 1991, my then-100 year old grandfather, and many others born before 1900 March 1, still walked the face of the earth. If it involved hundred-year mortgages, there could have been problems nine years later, on 2000 February 29.
strlcpy/strlcat will silently truncate the copied string. Sometimes, that's what you want, but I find that usually, it indicates a problem. You basically need two functions : one says "truncation is expected in this case", vs. "truncation means something went wrong; stop now and emit a hopefully helpful message."
After years of trying various solutions, I now have supplemented strlcpy/strlcat with 'error' versions. With these, if the string doesn't fit into the specified buffer size, you get a message and an assert() is triggered.
Similarly, I have an snprintf_err() function for cases where a buffer overflow should be a red flag.
In theory, these could just be replaced by the non-_err() functions on non-debug builds. However, 99% of these calls are not in high-performance code. For the remaining 1%, I would use
strlcpy( arguments) or strcpy( arguments)
I've been writing C code since 1987, and have been slow to the party on these points. Kinda wish I could go back in time and tell my younger self about the value of adding in these "idiot checks". I don't think I've had security issues as a result, but Dog knows I've certainly had "code-not-working" issues.
Sorry, lapsed into astronomer-speak, where "secular" = "linearly changing over time", usually opposed to "periodic" = "changing back and forth around some mean value". The seasonal changes are periodic. The overall trend to a slowing earth is secular.
I probably also should have noted that most of the gradual (secular) change in the earth's rotation rate is, of course, due to lunar tides. That causes a transfer of angular momentum; the moon recedes at about 3 cm/year, and the earth rotates slightly more slowly.
I conjecture that the downvoters thought I was blaming global warming for leap seconds. It's a measurable factor, but that's mostly just because we've gotten really, really good at measuring the earth's rotation. And, in fact, we've had a slight speed-up in recent years; we may yet see a negative leap second. Kinda early to say, but there have been reversals of that sort (all before leap seconds were adopted.)
If we do reach the point where there's a negative leap second, I'd expect lots of arguing in favor of abolishing leap seconds. I'd bet lots of code is not currently set up for such... come to think of it, my own code doesn't account for negative leap seconds, and it'd be some serious work to do so. (Though on the bright side, we don't have the "one second repeating" issue that occurs with positive leap seconds.)
Well, yes and no. We'd temporarily speed up the earth's rotational speed; it would then return to normal. But if we'd gained a second, we'd keep it. Sort of as if you had a clock running a bit slow and set it ahead; you wouldn't "fix" the long-term slowness of the clock, but it would temporarily be closer to the actual time.
Strange as it may seem, the human race is actually having an effect on the earth's rotation, though in the wrong direction to fix this problem. There's always been a seasonal component to the earth's rotation, caused by ice melting and re-freezing at the poles. There is now a secular component due to ice melting and not freezing; it tends to flow away from the poles and, via conservation of angular momentum, the earth turns at a slightly slower rate. This will cause more leap seconds, not fewer.
I suppose you could argue that a side benefit of "fixing" global warming would be that if ice started re-forming near the poles, we might get the earth's rotation rate back up to match the SI second, eliminating the need for leap seconds. Fine-tuning might then be required, in the form of emitting or capturing CO2 to get the rotation rate Just So.
Interesting. Looks as if the plastic removal really ought to be done at the mouth of the Yangtze.
I say that only somewhat tongue-in-cheek. I would ass u me that the density of garbage is greatest at these river mouths. Then again, you presumably also have much more shipping traffic at these locations; running their "sweeper" back and forth is going to be an obstacle course.
Dunno how "global" this is, but in the US, we have time/temperature signs, usually on banks, cycling between displaying time, temp in degrees F, and temp in degrees C. I've always wanted to hack one to also show the temp in "degrees" K. If I ever do so, I'll try to remember to leave out the degree symbol.
(Though truthfully, I'd prefer the now-obsolete use of Absolute and Centigrade. I appreciate the desire to honor Kelvin and Celsius, but there's something to be said for designations that actually tell you what's being discussed.)
"...It also follows Pi Appreciation Day on July 22..."
July 22, also known as 22/7 = 3.142857..., is π Approximation Day. My wife even made a quiche, which is approximately a pie. (In truth, I think it was just a coincidence, and she just happened to want to make a quiche. But it was baked in a pi plate.)
Years back, when I got junk mail with a self-addressed prepaid envelope, I'd circle my name and address, write REMOVE FROM LIST next to it, and send it back to the offending organization.
Some didn't pay any attention, of course. So I took to writing DECEASED -- REMOVE FROM LIST (which horrified my wife and my mother, but was more effective.) I still got offers for pre-approved credit cards; apparently, death wasn't enough to make me a credit risk.
Only later did it occur to me that if I ever do need to take out a loan, I'll probably be told : "Sorry, Mr. Gray, but our records indicate that you're dead."
"...it does seem a little impractical to assign 5.5% of the Unicode space (so far) to pictograms..."
Sadly, Unicode has 0x110000 = 1114112 code points (the odd number has to do with the inner workings of UTF8 encoding). So we've wasted a bit over 0.3% of the available code points on emoji thus far. I don't think the emoji madness will stop until most of the remaining ~million (US) code points have been assigned to them.
Julian date format != Julian calendar.
Julian date format (in this context) means expressing dates in year and day-of-year format. It is a mangled version of "real" Julian dates, which are a straightforward count of days elapsed since noon -4712 Jan 1. The name is unfortunate; you can have Julian-format dates for the Gregorian calendar, as occurred here.
The Julian _calendar_ is the one where any year divisible by four, including century years, are leap years. Your note about the Gregorian fix is correct.
"...I mean, Google isn't a pubic utility..."
Are you sure? They've always seemed like a bunch of (censored)s to me.
Aside from that, you are correct; even if Google (or other tech giant) really did Take Our Customer's Privacy Seriously, it'd be easy to mess up. About your only way to stay safe is leave your phone at home, don't do any searches for sensitive topics, and don't drive your own vehicle through any of the various licence tag scanners used for toll collection on the way.
I'm the Bill Gray mentioned in the article. But my only connection to the Planetary Society is that I wrote a couple of articles for them, quite a while back. (One of which, coincidentally, was about Chang'e 2 and its flyby of the asteroid Toutatis, which involved similar sleuthing to figure out what China was up to. This would all be much simpler if the China National Space Agency would just tell us what they were doing, the way ESA and NASA almost always do. But I'll admit that it's more fun when CSNA leaves us little puzzles like this to figure out.)
I'm 57, and used a slide rule a bit (not much) in my early teens. Not sure what happened to it. I now have two of my grandfather's slide rules (pocket versions with not many functions) and recently picked up the Versalog at a thrift shop. Basic calculations are quite straightforward; developing the facility to tackle anything really complicated would probably take more practice than I'm apt to invest. Definitely an elegant computing instrument for a more... civilized age.
My 10" Versalog slide rule says 355/113 = 3.145, or close to that.
(I had to get my reading glasses out to see the numbers. The intersection on the Venn diagram of people who know how to use a siide rule and the people young enough to do so without reading glasses is probably just about empty.)
Not exactly astrophysics, but some old code I modified for artificial satellite orbits had a value of π given to enough places for a 32-bit float, but not for a 64-bit one.
"...The primary purpose of the Data statement is to give names
to constants; instead of referring to π as 3.141592653589793
at every appearance, the variable Pi can be given that value
with a Data statement and used instead of the longer form of
the constant. This also simplifies modifying the program,
should the value of π change."
-- Fortran manual for Xerox Computers
Not sure why you're getting downvotes. Your basic idea is right, with the minor quibble that 100 trillion = 1014, not 1015. (As a Yank, I will leave it to other commentards to quibble about long vs. short trillions.)
In a sequence of that length, any given string of fourteen digits (fourteen zeroes, or 12345678901234, etc.) has a probability of almost exactly 1/e = 36.8% of appearing zero or one times. The probability of n occurrences of the string is 1/(e * n!). So, an 18.4% chance of two occurrences, 6.1% of three occurrences, and so on.
Forgot your troll icon, eh?
I'll grant you, it's an arbitrary distinction, sort of like the legal distinction between fruits and vegetables. Your average citizen would probably say that "assault weapons" are "weapons intended solely to kill lots of people at once, as opposed to what you'd use to defend against an armed robber or shoot a deer or other 'legitimate' use."
Since the "intent" is not necessarily clear, they went with a more arbitrary definition that (they hoped) would roughly line up with what they actually wanted and be good enough for government work. But you knew that.
Hmmm... it's difficult to say without knowing the likelihood of nuclear annihilation. But we can still do a Fermi estimate.
A quick search on "number us people shot by police" gets you agreement on a bit over a thousand a year, out of a total population a bit over 300 million (you wrote "citizens", but I'll consider citizen=person for this rough approximation). I was surprised at how good the agreement was amongst politically diverse sources, by the way, though I could imagine some systematic biases (I'd expect many murders by cops to go unreported and/or covered up).
I'm also saying "numbers killed by police" rather than "numbers shot". It appears the first is carefully counted. Oddly, the latter is not.
Let's say "nuclear annihilation" would kill half the US (I'm considering the risk to US people, as I assume you were as well). If the probability of nuclear annihilation in a given year is greater than 1000/150 million = about 0.0006%, you're more likely to die of nuclear annihilation than of being shot by a cop. I'd guess the actual probability of nuclear annihilation is much higher than that.
I think you may have an exaggerated sense of how commonly people are shot by cops in the US. It's indeed dramatically more common than in any other country, and is much more of a danger to Americans than (say) mass murders with assault weapons, especially if you aren't white. But even with that, they're still about 30 times less common than garden-variety firearms murders. (Again, much more common in the US than anyplace else, because Freedumb.)
"...the lizards oppress the people horribly, of course, and nobody likes them," Ford said. "But people vote for them again and again."
"But why?", Arthur asked patiently.
"Because," Ford explained, "if they didn't vote for a lizard, the wrong lizard would get elected. Got any gin?"
(Or something like that. Working from memory here.)
OP's (my) formula _and_ your formula are both correct. Acceleration = r * ω^2 = v^2/r. Remember that ω = angular velocity = v/r.
At half the radius, the velocity is (also) half as much. If the acceleration ran strictly as 1/r, you could get one heck of a centrifuge by putting objects a few microns off the axis.
Assume the vehicle's going about 100 km/hour = 27 m/s. I'm too lazy to go outside and measure my vehicle's tires at the moment, but the radius is probably about 25 cm.
The acceleration will be v^2/r = about 2500 m/s^2, or about 250 gs. Gotta admit that I started writing this to dismiss the idea that the g forces would be significant, but that's a fair bit of acceleration.
The above is for the outer edge of the tire. The watch was presumably strapped in at, say, half that radius and would have experienced half the acceleration.
The stupid is obviously already strong in this one on many levels, but we can add the stupidity of not putting the watch someplace where it's less exposed to view and to possible damage.
"How do people without a brain ever get elected?"
Well... if you took the idiots out of Congress, it would no longer be a representative body.
(Some years back, when Richard Nixon nominated a particularly hard-to-defend choice to the Supreme Court, one senator was reduced to arguing : "Okay, this guy is mediocre, but so are many Americans, and they deserve representation, too, don't they?" Somehow, nobody replied that mediocre Americans had ample representation via the Senate already.)
An interesting thought problem, of the sort that would be useful for a physics instructor. Somebody should ask Randall Munroe to do a "What if" about this.
The net effect on the earth-moon distance would be (drum roll...) effectively zero. If you look at most of the formulae for orbital speeds and periods, they rely on M+m (sum of the mass of the primary and secondary). Often, m is considered negligible (for spacecraft or small asteroids, for example), but it wouldn't be in this case.
So even if you somehow got significant amounts of mass from the earth to the moon, M would drop a bit and m would go by the same amount, it'd cancel out, M+m would remain unchanged, and we'd remain about 385000 km apart and orbiting each other about once a month.
I'm ignoring here the side effects of getting that mass to the moon. If rockets are involved, some of the exhaust may leave the earth-moon system, and M+m will _drop_ and the earth and moon will recede from each other. Also, there's a slight gain or loss of energy and angular momentum if the object impacts, rather than soft-lands, on the moon. If we found that the accumulated impacts had resulted in a lower orbit for the moon, we might have to switch to having them impact the other side for a while to balance things out.
More mundane, I'm afraid. '2020 X' = found in first half of December 2020; 'L5' = an index of which discovery it was within that half-month.
Circa mid-90s, I started my (one-person) company, Project Pluto, with the (now long discontinued) US toll-free number 1 (800) PR-PLUTO.
A few months later, my mother was going up and down in the world and to and fro in it, and wanted to call me from someone else's phone. So she called 1 (800) PRO-PLUTO. The telephone system silently dropped the trailing 'O'.
My mother gets a breathy voice explaining the delights awaiting her, inviting her to press 1 and have a credit card ready.
Easily enough explained when she next saw me, but she did briefly wonder if I'd changed my business model from writing software for astronomers to... ah... discussions involving "heavenly bodies" of a different sort.
The thought occurred to me that both the number of planes and the bit depth could easily be variables. For black/white images, one plane and one bit; for monochrome images, one plane and N bits, and so on. Astronomical images sometimes have 32-bit depths; the eventual image shown to humans is reduced, but there can be a large dynamical range between a magnitude 0 star and a magnitude 20 star, so you need those extra bits while processing. For color line drawings, three planes at two bits each would suffice.
And then it occurred to me that rather than doing "look-backs" at the last 64 pixels, you should look at the 8x8 block of adjacent/above pixels; these are more likely to include matches. Switches allowing some degree of lossiness would be easy to do. By default, it doesn't do a thorough job of checking the last 64 pixels; a switch to do so could get better compression at the cost of some speed.
And... by the time you're done with all of this, it all starts ballooning to PNG and JPG library sizes and complexity. So : never mind.
At my first job (1987 to 1992), I used KEdit (in DOS). On leaving that job, and my paid-for copy of KEdit, I decided I'd just write my own text editor. (I was young and foolish.) 29 years later, I still use it, ported from DOS to Windows to Linux. I've posted source code for it, mostly so I can download/compile/install on other machines.
It does suit my needs nicely (and because I wrote it, I can modify it as needed). And you are correct about the process of writing it being educational. But no halfway sane person would ever use it.
Interesting link. You'll notice, though, that it is quite clear that it refers to _small_ businesses.
In theory, the same laws and ideas apply to all corporations. In observed reality, for larger corporations, maximizing profit becomes (almost) the sole consideration. If making useful products at a decent price will do so, they'll do that. If killing lots of people will do so, they'll do that instead. (And I do not exaggerate. Consider the tobacco industry, which knowingly kills lots of people in a slow and disgusting manner. The history of the asbestos industry, leaded gasoline, and the fossil fuel industry's reaction to climate change arguably offer similar examples.)
Also not mentioned in that article is that corporations can exist for all sorts of reasons; if the shareholders want the corporation to maximize the world's supply of unicorns and rainbows, it will be the corporation's responsibility to do that. And some smaller businesses do so. But again, real-world megacorporations don't do that.
I run a (very small) business. I'm a big fan of capitalism as it works on my scale and at medium scales, and even (sometimes) at larger scales. But my fandom is a practical one, not a religious one.
An object that is, say, ten times larger than another will have a thousand times the mass and a hundred times the cross-sectional area. So the _force_ of drag will indeed be a hundred times larger for the larger object. The _acceleration_ (force divided by mass) will be ten times less. Sort of the way a snowflake experiences atmospheric drag and falls slowly in the way that a snowball doesn't.
In theory and practice, this does mean that the smaller stuff gets dragged down more quickly. Though in most cases, not quickly enough.
You're right on the observability issue, though. If I recall correctly, objects down to about ten cm are currently reported by CSpOC (US organization that collects radar data and provides orbital elements). The new "Space Fence" is supposed to raise that by a lot, so I assume it'll do so by tracking smaller objects (which certainly seems like an excellent idea in any case). But even a one-cm object hitting at several km/second will do serious damage.
An amateur astronomer in the western US imaged the spacecraft shortly after perigee, at a distance of about 17000 km. The following is available even to F__ebook refuseniks (including me).
Of course, all you get is a streak moving among the stars. (Or, when the telescope is tracking the spacecraft's motion, a solid dot and the stars become moving streaks. This image takes the first approach.)
Should note that amateurs (and some professionals) get images of spacecraft leaving the earth/moon system fairly regularly. (Exceptions usually involve the object's departure route putting it close to the sun in the sky.) It's the only tracking data we have for the boosters, and can come in handy when the asteroid surveys are wondering if they've found a rock or just some old bit of space junk.
These are low-thrust devices, only used once an object is in (at least) low-earth orbit. You have the cost of the propellant, _and_ its storage tank (significant for xenon), _and_ the cost to get it to LEO in the first place. See slide 9 of the link below; looks as if at best, it'll run you over $1000/kg for that bit.
So ignoring the storage issues, but adding cost-to-LEO in, you're looking at $1080/kg for iodine; krypton, $1003/kg; xenon, $1850/kg. Also to be considered is exhaust velocity; if one propellant can be expelled at ten times the velocity of another, thereby generating ten times as much thrust per kilogram, that'll slant things in yet another direction.... I know xenon has an exhaust velocity of around 40 km/s; dunno about the others. If they're significantly slower, it'd go a long way to explain why xenon gets the use it does.
Yes and no. The US test was on an object already at low altitude. As a result, most of the bits decayed rapidly, with the last bit coming down 20 months later.
You can argue against ASAT tests on a variety of grounds. But if you're going to do them, for $(DEITY)'s sake, do it on an object at low altitude where it won't cause much trouble. Such objects are numerous. There is absolutely no good reason to blow up something at the altitudes of the Russian, Chinese, and Indian tests.
Ah, but how do we know our AC friend is really just an anonymous conspiracy nut?
If I were trying to communicate securely in the face of a nation-state adversary, I wouldn't send my messages directly to the recipient; I'd post them on a forum such as this one. And it now occurs to me that might add something to make the post appear as if it came from a harmless nutter not worth decrypting. I'd start and end with a few bytes from /dev/random.
Speaking of good excuses...
I write software for one of the asteroid-hunting sky surveys that searches for objects that might hit us. Most clear nights, their telescopes will gather images of various chunks of the sky, then look for objects that move against the background of the stars in a straight line. This starts up a few days after a full moon, then runs for about three weeks until a few days before full moon. (Near full moon, the sky background is bright enough that the telescopes really can't see fainter objects well anyway.) All three of the major surveys, one in Arizona and two in Hawaii, follow this cadence.
At one point, we were trying to figure out a software issue involving getting data from the Minor Planet Center, which gathers all the measured positions of asteroids (astrometry) and tries to make sense of them ("this set of points links up to this set of points; they're the same object"). We eventually figured out that the issue arose during the time near full moon, when MPC was doing much of this linkage work.
I commented that I've frequently heard software problems blamed on "it must be a full moon", but that this was the first time it really _was_ because "it was a full moon".
Hmmm... hadn't tried such a thing, but
int main( void)
*(int *)0 = 0;
gcc -Wall -Wextra -pedantic -o z z.c got no warnings. Chalk one up for clang, though; it realized this was a no-no and warned me. However,
int main( void)
int *null_ptr = (int *)0;
*null_ptr = 1;
slips past both compilers without warning. (A thank-you to jake for reminding me that one can use HTML tags on these fora.)
Biting the hand that feeds IT © 1998–2022