Hacker News Reader

Comment by addaon | Hacker News Reader

Unsigned integers are also, trivially, asymmetrical. Floats are symmetrical at the cost of redundant encodings. Fundamentally a binary representation of b bits can support 2^b values. 2^b is even, and any symmetric range that includes zero has an odd number of distinct values, so a binary representation must either be asymmetric, contain undefined values, or contain redundant encodings (e.g. negative zero).

View on HN

I once worked with a 16-bit processor that used two's complement with the convention — fortunately mostly just a convention — that 0x8000 was an undefined reserved value, rather than −32768. I say ‘fortunately’ because I was tasked with implementing C-style 16- and 32-bit arithmetic, where 0x8000 is perfectly reasonable as an unsigned value and perfectly reasonable as either half of a long. And ‘mostly’ because the hardware multiply instruction took two 16-bit signed operands and produced a 30 bit result.

Do you remember the name of that processor?

Yes, it was the Hamilton Sundstrand 1600.

> Hamilton Sundstrand 1600

Thank you.

The most beautiful way around this I've seen is the Posit number system. It's a floating point system that contains a single NaN which is the opposite of zero. https://posithub.org/

I'm a huge fan of this system, but it's worth pointing out that it doesn't have a single NaN, it has a single infinity with an undefined sign, modeling the projectively extended real numbers. NaN is a bit of an abomination; projective infinity is an uncommon beast, but one that can be worked with consistently. And yes, by pairing zero with infinity on opposite sides of the number ring, you get a symmetric system with no undefined or redundant encodings.

NaN is a feature of dynamically typed languages; otherwise they would not be able to represent all outcomes of implicit coercion.

And here I thought NaN was a definition from IEEE-754.

Yes, I'm not sure what parent means. Even java double has NaN.

NaN is a feature of IEEE floats to ensure that all arithmetic operations can always create a correct result. For example 0/0 has to evaluate to NaN, no other result would be mathematically correct. If there was no NaN the CPU would have to trigger a fault or return an incorrect result, both are undesirable.

So, today I learned something: the JavaScript critics are wrong at yet another thing.

It crops up more in JavaScript since it doesn't have integers, and if you try to convert non-numeric string to a number you get a NaN

Signed infinity is useful for limits, and also for initial values of some algorithms, so missing them seems like a disadvantage.

Also, it still has no total order, so keeps another messy part of IEEE floats

There's an easy alternative: just use the MAX and MIN values. That's what you would do with integers anyway, in case of initial values. As for limits, if you need to express limits in a datatype for expressing a small subset of rational numbers, you've got the wrong tool for the job.

> Also, it still has no total order

This is not true. It is defined to have the exact same ordering, bitwise, as two's complement integers. That means it has total order: the NaN is the most negative, then comes the negative numbers, then zero, and then positive numbers.

They used to call it "infinity with an undefined sign", then "NaR" for "Not a Real" but in the latest papers I've seen they just call it NaN. But that's just a name, it's the projective infinity as you say. I agree that the IEEE NaN is an abomination.

It still seems to be NaR here https://posithub.org/posit_standard4.12.pdf

Looks like there's no negative zero in posit, which is useful in some contexts .... https://en.wikipedia.org/wiki/Signed_zero

Yes, that's a feature. I regard negative zero as a misfeature in most contexts. There might be some, where it's useful, but a general purpose datatype shouldn't be optimized for niche use cases.

There is no a real number called "negative zero". For extremely small-magnitude negative values, posits have more to offer than IEEE floats without the abomination that is known as denormal numbers. And for limits approaching zero, using a datatype that is supposed to represent a subset of rational numbers is the wrong tool for the job.

I've always hated this fact with passion but it's like hating gravity. You can't fight it. Personally, I would have gone with one's compliment and a modified equality but that's just my OCD speaking.

It unfortunately makes all the hardware very messy, end around carry is not a pretty thing. You end up needing fiddly flagged prefix adders.

Further down the rabbit hole: https://en.wikipedia.org/wiki/Gray_code#Balanced_Gray_code Have yet to discover/work out an addition algo for balanced similar to Harold Lucal's algorithm https://stackoverflow.com/questions/20923165/gray-codes-addi...

Or just constrain the problem to support only [-2^N-1, 2^N-1].

