Quadibloc

Also the slide rule section on John Savard's home page http://quadibloc.com/math/slrint.htm. There is a mention of the K&E KE-LON slide rule which they prototyped, but never manufactured due to the availability of the pocket scientific calculator at that time. But I would still love to see someone make a replica of the KE-LON (or KeLon, however it was to be spelled), see the prototype picture here: https://www.mccoys-kecatalogs.com/KECollection/KeLon/keLon.htm. Of particular interest is the Constants scale at the top of the back side.

"Editors are meant to be customized to your workflow and what works best for you." Sure, but if you do it too soon, all tutorials and howtos will be a pain to follow. Comfort is important. How are you using your F1-F12 keys? Also, if you have a whole bunch of bindings you may want to use a 24-function-key keyboard for IBM's (like http://www.quadibloc.com/comp/images/122hc.gif or http://www.nlynx.co.uk/products/keyboard.aspx) or a Sun Type-7 Unix lay-out (the one with special keys for your left pinky) may help.

I believe that small changes like this can make ciphers more secure in practice but are usually best avoided. The are several factors involved. * Modern ciphers are carefully designed and random changes to the algorithm may weaken the cipher, by say shrinking the effective key space or leaking internal state information due to timing attacks. Without careful cryptographic analysis by experts, motivated to study the new changes over a period of months or years, it may be hard to anticipate the overall effect of the changes. This in an argument in favor of adopting the existing studied systems and implementations. * Some types of changes can be safely made and may be worthwhile. For example, superencipherment by encrypting the output of one cipher with a different independent system and an independent second key is almost certainly going to make breaking the system harder. This, however, reduces the performance of the encryption and requires careful implementation for perhaps no gain over simply choosing stronger parameters (for example, rounds and key length) with a single system. Examples of superencipherment that have been successful include the system used by soviet agents known as the VIC cipher. Apparently, this cipher resisted attempts at decryption. (The VIC cipher combined two simpler ciphers a franctionated substitution followed by an interrupted columnar transposition. There was a nice explanation of this cipher in Scientific American that I read in the mid…

Selectric typewriters made something that looked more like print than the typical typewriter. The Selectric type ball mechanism made multiple rapid impressions, producing a crisp dark letter, and the high end models had proportional typefaces. The Composer could even do justification. An example of Selectric Composer output: http://www.quadibloc.com/comp/images/ps_sco2.jpg

Interesting discussion on shapes of other dice, including a 200 sided one: http://www.quadibloc.com/other/bo2122.htm

The linked article doesn't mention that the SSEC's modifiable-program nature is debated, since it normally read instructions from paper tape. It did have a small (150 word) relay store from which it could also read instructions (so I personally think it counts). http://www.quadibloc.com/comp/cp04.htm#ssec http://www.columbia.edu/cu/computinghistory/ssec.html

As done in Checkers: http://www.quadibloc.com/other/bo010201.htm & how TCEC (Top Chess Engine Championship) runs

To be fair, he has a newer main page: http://www.quadibloc.com/main.htm and there are really some nice articles. And he has an even older site: http://friedo.szm.com/krypto/JS/home.ecn.ab.ca/~jsavard/frhome.htm

EBCDIC seems elegant in its own way: http://www.quadibloc.com/comp/cardint.htm (scroll down) -- apparently it's descended from IBM punch card formats. The discontinuity in the alphabet seems inconvenient for sorting, but it looks like it shares some properties (like bit-flip to make lower case) with ASCII.

But surely there are tools to remap X-language physical keyboard codes to the US layout? Here's diagrams of the mappings. https://www.terena.org/activities/multiling/ml-mua/test/kbd-all.html And here's usbkbd (note scancodes at the top): http://lxr.free-electrons.com/source/drivers/hid/usbhid/usbkbd.c Explanation on scancodes, which map to which keys for different physical boards: http://www.quadibloc.com/comp/scan.htm

IEEE 754 basically had three major proposals that were considered for standardization. There was the "KCS draft" (Kahan, Coonen, Stone), which was the draft implemented for the x87 coprocessor. There was DEC's counter proposal (aka the PS draft, for Payne and Strecker), and HP's counter proposal (aka, the FW draft for Fraley and Walther). Ultimately, it was the KCS draft that won out and become what we now know as IEEE 754. One of the striking things, though, is just how radically different KCS was. By the time IEEE 754 forms, there is a basic commonality of how floating-point numbers work. Most systems have a single-precision and double-precision form, and many have an additional extended-precision form. These formats are usually radix-2, with a sign bit, a biased exponent, and an integer mantissa, and several implementations had hit on the implicit integer bit representation. (See http://www.quadibloc.com/comp/cp0201.htm for a tour of several pre-IEEE 754 floating-point formats). What KCS did that was really new was add denormals, and this was very controversial. I also think that support for infinities was introduced with KCS, although there were more precedents for the existence of NaN-like values. I'm also pretty sure that sticky bits as opposed to trapping for exceptions was considered innovative. (See, e.g., https://ethw-images.s3.us-east-va.perf.cloud.ovh.us/ieee/f/fb/Analysis… for a discussion of the differences between the early drafts.) Now,…

Modern day vaccum tube hobby take on 8 bit ascii from unabstracted signal procesing point of view (pre-type punning): 1920's-1950's were initially reusing prior experience/knowledge of each punch card card hole as an individual electric on/off switch [1], Electronic relays required 4 electrical inputs [2](flow control/reset done per 'end of current row hole punches) 10 holes per line -> 3 relays!; 8 holes per line -> 2 relays, where each relay deals with 4 bits. Switching away from physical punch card media to electric/audio, 7holes per line, with extra bit for indicating 'done' with current set of row holes. 8 holes per line needed 'software support' or make use of the hardware for 3rd relay (formerly need for 10 holes in a line) Numbers faster because with 6 bits, don't need 3rd relay to do flow control. Wonder if the pairing of binary sequence with graphic glyp could be considered to be the origin of the closure concept. modern day abstractions based on '4 wire relay' concept: tcp/ip twisted pair usb prior to 3.2 vs. usb 3.2 variable lane width epci fixed lane vs. latest epci spec with variable width lane ----- [1] : http://quadibloc.com/comp/cardint.htm [2] : https://en.wikipedia.org/wiki/Vacuum_tube

DO visit quadibloc's color page, http://www.quadibloc.com/other/colint.htm It is one of those pages that has been around forever and keeps getting better. I was glad to discover it years ago (it had a grey background then, how old does that make me?) and its intriguing re-organizations of the author's own 240 hue color wheel loosely based on the Munsell system, http://www.quadibloc.com/other/images/240ccf.gif that is a mighty fine hue base for a color picker. It embodies the author's human perception of color. For example -- compared to raw RGBspace, the massive area of green is relegated to a smaller area, and the small area of violet is expanded. Also the space between red/yellow is expansive enough that once you branch off these hues into tangents of lightness and saturation, you can pick better flesh tones, more vibrant pastels, and fewer 'muck-yuck' tones such as the ones you get most often when you poke randomly into RGB space.

In addition to that list, there are the physical issues of film and optical devices. CGI can just work around them, but with film and lenses, physics still gets yah. For reference (http://www.quadibloc.com/science/opt0505.htm) the first order optical issues with all systems are: > Spherical Aberration: this is the aberration affecting rays from a point on the optical axis; because rays from this point going out in different directions pass through different parts of the lens, then, if the lens is spherical, or otherwise not the exact shape needed to bring them all to a focus, then these rays will not all be focused at the same point on the other side of the lens. Essentially, lenses are spherical, they need to be parabolic but that is very expensive. > Coma: this aberration affects rays from points off the optical axis. If spherical aberration is eliminated, different parts of the lens bring rays from the axis to the same focus. But the place where the image of an off-axis point is formed may still change when different parts of the lens are considered. Essentially, your lens may not be flat compared to the film. > Astigmatism: this is another aberration affecting rays from a point off the optical axis. These rays, as they head through the lens to the point in the image where they will be focused, pass through a lens that is, from their perspective, tilted. Even if neither spherical aberration nor coma prevents them from coming to a sharp focus, if we consider the rays of…

From what I understand, the Feb 23rd SHA-1 attack was possible because they figured out how to get the internal state (160 bits or 5 words of 32 bits) to match from two separate pieces of data. After that, additional data could be appended to the first two pieces as long as it was identical. The internal state would play back the same sequence from there on, just like two random number generators starting from the same seed. Here is a comparison of internal state sizes: https://en.wikipedia.org/wiki/SHA-0#Comparison_of_SHA_functions SHA-256 is susceptible to this same flaw, it would just take longer because it has about about 128 bits of security instead of less than 80 for SHA-1. It looks like only SHA-3 really "gets it" with a 1600 bit state size. After all of the effort put into making highly pseudo-random hash functions, it's a wonder that the state size was only the size of the hash. By comparison, Mersenne Twister's state size is 19937 bits (624 words of 32 bits minus 31 bits): http://www.quadibloc.com/crypto/co4814.htm Does anyone know why hash algorithms keep using such small state sizes, leaving us vulnerable to this same issue?

http://homepage.cs.uiowa.edu/~jones/cards/history.html "The use of punched cards in the Jacquard loom influenced Charles Babbage, who decided to use punched cards to control the sequence of computations in his proposed analytical engine. Unlike Hollerith's cards of 50 years later, which were handled in decks like playing cards, Babbage's punched cards were to be strung together like Jaquard's. Despite this and the fact that he never actually built an analytical engine, Babbage's proposed use of cards played a crucial role in later years, providing a precident that prevented Hollerith's company (and its successors) from claiming patent rights on the very idea of storing data on punched cards." http://www.adbranch.com/how-ibm-helped-automate-the-nazi-death-machine… http://www.scrapbookpages.com/AuschwitzScrapbook/History/Articles/IBMp… "Auschwitz historians were originally convinced that there were no machines at Auschwitz, that all the prisoner documents were processed at a remote location, primarily because they could find no trace of the equipment in the area. They even speculated that the stamped forms from Auschwitz III were actually punched at the massive Hollerith service at Mauthausen concentration camp. Indeed, even the Farben Hollerith documents had been identified some time ago at Auschwitz, but were not understood as IBM printouts. That is, not until the Hollerith Büro itself was discovered. Archivists only found the Büro because it was listed in…