As someone pointed out what you really want here is c++ templates, those compile out completely and can be specialised for different types - which you need for speed.
-----Original Message----- From: music-dsp-boun...@music.columbia.edu [mailto:music-dsp-boun...@music.columbia.edu] On Behalf Of Sampo Syreeni Sent: 01 May 2013 23:08 To: A discussion list for music-related DSP Subject: Re: [music-dsp] basic trouble with signed and unsigned types On 2013-05-01, Bjorn Roche wrote: > Not sure I completely understand what you are after, but I think most > audio folks don't use types like int, long and short, but rather types > like int32_t from types.h (or sys/types.h). There are various > guarantees made about the sizes of those types that you can look up. Correct, and for now I'm doing something similar by calculating all of my widths, maximum values and whatnot beforehand into #defines. In the end I'd like an implementation that is fully parametrizable, though, and with as few adjustable parameters as at all possible. That's because while the idea I'm trying to put into code is primarily useful wrt audio, the basic framework of dithering I'm working within admits plenty of environments beyond *just* that. So, ideally, I'd want to make the code "just work", even within certain highly unusual environments. (Say, you receive a single bit integer type from the outside which you have to use to process your samples; there's way to go towards that but it might eventually happen. And, by the way, if you've ever done anything with DSD/SACD, treating the 1-bit channel as a modulo-linear one actually seems to make it too perfectly ditherable, breaking the Lipshitz and Vanderkooy critique. Thus, audio relevance even here. :) What I'm after is ways of reimplementing at least right shifts for unsigned quantities within standard C99, so that my new operator is fully portable and guaranteedly implements right shifts without sign extension, regardless of what integer type you use them on, and without any parametric polymorphism or reference to built-in constants describing your types at the meta level. There are bound to be other problems I have to worry about in the future, like how to deal with the possibility of one's complement arithmetic where I'm now taking parities. And whatnot. But at least the right shift would help me a lot right now. > Also, I assume you've given C++ templates and operator overloading > consideration. Yes. Immediately after I wanted to die. ;) -- Sampo Syreeni, aka decoy - de...@iki.fi, http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
