On Saturday, 8 February 2020 at 17:21:04 UTC, Jonathan Marler wrote:
> for 32-bit floats it doesn't take too long to do an exhaustive test (maybe 30 minutes or so).  I did this with my port of the "ryu" float to string implementation (https://github.com/dragon-lang/mar/blob/master/src/mar/ryu.d).
>  That being said, an exhaustive 64-bit test may not finish until the inevitable heat death of the universe :)

Maybe some structured tests could help, e.g. by using libfuzzer to instrument the new and old code. It's obviously not be an exhaustive tests but could result in a better coverage than random sampling.

On Saturday, 8 February 2020 at 16:29:18 UTC, berni44 wrote:
> On Saturday, 8 February 2020 at 01:40:36 UTC, Walter Bright wrote:
>> [...]
>
> I'm sorry, maybe I didn't express myself clearly enough: I do not want to close them, just because they are old, but to actually handle them somehow. As far as I know, several of them could either be merged (maybe with some minor changes) or it is quite clear, that they will never be merged (for example because the issue has been addressed in a different way meanwhile).
>
> On Saturday, 8 February 2020 at 01:52:25 UTC, Walter Bright wrote:
>> [...]
>
> That's what I did - see [1]. H. S. Teoh suggested above to put them into std/internals to preserve them and have a possibility to let others run the tests too. I'll have to see. Havn't peeked into std/internals yet...
>
> [1] https://github.com/berni44/printFloat

FYI: another easy option would be to add this to the project tester. It basically checks out a project and then does `dub test` on it.
The downside is that the project tester is Linux only at the moment.

On 2/8/2020 8:29 AM, berni44 wrote:
> On Saturday, 8 February 2020 at 01:52:25 UTC, Walter Bright wrote:
>> Another way is to construct a tester that randomly generates bit patterns, then formats the result with both sprintf and the new implementation, and they must match exactly. Then it's a matter of how many of these test cases are run.
> 
> That's what I did - see [1]. H. S. Teoh suggested above to put them into std/internals to preserve them and have a possibility to let others run the tests too. I'll have to see. Havn't peeked into std/internals yet...
> 
> [1] https://github.com/berni44/printFloat

Good. It needs to be part of the D test suite.

On 2/8/2020 9:35 AM, Seb wrote:
> FYI: another easy option would be to add this to the project tester. It basically checks out a project and then does `dub test` on it.
> The downside is that the project tester is Linux only at the moment.

That shouldn't be a big problem here, as the floating point tests should be platform agnostic.

On Saturday, 8 February 2020 at 17:27:00 UTC, MoonlightSentinel wrote:
> On Saturday, 8 February 2020 at 17:21:04 UTC, Jonathan Marler wrote:
>> for 32-bit floats it doesn't take too long to do an exhaustive test (maybe 30 minutes or so).  I did this with my port of the "ryu" float to string implementation (https://github.com/dragon-lang/mar/blob/master/src/mar/ryu.d).
>>  That being said, an exhaustive 64-bit test may not finish until the inevitable heat death of the universe :)
>
> Maybe some structured tests could help, e.g. by using libfuzzer to instrument the new and old code. It's obviously not be an exhaustive tests but could result in a better coverage than random sampling.

Another option is KLEE (https://theartofmachinery.com/2019/05/28/d_and_klee.html).  Unfortunately the original KLEE doesn't support floating point or threads, but you could use the (unmaintained?) floating point fork to generate a pretty good test suite based on an existing libc snprintf or a betterC version of D floating point code.

On Saturday, 8 February 2020 at 01:52:25 UTC, Walter Bright wrote:
> A lot of algorithms really do care if 3.78612345 is more accurate than 3.78612344.

What algorithms are those? You can get that kind of variance dependent on what hardware you are running on.

On Saturday, 8 February 2020 at 22:44:26 UTC, Arine wrote:
> On Saturday, 8 February 2020 at 01:52:25 UTC, Walter Bright wrote:
>> A lot of algorithms really do care if 3.78612345 is more accurate than 3.78612344.
>
> What algorithms are those? You can get that kind of variance dependent on what hardware you are running on.

Walter's possibly remembering the fuss that was made about this bug:
https://en.wikipedia.org/wiki/Pentium_FDIV_bug

On Sun, Feb 09, 2020 at 12:25:43AM +0000, sarn via Digitalmars-d wrote:
> On Saturday, 8 February 2020 at 22:44:26 UTC, Arine wrote:
> > On Saturday, 8 February 2020 at 01:52:25 UTC, Walter Bright wrote:
> > > A lot of algorithms really do care if 3.78612345 is more accurate than 3.78612344.
> > 
> > What algorithms are those? You can get that kind of variance dependent on what hardware you are running on.
> 
> Walter's possibly remembering the fuss that was made about this bug: https://en.wikipedia.org/wiki/Pentium_FDIV_bug

Dare I bring up this one too?

	https://issues.dlang.org/show_bug.cgi?id=15854


T

-- 
Дерево держится корнями, а человек - друзьями.

On Friday, 7 February 2020 at 20:00:16 UTC, berni44 wrote:
> I still don't know, if I will leave or stay...

I really don't fit in here...

On Sunday, 9 February 2020 at 10:04:25 UTC, berni44 wrote:
> On Friday, 7 February 2020 at 20:00:16 UTC, berni44 wrote:
>> I still don't know, if I will leave or stay...
>
> I really don't fit in here...

Social dynamics in open source is fascinating to me. Can you elaborate a bit on why you don't think you don't fit in? I'd like to learn from your perspective.

I see that you had alot of the same thoughts that I've had. Issues with PRs and bugs that stay open forever with the focus on new features rather than fixing issues. Do you think this community is beyond hope? What would be different with a community that you feel like you would fit in with?