On Sat, 24 Nov 2018 14:19:01 +0100
Fons Adriaensen wrote:
>On Sat, Nov 24, 2018 at 10:49:46AM +, Will Godfrey wrote:
>
>> >The safe way is of course:
>> >
>> >int i = (int) floorf (p);
>> >float f = p - i;
>
>> I'd been mulling over *exactly* that point for some time. My reasoning being
On Sat, Nov 24, 2018 at 10:49:46AM +, Will Godfrey wrote:
> >The safe way is of course:
> >
> >int i = (int) floorf (p);
> >float f = p - i;
> I'd been mulling over *exactly* that point for some time. My reasoning being
> that in the latter case, if the integer was slightly wrong then using
On Sat, 24 Nov 2018 11:14:06 +0100
Fons Adriaensen wrote:
>The dangerous thing to do is:
>
>// given float p
>
>int i = (int) floorf (p);
>float f = fmodf (p, 1.0f);
>
>as you could end up with i + f != p.
>
>The safe way is of course:
>
>int i = (int) floorf (p);
>float f = p - i;
>
>
>Ciao,
>
On Thu, Nov 22, 2018 at 11:29:11PM +0100, Robin Gareus wrote:
> A simpler example to show this is
>
> #include
> #include
> int main (int argc, char** argv) {
> float a = 0;
> for (int i = 0; i < 100; ++i) {
> a += 0.1f;
> a -= 0.05f;
> a = fmodf (a, 1.f);
> }
> printf
Am 22.11.18 um 22:41 schrieb Fons Adriaensen:
On Thu, Nov 22, 2018 at 09:27:58PM +0100, Hermann Meyer wrote:
In guitarix nearly all DSP is generated by FAUST.
That doesn't make any difference for numerical stability.
This is a property of an algorithm, not of the language.
Ciao,
Just as
On 11/23/2018 09:18 AM, Gordonjcp wrote:
On Fri, Nov 23, 2018 at 02:09:02PM +0100, Robin Gareus wrote:
On 11/23/2018 01:00 PM, Will Godfrey wrote:
[...]
Thanks for going into this in such detail Robin. I never realised fp stuff
could be *quite* so, umm, approximate!
Depending on context
In Fri, 23 Nov 2018 17:56:38 +
Gordonjcp wrote:
> On Fri, Nov 23, 2018 at 10:33:24PM +0500, Nikita Zlobin wrote:
> > In Fri, 23 Nov 2018 14:18:01 +
> > Gordonjcp wrote:
> >
> > > On Fri, Nov 23, 2018 at 02:09:02PM +0100, Robin Gareus wrote:
> > > > On 11/23/2018 01:00 PM, Will
On Fri, Nov 23, 2018 at 10:33:24PM +0500, Nikita Zlobin wrote:
> In Fri, 23 Nov 2018 14:18:01 +
> Gordonjcp wrote:
>
> > On Fri, Nov 23, 2018 at 02:09:02PM +0100, Robin Gareus wrote:
> > > On 11/23/2018 01:00 PM, Will Godfrey wrote:
> > > [...]
> > > > Thanks for going into this in such
It's probably gonna be silly question, but after short analysis i don't
see, what could be broken in this demo snippet, when float is standard
single-precision 32bit type.
I omit first case, as optimizing compiler could just optimize it to
just =1; though it could do it in second case too... (as
In Fri, 23 Nov 2018 14:18:01 +
Gordonjcp wrote:
> On Fri, Nov 23, 2018 at 02:09:02PM +0100, Robin Gareus wrote:
> > On 11/23/2018 01:00 PM, Will Godfrey wrote:
> > [...]
> > > Thanks for going into this in such detail Robin. I never realised
> > > fp stuff could be *quite* so, umm,
It could be lame question, but still... is it possible, that some
implementations (compiler/hardware) will print 1? (even 64bit doesn't
hold 20 decimal digits).?
In Fri, 23 Nov 2018 14:09:02 +0100
Robin Gareus wrote:
> On 11/23/2018 01:00 PM, Will Godfrey wrote:
> [...]
> > Thanks for going
On Fri, Nov 23, 2018 at 02:09:02PM +0100, Robin Gareus wrote:
> On 11/23/2018 01:00 PM, Will Godfrey wrote:
> [...]
> > Thanks for going into this in such detail Robin. I never realised fp stuff
> > could be *quite* so, umm, approximate!
>
> Depending on context and the maths, the difference may
On 11/23/2018 01:00 PM, Will Godfrey wrote:
[...]
> Thanks for going into this in such detail Robin. I never realised fp stuff
> could be *quite* so, umm, approximate!
Depending on context and the maths, the difference may not matter at
all, or may be off completely..
float a = (1 + 1e20) -
On Thu, 22 Nov 2018 23:29:11 +0100
Robin Gareus wrote:
>Hi Will,
>
>I just ran your code and -ffast-math does not make any difference.
>
>With or without --ffast-math I get "int: 5 rem: 0.049994"
>
>However optimizing the code with `-O2 --ffast-math` does make a
>difference because SSE is used.
Am 23.11.18 um 03:56 schrieb Hermann Meyer:
Am 22.11.18 um 23:44 schrieb Robin Gareus:
On 11/22/2018 09:27 PM, Hermann Meyer wrote:
However, problems with NAN's and INF's when use -ffinite-math-only
occurs only when we save preset values to file, and only sometimes
then.
A shot in the
Am 22.11.18 um 23:44 schrieb Robin Gareus:
On 11/22/2018 09:27 PM, Hermann Meyer wrote:
However, problems with NAN's and INF's when use -ffinite-math-only
occurs only when we save preset values to file, and only sometimes then.
A shot in the dark..
Serializing a float in most parts of the
On 11/22/2018 09:27 PM, Hermann Meyer wrote:
>
>
> However, problems with NAN's and INF's when use -ffinite-math-only
> occurs only when we save preset values to file, and only sometimes then.
A shot in the dark..
Serializing a float in most parts of the world uses comma as decimal
separator.
Hi Will,
I just ran your code and -ffast-math does not make any difference.
With or without --ffast-math I get "int: 5 rem: 0.049994"
However optimizing the code with `-O2 --ffast-math` does make a
difference because SSE is used.
Do you also use -O2, or -O3 along with --fast-math?
On
On Thu, Nov 22, 2018 at 09:27:58PM +0100, Hermann Meyer wrote:
> In guitarix nearly all DSP is generated by FAUST.
That doesn't make any difference for numerical stability.
This is a property of an algorithm, not of the language.
Ciao,
--
FA
___
Am 22.11.18 um 21:07 schrieb Fons Adriaensen:
On Thu, Nov 22, 2018 at 06:57:15PM +0100, Hermann Meyer wrote:
Am 22.11.18 um 18:30 schrieb Will Godfrey:
While testing some mixed floating point and integer calculations I found a
quite surprising difference when this compiler option was set
On 11/22/2018 07:28 PM, David Runge wrote:
> Rabbit hole stuff! SuperCollider came to a similar conclusion:
> https://github.com/supercollider/supercollider/issues/4116
This is a different issue. In SuperCollider's case they do want NaN and
not finite-math, that is not usually the case for
On Thu, Nov 22, 2018 at 06:57:15PM +0100, Hermann Meyer wrote:
> Am 22.11.18 um 18:30 schrieb Will Godfrey:
> > While testing some mixed floating point and integer calculations I found a
> > quite surprising difference when this compiler option was set (gcc 6.x). It
> > was
> > clearly
On Thu, 22 Nov 2018 19:28:58 +0100
David Runge wrote:
>On 2018-11-22 18:57:15 (+0100), Hermann Meyer wrote:
>> In the guitarix project we've disabled -ffast-math several years ago,
>> when I remember right it was at gcc3, as it could lead to different
>> un-reproduciable calculations. Last
On 2018-11-22 18:57:15 (+0100), Hermann Meyer wrote:
> In the guitarix project we've disabled -ffast-math several years ago,
> when I remember right it was at gcc3, as it could lead to different
> un-reproduciable calculations. Last option I've disabled on gcc8 now,
> is -ffinite-math-only, this
Am 22.11.18 um 18:30 schrieb Will Godfrey:
While testing some mixed floating point and integer calculations I found a
quite surprising difference when this compiler option was set (gcc 6.x). It was
clearly different at only 100 iterations and got dramatically worse with
larger counts.
My test
While testing some mixed floating point and integer calculations I found a
quite surprising difference when this compiler option was set (gcc 6.x). It was
clearly different at only 100 iterations and got dramatically worse with
larger counts.
My test routine was this:
int a = 0;
float b = 0;
26 matches
Mail list logo
