Negative Base
en.wikipedia.org
en.wikipedia.org
However, I was always willing to answer nontrivial questions, and even convert numbers to/from negabinary to help them. (The program used the Schroeppel2 implementation, to prevent them from getting too much of a clue if they somehow managed to find its source code)
I'm not sure those would be enough, but just inspecting the digit-wise patterns would get you pretty far. Correctly interpreting the sequence is far harder!
Interestingly, normal binary has the same pattern, but with different offsets for the start of the sequence.
https://oeis.org/search?q=1%2C+6%2C+7%2C+4%2C+5%2C+26%2C+27&...
* https://en.wikipedia.org/w/index.php?title=-0&diff=25603603&...
* https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletio...
Although it smells like a design flaw (which negabinary conveniently doesn't have)
The only way to tell them apart in general is to divide by them. In some languages you might be able to type-pun and examine the bit pattern, or do things like Object.is() or whatnot.
> 1/(-0)
-Infinity
> 1/0
Infinity
> Object.is(0, -0)
false
Of course = doesn't actually test equality in javascript. == reports -0 as being equal to +0, but Object.is reports them as different."You have 12 coins that all look exactly the same. One is counterfeit and is either heavier or lighter than the other 11. With a balance beam scale, isolate the counterfeit coin in three moves."
Any uses for Negative-base systems?
EDIT: According to
> https://en.wikipedia.org/w/index.php?title=Balance_puzzle&ol...
if you know that one coin is different from the others, with 3 weighings, you can even detect it among 13 coins (not just 12).
ABC, one of them is different weight than the other two (either more or less)
Possible ways to weigh them:
A v B
A not enough information
E C is odd one out
B not enough information
A v C
A not enough information
E B is odd one out
C not enough information
B v C
B not enough information
E A is odd one out
C not enough information
AB v C
AB not enough information
E C is odd one out
C C is odd one out
AC v B
AC not enough information
E B is odd one out
B B is odd one out
BC v A
BC not enough information
E A is odd one out
A A is odd one out
In all possible ways to weight 3 coins, all have uncertainty which means you cannot deduce which is the odd one out.It's easier than the 12-coin one different puzzle, but introduces the ternary concept well enough to get you started on the harder problem (there are some other complications to it as well).
Weigh 2 coins. If the scales move you've found the lighter coin. If the scales balance, it's the third coin you didn't weigh.
So I think it goes like this:
- you have 12 coins, and each one has an equal chance of being heavier or lighter than the others - so that's 24 possiblities
- you have 3 moves, and the result of each move could be one side of the beam goes down, one side goes up, or it balances. That means you can create a system that identifies 3^3 = 27 outcomes. So far so good.
- you need each of your outcomes to provide real information. if it was a binary problem that means you're not really getting any information if the beam balances
(bit sketchy on that last point, maybe someone can help with that)
Wrong. If it was true, that would imply that the probability of it balancing is 1, since the information you get is -log2(probability). Obviously the probability of it balancing is lower than 1, so you do get information.
It is a kind of search problem, but the steps aren't recursive and you have to use several tricks to maximize the information you get out of each measurement.
This is because there are 3 possible scenarios:
1. the biased coin is on the right side of the scale,
2. the biased coin is on the left side of the scale,
3. or the biased coin is the coin not measured (since the scale is balanced).
In essence, even though this scale only has 2 sides, you gain information proportional to having 3 sides.
Hence if we were to extend this to a scenario where you had n coins, of which one was biased and others fair, you would only need log_3 n measurements total to find the biased coin.
This idea has pretty neat applications. For example, if you wanted to prove that merge sort has a O(n log n) computational complexity, you can use this scale idea.
Move 1: weigh 6 coins vs 6 coins. Isolate the heavier set for the next move. Move 2: weigh 3 coins vs 3 coins. Isolate the heavier set for the next move. Move 3: weigh any two of the 3 remaining coins. If one is heavier, that is the counterfeit. Otherwise (if coins are equal in weight) the remaining coin is counterfeit.
> One is counterfeit and is either heavier or lighter
It turned out the counterfeit was lighter and you discarded it after the first weighing.
This was a fun one to work out on paper though.
I think the ideal wikipedia page for this kind of thing has a 'Properties' section from which to start thinking about this
So this may eventually find a use, likely with higher-dimensional math.
Highly unlikely, but fun to think about.
Actually, another neat example is analog vs digital computation. your models can get very different answers. I recall some Mandelbrot guy talking about that.
https://en.m.wikipedia.org/wiki/Fundamental_theorem_of_algeb...
The first use of negative roots was to find the (real) roots of certain polynomials. They were considered a mathemathical hack: useful, but specious on their own. And then it turned out that if you take them on their own terms, they're fantastically useful.
So there's no possible way this could be useful for "higher dimensional math" or anything, because there's no entity being added here. Higher dimensional math already uses numbers. At most there might be one or two concepts that might in some manner if you squint hard enough could be better represented by negative base numbers, but even then the positive base representation would probably still be how people actually understood it.
That's what I was thinking.
Different representations of the same thing are not useless; one might make an argument (which I can only back up off the top of my head with mathematical examples, but I suspect that there are also many in the physical sciences) that they are at the root of much progress. The canonical example is to try to do positive-integer arithmetic with Arabic versus Roman numerals; they represent exactly the same thing, but I'll bet you can compute 16 ⨉ 17, but not XVI ⨉ XXIII (without converting), in your head.
XVI ⨉ XXIII
= XVI ⨉ (XVI + I)
= (XVI ⨉ XVI) + XVI
= CCLVI + XVI
= CCLXXIINote that your calculation for some reason (EDIT: ah, maybe because my Arabic-numeral problem has 16 ⨉ 17?) replaces XXIII = 23 by XVII = 17, and then black-boxes the calculation XVI ⨉ XVI = CCLVI (which I at least wouldn't know without converting).
1 6
1 1 6
7 7 42
1, 6+7, 42 = 100 + 130 + 42 = 272
Same process in Roman X V I
X C L X
X C L X
I X V I
I X V I
I X V I
CC LL(=C) XXXXX(=L) VVV(=XV) III = CCCLXVIII = 16*23=368
This supports the arguments that Arabic numbers really are better suited for things like multiplying. They don't have the property that multiplication is convolution, so you can't even do things like truncate your computation to get an approximation.There's probably a way to formalize this with an entropy argument: that roman numerals are inefficient encoding. Because given some n-length string of numerals, firstly many are invalid encodings, and secondly among the valid numerals there isn't a uniform distribution from strings to integers. Something like that.
Although it's in some sense the same algorithm, the Roman-numeral version requires far more memorisation. For example, once I know that 2 ⨉ 3 = 6, I know without further memorisation (or, rather, with only a meta-memorisation that generalises readily to other contexts) that 20 ⨉ 30 = 600; but, even once I know that II ⨉ III = VI, I have to memorise separately that XX ⨉ XXX = DC.
> This supports the arguments that Arabic numbers really are better suited for things like multiplying. They don't have the property that multiplication is convolution
I think "They" here is "Roman numerals", not (as the structure seems to suggest) "Arabic numerals", right?
- Obfuscation.
- Storing signed numbers in unsigned fields (nah, not really).
― Aldous Huxley
i^1 = i
i^2 = -1
i^3 = -i
i^4 = 1