4 ms·
A lot of the problems cited make sense in the context the machine was designed for. Of course it did math in decimal. The designer did math in decimal, the user
by ummwhat 5y ago
A lot of the problems cited make sense in the context the machine was designed for. Of course it did math in decimal. The designer did math in decimal, the user input was in decimal, they wanted output in decimal, and unlike electrical switches, mechanical switches aren't naturally limited to just on/off states. Of course the register supported 40 digit numbers. This was a machine that would have to be cranked. The clock cycle was literally a cycle. Anything less than 40 and you could more economically pay someone to calculate directly. It's easy to say "just do it in software" when cycles are measured in GhZ.
- a_shovel 5y ago> Of course the register supported 40 digit numbers. This was a machine that would have to be cranked. The clock cycle was literally a cycle. Anything less than 40 and you could more economically pay someone to calculate directly. Yes, but larger registers would need more physical force to manipulate. If you had smaller registers, you could have a higher gear ratio on the crank, allowing the machine to run faster for the same input force. If they wanted to perform some particularly complicated instructions, then they might want a lower gear ratio instead. The obvious solution: install a gearbox and a shifter.
- pishpash 5y agoThat's extra complexity kind of like adding frequency throttling or sleep mode.
- Animats 5y agoThis was a machine that would have to be cranked. The Difference Engine was hand-cranked, but the Analytical Engine was intended to be steam-powered. The thing was going to be the size of a locomotive. Most of that was memory. As I've pointed out before, the big problem in the early days was affordable, fast memory. Babbage's design, at least one version, was to have the ability to store 1000 numbers of 40 digits each. So, 40,000 number wheels, with some kind of mechanism to bring them to the read/write station. Access time would probably have been measured in seconds. The arithmetic unit wasn't the big part of the machine. It was roughly equivalent to a desktop mechanical desk calculator, after all. Something similar appears to have happened with Babbage, where he started with a simple calculating device and, thinking about it more deeply, single-handedly came up with a Turing-complete design and was writing programs for it. Desktop calculators existed long before Babbage. Leibniz built the first mechanical multiplier around 1673. Mechanical arithmetic was known. Babbage's contribution was the instruction decoder and control unit. Mechanical arithmetic was limited more by cost-effectiveness and reliability than by conception. The commercial breakthrough was cash registers, in the mid 1880s. First really cost-effective application. Babbage's machine might have been buildable, but not cost-effective. A few years ago, there was some guy in the UK talking about an analytical engine build. But he never got very far. I'm surprised someone doesn't have one running in Minecraft or Unreal Engine.
- codeflo 5y ago40,000 decimal numbers is about 16 KB of RAM (40K * log2(10) / 8). That’s 1980s home computer territory — there’s no way that amount of memory would have been needed for anything. (Given today’s understanding of efficient algorithms.)
- Animats 5y agoBabbage was perhaps thinking a bit too big. Also, the 40 or 50 digit decimal number thing comes partly from not being clear on how to manage scaling "However, by inserting an imaginary divider between the same two figure wheels of all variable number columns, thus making all coefficients and numbers within the Store possess the same number of decimal places, decimals could be used."[1] So there was one decimal point location for all memory locations. Babbage apparently didn't include a general shift function, which is necessary for rescaling results. If you can shift to discard low order digits, as on mechanical desk calculators, you need maybe 10 digits, and a 20 digit product register, so you can multiply two 10-digit numbers and then round off or truncate the result. Without that, you need a lot more digits to avoid overflow. So close... Useful programmable calculators from the 1970s had 20 to 100 memory locations, each capable of maybe 10 digits. A base Babbage machine with 200 digit wheels of memory, expandable to 1000, would probably have been feasible and moderately useful. Useful for cranking out navigation and gunnery tables, at least. Babbage's difference engine has about that much storage. So that was probably buildable as a minimum viable product. [1] https://cs.stanford.edu/people/eroberts/courses/soco/projects/1998-99/babbage/ana-mech.htm https://cs.stanford.edu/people/eroberts/courses/soco/project...
- codeflo 5y agoThat sounds like the fixed point representation is part of what causes the huge memory requirements. It's fascinating how obvious some ideas are in retrospect. Floating point is basically just scientific notation, which was well known AFAIK. But I can imagine that it's hard to make the transfer to use that as the representation for all calculations.
- 5y ago
- wmf 5y agoYeah, I was also wondering about performance when I read this. The Analytical Engine wouldn't have been fast to begin with and using a narrower datapath would have made it even slower. AFAIK if you measure the time-space complexity of emulating wide operations in software it's a loss. 8-bit PCs were derided as toys in the 1970s and with the benefit of hindsight people now scoff at that idea, but PCs really were much slower, less capable, and harder to program than minicomputers.
- pishpash 5y agoAnd we're going wide again, as soon as we have the means to do so. The virtualization penalty is real.
- zozbot234 5y ago8 bit computers were basically glorified calculators that could double as video game systems and perhaps BBS terminals. Even data storage was very much an afterthought on those machines until well after floppy disks entered common use. Then again, as late as the 1960s a programmable desk calculator could be quite valuable for plenty of serious uses.
- phire 5y agoThe reason why many 8 bit micros were derided as toys was not because of the 8bit cpu. 8bit cpus were well-respected. It was because of the crippling lack of ram and other cost-saving measures. Having 1KB of ram (or less) on a single board computer like the KIM-1 wasn't an issue, because they were programmed in machine-code and didn't need to drive a screen. But 1KB of ram on a low-cost microcomputer like the ZX80 was beyond painful. It takes 768 bytes for a full screen buffer, leaving just 384 bytes for the BASIC program, all it's variables and the interpreter state. And it took all the CPU time to drive the display. Actually running the program or even pressing a key would cause the screen to blank and desync. Even on better micros that had ~4KB of ram, the scope of the BASIC program you could write was pretty limited.
- monocasa 5y agoThe goal wasn't as much speed (it generated printed tables to be referenced later), but instead accuracy. The contemporary sources of such tables were rife with errors. Some by mistake, some added intentionally as a form of copy protection.
- nitwit005 5y ago> Anything less than 40 and you could more economically pay someone to calculate directly. Hiring someone to do the math would defeat the point. The idea was to eliminate human error when doing something like printing tables of common functions like sines or cosines. A lot of effort went into designing a printer, as they couldn't have humans recording the results without re-introducing human error.