Installer Steam
log på
|
sprog
简体中文 (forenklet kinesisk)
繁體中文 (traditionelt kinesisk)
日本語 (japansk)
한국어 (koreansk)
ไทย (thai)
Български (bulgarsk)
Čeština (tjekkisk)
Deutsch (tysk)
English (engelsk)
Español – España (spansk – Spanien)
Español – Latinoamérica (spansk – Latinamerika)
Ελληνικά (græsk)
Français (fransk)
Italiano (italiensk)
Bahasa indonesia (indonesisk)
Magyar (ungarsk)
Nederlands (hollandsk)
Norsk
Polski (polsk)
Português (portugisisk – Portugal)
Português – Brasil (portugisisk – Brasilien)
Română (rumænsk)
Русский (russisk)
Suomi (finsk)
Svenska (svensk)
Türkçe (tyrkisk)
Tiếng Việt (Vietnamesisk)
Українська (ukrainsk)
Rapporter et oversættelsesproblem
Idea: this relies on a lot of random coincidences that work out. The idea is, if the input is 10a+b (ignore 100 for now), then compute 15a+b by using `dgt 1` and `mul 5` to get `5a` and adding the original input again. Use 15a+b as the address inside a ROM.
If we reduce this mod 14, we get a+b. Thus, the data of the ROM can tell is if a+b is a multiple of 3. Unfortunately, sums in the range 0-4 could correspond to 0-4 or 14-18.
The way we can fix this is as follows: if the sum mod 14 is 0-4, then we should add 14 if and only if the original input was >= 50. If the input is < 50, then the max digit sum is 4 + 9 = 13, so there will never be overflow. If it is >= 50, then the digit sum is at least 5, so a result of 0-4 indicates overflow mod 14. Since the threshold (50) is exactly the threshold that the logic gates use to distinguish 0 and 1, we can fix the 14-18 issue using only logic gates (in particular, zero lines of code and zero extra power!).
Then I realized a + b = 10a + b - 9a , finally solved in 5/498/9.
Digital root calculation similar to @ebik's approach + lookup table
https://i.imgur.com/BdbYVmf.png
I used repeated conditional subtraction with an optimized gap sequence to get the input in the range 0-13, then used that as an address in a lookup table.