Replacing std.math raw pointer arithmetic with a union type
Simen Kjærås via Digitalmars-d
digitalmars-d at puremagic.com
Wed May 17 06:09:45 PDT 2017
On Wednesday, 17 May 2017 at 03:02:02 UTC, tsbockman wrote:
> std.math contains a lot of raw pointer arithmetic for accessing
> the various bit fields of floating-point values (see
> https://en.wikipedia.org/wiki/IEEE_754-1985). Much of this code
> has several nearly-identical copies, manually specialized for
> each supported floating-point format.
>
> Such code is verbose, hard to read, and, judging by the bugs
> and missing specializations I've found, hard to write
> correctly. It is also not compatible with CTFE.
>
> A while ago I created Phobos #4336
> (https://github.com/dlang/phobos/pull/4336), which begins the
> process of replacing all the pointer arithmetic in std.math,
> and the supporting floatTraits template, using a fast union
> type: RealRep.
>
> Ian Buclaw recently approved my work, but I believe that a pull
> request of this size and importance should be review by at
> least one other qualified person.
>
> Would any of our other floating-point experts be willing to
> take a look?
I had a look-see, and it certainly is more readable and less
error-prone than the incessant casting-to-pointer in the existing
implementation.
Having all the magic in one place makes a lot of sense, and if it
also brings performance benefits as your table indicates, all the
better. This should also make std.math more approachable to the
curious and make fixing bugs and implementing new functionality
easier, especially when supporting more than one format is
required.
On the topic of format support: the details of ibmExtended seems
to leak a lot - would it be possible to encapsulate that better?
I realize it's a weird format and some leakage may be
unavoidable, but currently it seems basically every function
you've converted contains a happy path dealing with every other
format, and a special case for ibmExtended.
All in all, this seems solid, and a great improvement over the
current state.
--
Simen
More information about the Digitalmars-d
mailing list