February 09, 2020
On Sunday, 9 February 2020 at 00:25:43 UTC, sarn wrote:
> Walter's possibly remembering the fuss that was made about this bug:
> https://en.wikipedia.org/wiki/Pentium_FDIV_bug

It's not a bug. Different hardware is built differently, they aren't going to all have the same results unless they are exactly the same. You aren't going to get that kind of behavior, especially across different assembly architectures.
February 09, 2020
On Sunday, 9 February 2020 at 15:28:21 UTC, Arine wrote:
> On Sunday, 9 February 2020 at 00:25:43 UTC, sarn wrote:
>> Walter's possibly remembering the fuss that was made about this bug:
>> https://en.wikipedia.org/wiki/Pentium_FDIV_bug
>
> It's not a bug. Different hardware is built differently, they aren't going to all have the same results unless they are exactly the same. You aren't going to get that kind of behavior, especially across different assembly architectures.

It's a simpler matter than that. Either a hardware FPU is compliant with the IEEE754 standard or not. There can be infinitely many implementations, but if they claim to implement the standard, they should all return either the same value or a value within the specified interval (for the same instruction and operands).
February 09, 2020
On Sunday, 9 February 2020 at 16:08:58 UTC, Petar Kirov [ZombineDev] wrote:
> or a value within the specified interval

Really the only relevant part of your comment. If they aren't exactly the same, then there is going to be variance. Anyways I would like to know what algorithms he was referring to.

February 10, 2020
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 :)

It feels intuitively that there's got to be a more effective way of approaching this than brute-forcing all the cases, or randomly selecting a sufficient subset.

I would anticipate that there has to be a well-defined subset of cases such that, if the formatter works for those, it'll work for everything else.

(Yes, I get that in this case you're trying to compare the behaviour of 2 different functions, but I think the principle should still apply.)
February 10, 2020
On Thursday, 6 February 2020 at 16:26:43 UTC, berni44 wrote:
> Last week, I was quite disappointed when no one replied on my anouncement of a new website about D (meanwhile there are three replies, one negative

I'm going to guess that my reply is the "negative" one but I wouldn't exactly call it negative.

I didn't specifically say anything bad about your website, on the contrary I think it's great and everything. It was just wishful thinking that it would've been great to see it in D as D already lacks websites written in D.

It's sad to see you wanting to leave, please don't.

The community needs you and nobody wants you gone.
February 10, 2020
On Monday, 10 February 2020 at 11:23:16 UTC, Joseph Rushton Wakeling 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 :)
>
> It feels intuitively that there's got to be a more effective way of approaching this than brute-forcing all the cases, or randomly selecting a sufficient subset.
>
> I would anticipate that there has to be a well-defined subset of cases such that, if the formatter works for those, it'll work for everything else.
>
> (Yes, I get that in this case you're trying to compare the behaviour of 2 different functions, but I think the principle should still apply.)

KLEE (which I mentioned earlier in the thread) uses constraints solvers to prove/disapprove assertions over all possible code paths.  KLEE float uses the IEEE floating point theory in the Z3 solver.

When you run KLEE against some code, you can get it to generate example inputs for each code path, which can be used as a regression suite.  A regression suite like that is weaker than running KLEE again, but stronger than the typical code coverage test suite because it has code *path* coverage.
June 01, 2020
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...

I will delete my github account next week. If you want to keep anything from it copy it now or never.
June 01, 2020
On Monday, 1 June 2020 at 09:15:33 UTC, berni44 wrote:
> 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...
>
> I will delete my github account next week. If you want to keep anything from it copy it now or never.

As it might be easily overlooked, I'd like to point out

https://github.com/berni44/phobos/tree/formatS

which is no PR yet, as it is incomplete. It's a rewrite (correcting several mistakes and adding not documented features) of the main documentation of std/format, including unittests.
June 01, 2020
On Monday, 1 June 2020 at 09:15:33 UTC, berni44 wrote:
> 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...
>
> I will delete my github account next week.

I would keep it if I were you. One reason is that once out opening issues (e.g in a non D project) is impossible. You can just archive your repositories or make them private and take your distances, if it is about accompagning your disengagement with a strong symbol.

June 01, 2020
On Monday, 1 June 2020 at 09:15:33 UTC, berni44 wrote:
> 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...
>
> I will delete my github account next week. If you want to keep anything from it copy it now or never.

I suggest you don't delete it because it can be useful in future job applications as proof that you are a capable and self-motivated developer (even if applying for jobs in other languages).