Hacker News Reader

Comment by theamk | Hacker News Reader

This may be good for numerical simulation, but I doubt this will ever replace common ieee754 float in general purpose programs. Two problems I can see right away:

- Sometimes, one needs precision for numbers not close to 1. A UNIX timestamp is a good example -- for the current date, it provides ~1uS resolution in 64-bit ieee754. I could not calculate what the resolution would be for posits, but I suspect much worse.

- The lack of positive and negative infinites will break naive min/max calculations which start accumulator with +/-inf.

Now, you might say that those things should not be done, and that software that uses those patters is defective. But even then, there is a lot of software like this, and so posits will never become a default "float" type.

View on HN

UNIX timestamps are normally stored as 32-bit or 64-bit signed integers, not as floating-point. If you want better than 1-second precision, then the type "struct timespec" (specified by POSIX) gives you nanosecond precision. Fixed-point types can also be used in languages that support them.

I thought unsigned in 64 bits, holding the number of nanoseconds since the Unix 0 time (which might be 1970, but i forget).

time_t is usually signed.

UNIX time is seconds since epoch (hence year 2038, that's the limit for a signed 32b time_t).

gettimeofday() and clock_gettime() provide higher resolution timestamps (respectively µs and ns), using typedefs instead of just numbers.

Some APIs return floating-point UNIX time in order to provide sub-second accuracy (the decimal part is the fractional second). Python's time.time() does that for instance.

It’s a signed type so dates before 1970 can be represented

Yeah, timespec (or time_interval) is a proper way to go, but it is quite a pain to work with -- you need a library even if you just want to subtract the numbers.

On the other hand, floating-point time is pretty common in scripting languages -- for example Python has time.time(); ruby has Time.now.to_f. It is not perfect, but great for smaller scripts: fool proof (except for the precision loss), roundtrips via any serialization format, and easy to understand. And no timezone problems at all!

> will break naive min/max calculations which start accumulator with +/-inf.

Wouldn't the equivalent pattern just be to start at +/- typemax(Posit) or whatever? As you would for integers, which lack infinity.

I think this person is saying that it should break existing code not the pattern.

The solution seems simple to me though. Whatever syntax programmers are using to initialize floats to +/-inf, make that ensure to posit min and max as well.

I read "drop-in" as dropped in to new code. Certainly this could never be dropped in transparently at an OS or processor level. As long as the change is opt-in, neither of the things you mention are problems. I think a new world where programmers don't have to be aware of negative zeros, etc, would be appealing to a lot of people.

Reply on news.ycombinator.com