This gets you an extra bit of precision when multiplying two signed numbers, because you no longer need to leave room for two sign bits in the product.

Two things I hate but can't fight:

Tetrahedra almost tessellate but don't quite do it: https://www.pnas.org/content/pnas/103/28/10612/F1.large.jpg

In music, the frequency ratio of a semitone is ideally 2^(1/12), but without some tiny fudging (called tuning), you can't make harmonies as the frequencies almost but don't quite line up right. I forget exactly how this one works so I may have something off.

“12 tone equal temperament” is a good string to Google if you want to learn about that. Most pianos are intentionally out of tune just enough that they’re good enough for every key.

Other coincidences that drive me wild: speed of light is almost but not quite 3.0E8m/s And the fine structure constant being almost but not exactly 1/137.

>speed of light is almost but not quite 3.0E8m/s

On that subject, if you decided to make your base unit of length the distance light travels in a nanosecond it'd almost be a foot but not quite.

I know that the speed of light is c, or 1 or 3e8 m/s, but I really feel like it's a foot per nanosecond, because that's how I measured it the lab one day messing around with BNC cables amd an oscillscope.

Similarly the earth-sun distance is 8 light-minutes.These feel right, like measuring mass in stone for people, kilos for sugar, carat for diamonds, electron-volts for particles etc.

Pianos are more complicated, because they also use stretched octaves that aren't just a simple 2:1 ratio, due to inharmonicity of the thick bass strings. There are only a few exceptions, where instead of thicker strings the piano was made really long.

12 tone equal temperament is all wrong, but never by much, and it is very convenient, so almost everyone uses it.

> In music, the frequency ratio of a semitone is ideally 2^(1/12), but without some tiny fudging (called tuning), you can't make harmonies as the frequencies almost but don't quite line up right

IIRC correctly, it's not just harmonies; the range of a piano is big enough that if you tune each octave exactly based on that ratio, you'll end up with the first and last octaves sounding off from each other.

