[L2Ork-dev] PD_BIGORSMALL

[Matt Barber]

Best to use int32_t etc. from stdint.h when size is necessary

On Sun, May 13, 2018, 1:16 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

> Hi list,
>
> Ok, I'm delving into IEEE 754 a bit more, and I want to
> get a handle on the m_pd.h public interface changes before
> delving too much deeper into the double-precision project.
>
> Here's our recent code change that Pranay ported from
> pd-double to check for subnormals (a.k.a. denormals), nans,
> and some other desiderata:
>
>
> https://git.purrdata.net/jwilkes/purr-data/commit/d0d6b54deb1b803c67d85bd5d123d3da98faf495
>
> So basically we've replaced the old direct type-punning code
> with a union. From what I can tell, there are two benefits to
> the new approach:
>
> * we can error out on strict aliasing violations
> and thus ensure that no such violations accidentally get
> added in *other* parts of the code (where, unlike this macro,
> they likely would be bugs).
>
> * we can just do a comparison on the 2nd array element
> for double-precision
>
> However, we could still get silently borked for the following
> three cases:
>
> * systems where sizeof(int) != sizeof(float) for single-precision Purr Data
>
> * systems where sizeof(int) * 2 != sizeof(double) for double-precision Purr
> Data
>
> * big endian CPUs
>
> Should we add a preprocessor check for the type sizes and
> error out if they don't meet our assumptions?
>
> As far as big endian, I don't see anything in the way of
> consumer CPUs (and RISCV is apparently littleendian).
>
> Finally-- it appears that there is no issubnormal in
> math.h. Anyone have a clue why that is?
>
> -Jonathan
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20180513/85e0354f/attachment.html>