Yep, most likely that'll be exactly how it goes.
However, right now, it's kind of fabulous.
Yep, most likely that'll be exactly how it goes.
However, right now, it's kind of fabulous.
Now of course gas stations don't always have fully occupied pumps and that's the point, so that almost whenever you arrive, there's a free pump available.
Well, there's likely a pump available. It isn't generally going to be free. Tesla charging stations, however, at least for the time being...
If you thought it was a quick process to build a Supercharger station, you were clearly wrong.
If you thought I thought it was a quick process to build a Supercharger station, you were just as wrong. If you thought I cared about how long it tool them to build such as station, you were wrong about that, too. And if you thought I liked java over c, you were still wrong. I could go on -- likely longer than even I, in the name oif pushing a point until it is completely blunt, am willing to do so, but I will refrain in the interest of keeping the peace.
Anyway, as it turns out, TFS serves as a veritable smorgasbord of potential if-then-huhs that can only be explained by somewhat bemused turtles all the way down.
At this time, I'd like to take a moment to thank my dear friend Yurtle.
Kindle's have bookmarks. They're easy to use and work very well. I use them exactly as you've just described.
That's not the suspicious part. This is:
"But instead, the performance was largely similar, except when it came to the timing of events in the story."
So they measured a whole bunch of things. What would you like to bet they didn't correct for multiple comparisons?
Nuh uh! There are also compressed air cars - they only explosively decompress upon tank failure!
At least with batteries, flammability or explosiveness aren't a fundamental requirement of how you're trying to propel the vehicle, just an unfortunate side effect of some variants of the technology (even not all types of li-ions are flammable). There's lots of people who assume that flammability is a consequence of electrical energy density, but that's just not the case. The actual charge/discharge lithium batteries via intercalating into the anode or cathode is more an atomic-scale equivalent of compressing air into a tank, you're having little affect on the substrate flammabilities and you're not even changing their chemical bonding, you're just cramming lithium ions into the space between their atoms. The flammabilty of some types comes from side effects, such as flammable electrolytes or membrane failures leading to lithium metal plating out; these aren't a fundamental aspect of the energy storage process.
Now, li-air, that involves an actual lithium metal electrode, and that is fundamentally flammable. Of course, so is gasoline. I have no doubt that they can reduce fire risks on li-air cells and keep them properly contained to prevent failure propagations. My bigger issues with li-air are its terrible efficiency, lifespan, and cost. I'm certain the latter would come down, and I expect that they can improve the lifespan, but I'm a bit uneasy about how much they can improve its efficiency. Right now, they're as inefficient as a fuel cell. : Who wants to waste three times as much power per mile as is necessary?
It is a non-sequiteur. The energy density of a li-ion battery doesn't even approach the theoretical maximum storage for the element lithium shifting between ionization states. That's hardly the only way this article is terrible, mind you. My head hurt every time they said the word "efficiency", it's like they were using it to mean everything possible except for actual efficiency. And if I read it right - who knows, the article is such a total mess - the researcher isn't talking about reducing battery cost, but increasing longevity. But maybe that was mangled too.
I think he was just pinging me for the ideas, which do predate my efforts and is certainly fair -- I started my whole "object" approach to c in 1985.
Of course, the whole point was to avoid using compiler tech that generated code I didn't intend it to generate, and in that sense, I got what I was after.
I wish I could still write my code in assembler, though. I was never more at home than when churning out 6809 or 68000 code.
Thanks, looks like very interesting reading. Bookmarked it.
He wasn't speaking for them, he was berating them. Your inability to grasp the distinction has invalidated your criticism.
You're arguing against Tokamak fusion. But what about, say, HiPER? Looks to me to be a much more comercializeable approach, yet it's still "mainstream" fusion, just a slight variant on inertial confinement ala NIF to make it much smaller / cheaper / easier to have a high repeat rate (smaller compression pulse + heating pulse rather than a NIF-style super-massive compression pulse). The only really unstudied physics aspect is how the heating pulse will interact with the highly compressed matter; NIF and pals have pretty much worked out the details of how laser compression works out. Beyond this, pretty much everything else is just engineering challenges for commercialization, such as high repeat rate lasers, high-rate hohlraum injection and targeting, etc.
I've often thought (different topic) about how one can get half or more of fusion's advantages via fission if you change the game around a bit. Fusion is promoted on being passively safe (it's very hard to keep the reaction *going*, it really wants to stop at all times), it leads to abundant fuel supplies, and there's little radioactive waste (no long-term waste). But what about subcritical fission reactors? Aka, a natural uranium or thorium fuel target being bombarded with a spallation neutron source. Without the spallation neutrons, there's just not enough neutrons for the reaction, so the second the beam gets shut off, the reactor shuts down, regardless of what else is going on. It'd be a fast reactor, aka a breeder, aka, your available fuel supplies increase by orders of magnitude. And your long-term waste would be much, much less in a well-designed reactor. Spallation neutron sources have long been proposed as a way to eliminate long-lived nuclear waste by transmuting it into shorter-lived elements.
I agree that Chrome browser has a generally pleasant interface (to the point that other browsers feel cluttered, to me). However, look at everything else Google touches. It's always cluttered, clunky, and misleading. G+, youtube, youtube mobile clients, youtube clients on consoles and roku and other devices. Google Docs. Even Gmail to a degree. Google has two things that are pleasing as interfaces: Chrome and Google.com's main page. Everything else feels like an engineer tossed it together in a day after working on the backend for two years.
Granted, this is but one man's opinion. Maybe everyone else loves these interfaces...?
I'm fine with subscriptions. I would rather pay $5/mo to RDIO for access to their massive library than buy music. What could that $60/yr get me? Four CDs? No thanks.
On the other hand, they're all missing a lot of content, too. It's frustrating to really want one chunk of music and simply not be able to get it. And, of course, no subscription service gives you Led Zep or Beatles and AC/DC and so on, it seems.
I just don't know that I'd give Youtube $10/mo. Double the price.. for what is probably a weaker selection (and one that is probably geared more toward Gaga, Bieber, PewDiePie fans).
Plus, Youtube means Youtube/Google interface. Fuck that. RDIO isn't great, but at least it wasn't designed by Google's interface guys. *shudder*
Have you ever written C code which uses a switch statement based on what type a struct/union is and calling the relevant code for it?
No. When I use structures as objects (which is often), they almost always contain a pointer to a block of general methods appropriate to that structure, as well as containing any methods unique to the object, all of which are called through the object/structure, so it would be unusual, at least, to be testing the object type in order to choose an object-specific procedure to call. However, I do mark each object type with a specific ID and serial as they are created, along with a tag indicating what procedure created them, as these things facilitate some very useful memory management and diagnostic mechanisms.
Have you ever used qsort?
I am aware of qsort. But I have my own multi-method sort library that I use. Most of them locate the comparison mechanisms they are to use through the procedures specified by the objects they are asked to sort. Likewise list management, memory management, certain types of drawing primitives and image processing primitives, image handling mechanisms, associative storage, basically anything I have run into that I thought likely I would need more than once. I am positively locked into the idea that if I write it, I can fix it, and the number of bugs and problems that fall into the "maybe they'll fix the library someday" class are greatly reduced. I'm a little less picky if I have the source code to a capability I didn't actually write and can supply my own version if and as needed. A good example of something like that is SQLite. Actually having the source code and compiling it in reduces my inherent paranoia to a somewhat duller roar.
Any program which runs right is obsolete.