Somebody mod this up, that's exactly what's done on ARM.

True, but that's not the case with ARM though since thumb mode. Most instructions are then two bytes. ARM also has some neato features in it's instruction set, like you can shift for free almost every time you do anything else with a register like arithmetic. Also condition codes only change when you want them too. And almost every instruction can be conditional. This makes it so that the little cache there tends to be is utilized pretty well and you don't really need the branch prediction logic as much. I think unlike the other RISC chips, in the case of ARM, IA32 keeps up only since they are made in more modern efficient process to a greater extent.

I agree and unless there's something in CPAN pretty much already solving my problem (which happens a lot actually), I almost always choose python so I'm being honest unlike that person that somehow thinks the python makes more sense. I think that with perl, it depends how much shell scripting someone did first. Somehow a person needs to have experience with some syntax that's not like C/java/pascal and has reached the limits of shell scripts plus tools like sed and awk first before perl clicks or they can see the value in it.

You answered the real reason why maybe, it was a couple of instructions. In SWEET-16 it was one. Storage was expensive then. I think that must have been the real reason.

Exactly, also BMW and FIAT have engines with throttle bodies where the butterfly valve is open under most conditions. They all have spark plugs though, which is what I think the fellow you replied to was thinking about.

What? Like there is a carry flag, there is an adjust flag, it's set every time (unlike needing to use adc say). You just do the normal add, sub, or mul. Then daa, das, or aam respectively to adjust the values to BCD.

Now that's a proper car analogy!

No Bob sets AL = 0, does int 13h, and writes down the values of the registers. Then he does AL = 1 .... After that he hands that document to Fred, who writes the code that acts the same.

Sorry if I caused any offense. I don't know them, I'm sure they are great. I was just replying in regards to the list of reasons, which I thought was weak in my opinion. Sometimes I get cynical and snarky, again I apologize. I should have stopped at before all that you quoted, it was a reasonable response the words I wrote before that. Basically that not much has kept-up with visualization, especially in a browser. I worked (wow now more than fifteen years ago) on that as my first job after graduation, it sort of depresses me the state of scientific visualization to this day, hence why I got so grumpy in my reply. Cheers

Wow that's pretty bad, the only reason in that list that makes any sense is the rails one. But there have been lots of visualization packages for science for decades. It's just that it's a brand new group of people, not familiar with what is there, only familiar with what they know already or what there is buzz about, and they want to use that. These are ruby coders after all.

I've bought a new car and one for my wife, I took the cash back once and once the 0% precisely for the sort of calculation you did. There was a big trade in one case that made the financed amount small and the relative percentage of the rebate big enough (and I still had a big enough cushion of savings afterward). It's just not as simple as you initially made out as it's free money - take the 0%.

That principle allows you to have line noise that parses in other languages, make is harder to do that in python, so I don't know really if it should be followed to such dogmatic ends. There still is a lot of freedom in presentation in python after all. The cstyle and later astyle commands are a taste thing, some C coders liked it, others didn't. I always like to use whitespace to help me and others understand code and have it in a consistent style from the get go, not have a script or program munge it for me. I can have my editor auto indent python code too though, I use that a lot like when moving a block of code into a function, its moves over to the left on paste. Also about the new coders and pasting from examples on the web, having your editor change tabs to spaces always including (especially?) on paste seems to do the trick pretty well for those that do not want to deal with that headache.

1. vim s///g
2. vim folding
3. vim >, <, or =

I guess vim isn't an ide though, thankfully.

Really? There wasn't an option like 0% financing or $2500 cash back? If you had say $17.5k in a savings account it would not have been a $20K car.

I think the one key thing that you do not expect is how aperture effects DOF and exposure. So you need a certain amount of light to enter the back of the camera. I think the way you think is very technical, think about it like you need enough to beat the S/N for a decent photo. Can you buy that? Well when you have the shutter open for a short period of time you are letting less light in. So to compensate you can use more light. Well that's hard because you already are bathing the set with a lot of light. But let's assume you could get more light. There is also the issue of darker materials reflect less light than lighter ones and you need to make sure that the white and other such light colored objects in the scene do not wash-out completely while you have still detail in the darker areas. In fact with a lot of light you can actually see the lens elements themselves in the image you capture. So it's hard, you need just the right levels. Images that are overexposed look dull and lifeless as well as washed-out. The more overexposed that they are, the harder to correct, and if over-saturated in areas, they really cannot be fixed later. Photographers call this a blown highlight. Again in your way of thinking, all those values are pegged at 16K or whatever even though there was a whole range of them beyond. Incidentally CCD response also happens to not be linear. But there are more fundamental problems.

See the another way you could let more light into the back of the camera would be to use a larger aperture. This means that the shutter opens to a larger diameter. So first the problem is one that you can throw money at to solve to a certain extent at least. For practical reasons lens that have a larger aperture have other deficiencies. One very common one is that they have a much more limited zoom. To some extent better made lens can solve that, but there are some limits. Like you want a big CCD back there right, so you can average to beat some of the noise. Oh and you say you want 3CCD (which further reduces light to each CCD BTW). Ad yes you do want to be able to pull the shot (zoom), so soon you could make an awesome camera, but it would rival the Hubble in terms of size. (I exaggerate a bit, but you get the idea.) Still it's hard, they tend to be less quality lens for the same price as well, like 5 elements instead of 7, more aberration, etc. But beyond those practical aspects, there is the most fundamental problem, and that is depth of field. When you have a small aperture, it's like a pin-hole camera. Things close by and those things relatively nearby will seem in focus. But use a wide aperture and only those things relatively close to the focal point of your lens will be in focus. It's actually sort of neat in say single subject portrait photography since anything makes an interesting sort of random looking background and you only need to focus on a single face, but it's not good for most films where you have many subjects you want in focus as well as having the background maybe out of focus but with enough detail to still make out more or less what is there instead of plasma looking globs of color. That's an optics things, really can't be solved computationally or anything like that. Would need radical new lens technology, one that splits light most likely, getting you back to your original problem. Yes there are high speed videos, lots of them, but next time you watch them pay attention if you can see anything other than the popping balloon or what not in focus and how saturated the or overblown just generally balanced well the images look. Usually it's some scientific context and you can make-out what process is occurring, but it does not look good in terms of cinematography, like the shadows look dead or really noisy.