Re: Parsing timestamps?

Paul Rubin <no.email@nospam.invalid> writes:

I guess though, given the
continued attention they get, they must be more interesting than I had
thought.

IMO it's the usual case of a somewhat complex topic where existing
solutions have undesirable properties, and someone promises a solution
that supposedly solves these problems.  The attention comes from the
problems, not from the merits of the promised solution.

There has been attention given to research into the philosopher's
stone for many centuries; I don't think that makes it interesting
other than as an example of how people fall for promises.

I saw one of the posit articles criticizing IEEE 754 because IEEE 754
addition is not always associative.  But that is inherent in how
floating point arithmetic works, and I don't see how posit addition can
avoid it.

If you only added posits of a given width, you couldn't.  Therefore
the posit specification also defines quire<n> types, which are
fixed-point numbers that can represent all the values of the posit<n>
types plus additional bits such that a sequence of a lot of additions
does not overflow.  If you add the posits using a quire as
accumulator, and only then convert back to a posit, the whole thing is
associative.

Of course you could also introduce a fixed-point accumulator for
traditional FP numbers and get the same benefit without using posits
for the rest.

A problem is how these accumulator types are represented in
programming languages.  If somebody writes

0e n 0 ?do a i th f@ f+ loop x f!

should the 0e be stored in the accumulator, and F+ be translated to an
addition to the accumulator, and should the F! then convert the
accumulator to FP?  What about

0e x f! n 0 ?do x f@ a i th f@ f+ x f! loop

In Forth I would make the accumulator explicit, with separate
FP-to-accumulator addition operations and explicit accumulator-to-fp
conversion, but I expect that many people (across programming
languages) would prefer an automatic approach that works with existing
source code.  We see that with auto-vectorization.

How big would the accumulator be?  Looking at
<https://en.wikipedia.org/wiki/Unum_(number_format)#Quire>, for
posit32 (the largest format given on the page) the quire32 type would
have 512 bits, and would allow adding up of 2^151 posit32 numbers.

Let's see how big an accumulator for binary32 would have to be: There
are exponents for finite numbers from -126..127, i.e., 254 finite
exponent values, and 23 mantissa bits, plus the sign bit, so every
binary32 number can be represented as a 278-bit fixed-point number
(with scale factor 2^-149).  If you want to also allow intermediate
results of, say, 2^64 additions (good for 97 years of additions at 6G
additions per second), that increases the accumulator to 342 bits; but
note that the bigger numbers can only be represented as infinity in
binary32.

- anton
--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/