<br><br><div class="gmail_quote">On Wed, Jul 13, 2011 at 7:38 PM, IOhannes m zmoelnig <span dir="ltr"><<a href="mailto:zmoelnig@iem.at">zmoelnig@iem.at</a>></span> wrote:</div><div class="gmail_quote"><br></div><div class="gmail_quote">
<br></div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">>> i think this is the main showstopper right now.<br>>> the type punning tricks used to be crucial (i assume), but nowadays the<br>
>> speed gain should be rather low (at least according to some tests we did).</span><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br></span></div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">A double precision Pd is high on my wishlist, and if the union tabfudge thing is the main showstopper, then it's certainly worthwhile to put effort in it. I'm often running into precision issues with Pd, not only by lack of an integer type for indexes but also in the case of signal data. In some cases I write a new external instead of a patch for this reason, which is a pity. I'll do as you say, first write and test a generic alternative with straightforward implementation, then try to optimize. </span></div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br></span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Katja</span></div>