If you tune with exact 2^(1/12) semitones then all your octaves will be in tune for obvious reasons. (And pianos are normally tuned this way, equal temperament, so I don't know what the grandparent is talking about; for any tuning system some intervals are just and others are not. Equal temperament gives you just octaves, Pythagorean tuning gives you just fifths, meantone temperaments give you just thirds).

> If you tune with exact 2^(1/12) semitones then all your octaves will be in tune for obvious reasons.

Hypothetically, or on an electronic instrument, you could. But if you did all 2^(1/12) ratios, your octaves wouldn't be in tune. Strings on a piano do not behave like an ideal string. Their overtones are not 2X, 3X, 4X, 5X, etc. times the fundamental frequency. Instead, the actual overtones are higher than the ideal frequencies. This is called inharmonicity (https://en.wikipedia.org/wiki/Inharmonicity).

So when tuning a piano, you have to tailor the way you tune it to each different piano if you want that piano's lower strings to be in tune with its higher strings.

> This is called inharmonicity

I think I've been hearing this for a long time but didn't realize it was real so questioned my perceptual system.

Thank you for the info!

Basically at the least you want to create exact frequency ratio of 3/2(major 5th) and 4/3(major 3rd). And also all the power and inverse power which is not achievable in one scale. Instead we substitute 3/2 = 1.5 to 2^(7/12) = 1.4983 and 4/3 = 1.3333 to be 2^(5/12) = 1.3348

There's a pretty big community of musicians who do away with almost all constraints wrt to tuning now.

Some of it, of course, sounds like cats screeching but some of it is genuinely astonishing.

For anybody wanting to hear this, look for "microtonal" music, or the artist Sevish is one that I know of.

It's more the opposite: equal temperment is a compromise that fudges but mostly preserves the important harmonies (thirds and fifths) in all keys.

If the maximum size of your number type is anywhere within 10x of your largest values you should definitely be using a larger number type. It’s just a way to write down a number. It’s like getting mad about the fact that negative numbers when written by hand require an extra character

> It’s like getting mad about the fact that negative numbers when written by hand require an extra character.

Now that you mention it, that convention does make me mad. Not because I have to write an extra character, but due to operations getting mixed-up based on implied context. For example:

Unary + is implicit: 3 = +3

Addition is written as juxtaposition: +2+5 = add(+2, +5) = +7. The first number can have an implicit sign, e.g. 2+5 = +2+5

"Subtraction" is a redundant operation; it's just addition involving a negative number: 8-3 = +8-3 = add(+8, -3) = +5.

The nice thing about this perspective is that subtraction commutes: +8-3 = -3+8.

What's annoying is that we also take juxtaposition to mean multiplication, and this flip-flops depending on implicit characters like unary '+'. For example:

    -8-3 = add(-8, -3)
    -8+3 = add(-8, +3)
    ab = multiply(a, b)
    2a = multiply(2, a)
    a2 = multiply(2, a)  (non-idiomatic)
    -2a = multiply(-2, a)
    a-2 = add(a, -2)

This isn't just a problem when mixing variables with literals, since juxtaposition of literals also means multiplication (as long as they parse to separate numbers), e.g. '13' is a two-digit number, but:

    (1)(3) = multiply(1, 3)
    (-1)(-3) = multiply(-1, -3)
    -1-3 = add(-1, -3)
    -1(-3) = multiply(-1, -3)
    (-1)-3 = add(-1, -3)

Note that we can do the same thing for multiplication and division, if we have a uniary reciprocal operator, e.g. ÷2 = 1/2. That way, division is just multiplication involving an inverse number, which commutes; e.g. 6÷2 = 6×÷2 = multiply(6, ÷2) = multiply(6, 1/2) = multiply(1/2, 6) = ÷2×6.

This seems weirder than the case of addition/subtraction, probably because we already have the horizontal-bar notation for division, which seems even nicer. Note that the "÷" character itself is simply an inline approximation of the horizontal-bar notation (with placeholders above and below); the "foo/bar" notation is a more direct inline approximation (no placeholders, just 'tipping' the bar). Interestingly we don't use "bar\foo" to mean the same thing.

Partial application of the binary grouping operators with the first operand implicit does not have to stop at division: https://news.ycombinator.com/item?id=25278021

I feel the same way - if computers happened to use base 3 instead of base 2 we could have fixed-width signed integers which are symmetric about zero.

> redundant encodings (e.g. negative zero).

But negative zero is not a redundant value. It behaves very differently from positive zero.

Does it? The only thing it does I am aware of that it does differently is decide between negative or positive infinity, which doesn't exist for integers.

Negative zero doesn't exist for integers either.

(Note also that -0 is an additive identity, and +0 isn't.)

> Note also that -0 is an additive identity, and +0 isn't.

Wait what

That's really confused me. Is this purely with reference to addition operations as defined in IEEE-754, or is there an underlying mathematical reasoning that makes it make sense?

In the underlying mathematics, the only additive identity is zero, which is neither positive nor negative. IEEE-754 has signed infinitesimals instead, so it can't follow that. You just have to pick one to be the identity, and they picked -0.

I assume the reasoning was that they would prefer values to be +0 when possible. Assigning the sum of -0 and +0 to be +0 instead of -0 means that -0 is the identity and +0 isn't.

Unless you're on a machine which uses one's complement or ign + magnitude, which C currently allows. Luckily, C is moving to make two's complement mandatory.

Floats still have an issue for this particular piece of code though! abs(-0) would return -0

IEEE754 specifies that abs(−0) is 0 (positive). (If your machine doesn't use IEEE754, I'd love to hear more about your project.)

Some coworkers had to deal with MIL-STD-1750A [0] floating point recently. None of us had ever heard of it. They were talking to some pretty old HW.

[0] https://en.wikipedia.org/wiki/MIL-STD-1750A

Wow, lot of famous spacecraft using that.

The commenter above you isn't talking about IEEE754's abs() function, but rather the code from the OP, except applied to floats rather than ints.

That code also has the same problem for one's complement and sign+magnitude, which are allowed encodings in C.

This is going away in the next version of the C standard. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2412.pdf

Oh, nice!

Floats could have had NaN occupy that encoding slot to balance against zero, but chose to instead add other complication and redundant encodings.

I wonder if negative zero is redundant or actually has some uses.

It is carrying data now, so I'm sure many programs use it.

Yes, it has uses. E.g., see Kahan's "Branch Cuts for Complex Elementary Functions, or Much Ado About Nothing's Sign Bit", copy available at

https://people.freebsd.org/~das/kahan86branch.pdf

(he gives an example regarding complex branch cuts and fluid dynamics applications.)

Reply on news.ycombinator.com