On 07/30/2013 08:51 PM, Gregory Warnes wrote:
> How about enclosing the bit-for-bit tests in
> #ifdef IEEE754_Compliant
> ...
> #endif
Merely knowing that a platform conforms to IEEE 754 is not sufficient to
guarantee bit-for-bit compatibility. The order of operations also
matters, and compliers
O
I've looked around a little bit and teh interwebs say, "never test
floating point for equality", which is the way we are headed here.
Aside from NEON not being fully IEEE 754 compliant as Doug mentioned,
it looks like x86 (this statement not true for x86_64) has excess
precision inside the flo
> But there, I guess exceptions, and this is one case where doing a QA test
> that is
> looking for bit-of-bit identical patterns would be just wrong.
How about enclosing the bit-for-bit tests in
#ifdef IEEE754_Compliant
...
#endif
And adding appropriate definitions for the various platform
On Tue, Jul 30, 2013 at 6:43 PM, Marcus D. Leech wrote:
> On 07/30/2013 05:55 PM, Tom Rondeau wrote:
>>
>>
>> So codec2 shouldn't be using Volk, but if it's using some other SIMD
>> code itself, that could be a problem.
>>
>> The problem with just turning off a QA test because it fails is that
>>
On 07/30/2013 05:55 PM, Tom Rondeau wrote:
So codec2 shouldn't be using Volk, but if it's using some other SIMD
code itself, that could be a problem.
The problem with just turning off a QA test because it fails is that
we're now just hiding a potential problem. I'd rather understand the
problem
On 07/30/2013 06:03 PM, Douglas Geiger wrote:
Marcus,
(Forgive my ignoring the context of the parent discussion to answer
your question):
I can tell you that in the case of ARM at least NEON instructions are
is *not* IEEE-754 compliant. One optimization in particular that I can
recall of
On Tue, Jul 30, 2013 at 3:41 PM, Marcus D. Leech wrote:
> On 07/30/2013 03:35 PM, Kristoff Bonne wrote:
>
>> Tom,
>>
>>
>> (inline comments)
>>
>>
>> My understanding was that all IEEE floating-point implementations
> followed the same rounding rules, etc? Is that not the case?
>
> Are the SIMD
On Tue, Jul 30, 2013 at 4:47 PM, Kristoff Bonne wrote:
> Marcus,
>
> (repost due to technical problems. My appolologies for a possible double
> post).
>
>
>
> On 30-07-13 21:41, Marcus D. Leech wrote:
>>
>> On 07/30/2013 03:35 PM, Kristoff Bonne wrote:
>>>
>>> Tom,
>>>
>>>
>>> (inline comments)
>>
Marcus,
On 30-07-13 21:41, Marcus D. Leech wrote:
On 07/30/2013 03:35 PM, Kristoff Bonne wrote:
Tom,
(inline comments)
My understanding was that all IEEE floating-point implementations
followed the same rounding rules, etc? Is that not the case?
Are the SIMD subsystems not IEEE compl
Marcus,
(repost due to technical problems. My appolologies for a possible double
post).
On 30-07-13 21:41, Marcus D. Leech wrote:
On 07/30/2013 03:35 PM, Kristoff Bonne wrote:
Tom,
(inline comments)
My understanding was that all IEEE floating-point implementations
followed the same r
On 07/30/2013 03:35 PM, Kristoff Bonne wrote:
Tom,
(inline comments)
My understanding was that all IEEE floating-point implementations
followed the same rounding rules, etc? Is that not the case?
Are the SIMD subsystems not IEEE compliant, for performance reasons?
--
Marcus Leech
Prin
Tom,
(inline comments)
On 30-07-13 15:53, Tom Rondeau wrote:
The codec2 needs a bit of attention. I've not known it to fail like
this (and that's a very close result you're seeing), but we need to
update the version of codec2 that we're using. So unless you really
wanted to use codec2 with
On Mon, Jul 29, 2013 at 7:26 PM, Kristoff Bonne wrote:
> Tom,
>
>
> (inline comments)
>
>
>
> On 29-07-13 17:01, Tom Rondeau wrote:
>>
>> On Mon, Jul 29, 2013 at 5:48 AM, Kristoff Bonne
>> wrote:
>>>
>>>
Just found this, it might help:
https://github.com/dl1ksv/gr-afsk
>>>
>>> Hmmm. Look
Tom,
(inline comments)
On 29-07-13 17:01, Tom Rondeau wrote:
On Mon, Jul 29, 2013 at 5:48 AM, Kristoff Bonne wrote:
Just found this, it might help:
https://github.com/dl1ksv/gr-afsk
Hmmm. Looks interesting. A good start. :-)
However, it seams I have another problem: it does not build o
On Mon, Jul 29, 2013 at 5:48 AM, Kristoff Bonne wrote:
> Hallo Marcus,
>
>
>
>
> On 29-07-13 01:44, Marcus D. Leech wrote:
>>
>>
>>> - My first step with GNUradio was to learn a bit more about using it;
>>> so .. do some test.
>>> I wanted to use GNUradio to determine the width of an AFSK signal;
Hallo Marcus,
On 29-07-13 01:44, Marcus D. Leech wrote:
- My first step with GNUradio was to learn a bit more about using it;
so .. do some test.
I wanted to use GNUradio to determine the width of an AFSK signal; so
I started looking for a AFSK modulator / demodulator; to come to the
conclus
On 07/28/2013 07:35 PM, Kristoff Bonne wrote:
Hi,
I'm still very new to GNUradio, so please excuse my (perhaps dump)
question. I did look around at different places at the web but did not
really find an answer:
- My first step with GNUradio was to learn a bit more about using it;
so .. do
17 matches
Mail list logo
