Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In the title, read "and" as "plus". (For a while I thought they meant "logical AND", given the HN context.)


Yeah, I wrote "+" but HN turned it to "and".


Just for fun, what if it is read as AND: that is, bitwise AND?

x/(y&z) & y/(x&z) & z/(x&y) = 4.

If the / becomes integer (flooring) division, there are many solutions, such as (6, 13, 19).

But if the division results are required to actually be integers, there are no small solutions - at least, none where x, y, and z <= 10000 (checked by brute force with minor optimization). I suspect that unlike the original problem, there are actually no solutions, but it’s just a guess. Anyone want to come up with a proof? :)


Let's consider the lexicographically smallest triplet (x, y, z) such that:

x/(y&z) & y/(x&z) & z/(x&y) is even

That means that x/(y&z) is even, or y/(x&z) is even, or z/(x&y) is even.

If x/(y&z) is even, then x is even too, so x&z is even, so y is even (otherwise y/(x&z) wouldn't be integer).

Similarly, we can conclude that all x, y, z are even.

But if we substitute x=x/2, y=y/2, z=z/2, the value of x/(y&z) & y/(x&z) & z/(x&y) doesn't change.

So the (x, y, z) triplet we considered wasn't the smallest. Contradiction.


Makes sense. Nice proof :)


It might be fun and surprising to come up with seemingly unsolveable problems in math, but it isn't actually that hard. Especially if you come from the angle of computer science. Math does not have common tools I'm aware of to deal with many of those problems.

Bitwise AND is not a linear function, which is a first obstacle.


For bitwise and you have to be solving it in a Galois field (And consider what AND does) which is actually easier than the general solution but points you more accurately at the cryptographic origin of the question.


Sorry, that's the rare case where we actually want +. Fixed above.


Why does that have to be the rare case? What's the common case of using "+" that you're trying to avoid?


"Microsoft + Apple will both.." I imagine people use + to get by character limit in the title.


>I imagine people use + to get by character limit in the title.

What's wrong with that? The same phenomenon occurs on Twitter - people find a way to optimize every character.

Isn't an 80 character limit for titles on a modern web forum really the problem?


They should just get their threads removed then. There is no reason to silently apply that weird behaviour instead.

In fact, I would expect this to be quite rare as most people would probably use & instead.


For future reference, when someone really wants a plus sign would using Unicode FF0B (full width plus) get past the automatic "and" conversion?


We started stripping out a bunch of character ranges a few years ago because people were using them to play Unicode games in HN titles and the idea here is plain text. But I'm not sure in that case. You could test it if you wanted.


I tried it and it works. U+FF0B gives a plus sign when used in an HN title. It's a fair bit wider than normal, so may look a little off but not as off as "and". Here's a line of 10 U+FF0B's and a line of 10 +'s for comparison:

++++++++++

++++++++++




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: