On Tuesday, 24 October 2017 at 16:28:03 UTC, Fool wrote:
>
> @all: It is sad to see how parts of the community are losing their distance to the project and even put a gloss on completely absurd design decisions.

Consensus within groups is kind of important actually...it encourages harmony and coherence..with which.. there is no group.

But just as important, is being aware of the danger of groupthink...

Many (implicitly) understand the former, few understand (or are even aware of) the latter..

https://www.jstor.org/stable/3791464?seq=1#page_scan_tab_contents

Not that I'm suggesting anything here other than... don't become the victim of groupthink.

On Wednesday, 25 October 2017 at 01:06:40 UTC, codephantom wrote:
> Consensus within groups is kind of important actually...it encourages harmony and coherence..with which.. there is no group.
>

if only we could edit our post to correct it...when's that going to happen btw. ;-)

of course I meant .. 'without which' ...not 'with which' ...

btw. further below is a good study in group dynamics - I like the phrase "Stupidity certainly is not the explanation". (second paragraph)

http://web.mit.edu/curhan/www/docs/Articles/15341_Readings/Group_Dynamics/Janis_Groupthink_from_Psych_Today.pdf

On Tuesday, 24 October 2017 at 17:54:55 UTC, Andrei Alexandrescu wrote:
> For the record, I remember the points made:
>
> * When converting across integral types, any failed coercion yields a value essentially unrelated to the source. So we deemed these unacceptable.
>
> * When converting int to float or long to double, there is a loss of accuracy - a float can represent all ints, but some of them will be represented with approximation. But here there _is_ a notion of "I'm okay with an approximation". So we deemed these acceptable.
>
> * When converting double to float, again there is a loss of accuracy and also the risk of too large values. But there's never a gross mistake - too large values are converted to infinity, and otherwise an approximation occurs. This was also deemed acceptable.
>
> Folks with other design sensibilities might choose differently. Actually I wasn't on board with this decision, but I accepted it. But deeming it absurd is a bit of a stretch.

Thank you for the explanation. I understand the reasoning. It seems strange to me that D is aiming at security concerning memory management and integer arithmetic but not with respect to the processing of floating-point entities.

To clarify: this topic was not the reason but only the occasion for my ranting. It's just a pointed expression of my personal impression that I got from a few discussions here.

I would like to stress that there are also people in the community who do not reflexively dismiss every critical objection from the outside. In this context, "problem realized, won't fix nevertheless" seems to be a much better answer than denying existence of problems brought up by new or less known people.

On Wednesday, 25 October 2017 at 01:24:01 UTC, codephantom wrote:
> http://web.mit.edu/curhan/www/docs/Articles/15341_Readings/Group_Dynamics/Janis_Groupthink_from_Psych_Today.pdf

Great read, thank you for sharing!

On Tuesday, 24 October 2017 at 15:29:38 UTC, Basile B. wrote:
> On Saturday, 21 October 2017 at 20:17:12 UTC, NX wrote:
>> I was working on some sort of math library for use in graphical computing and I wrote something like this:
>>
>> const float PiOver2 = (atan(1.0) * 4) / 2;
>>
>> Interestingly enough, I realized that atan() returns double (in this case) but wait, it's assigned to a float variable! Compiler didn't even emit warnings, let alone errors.
>>
>> I see no reason as to why would this be legal in this century, especially in D.
>> So can someone tell me what's the argument against this?
>> Why type conversions differ between integral and floating types?
>> Why can't I assign a long to an int but it's fine when assigning double to float?
>>
>> I think this is a serious topic and needs clarification.
>
> I think that the rationale for allowing that is that you can feed the FPU with high precision values to get a better internal accuracy (temp values stored in ST0-ST7). At the end, even if there's a truncation the result is more accurate that if you would have feed the FPU with parameters of the same size as the result.

I'm currently using the compiler version that includes the warning:

https://github.com/dlang/dmd/pull/7240

and discovered that it's actually not only a problem of truncation.
For

```
float foo(float f)
{
    f *= 0.5;
    return f;
}
```


DMD generates


```
push rbp
mov rbp, rsp
cvtss2sd xmm1, xmm0 ; promotion
movsd xmm2, qword ptr [<addr of constant>]
mulsd xmm1, xmm2
cvtsd2ss xmm0, xmm1 ; truncation
pop rbp
ret
```

as you can see, the parameter is promoted to double because of the constant and then the result is converted back to single. The two instructions obviously disappear when the constant get the float suffix, and the compiler warning helped you to save a few cycles.

On Sunday, 22 October 2017 at 14:59:41 UTC, Andrei Alexandrescu wrote:
> On 10/22/17 9:41 AM, User wrote:
>> Is there a list of such quirks or gotchas in dlang?
>> 
>> The ones I know of are
>> 
>> 1. Implicit conversion from double to float
>> 
>> 2. Integer division results in integer result truncation the fractional part.
>
> These are not gotchas, as TDPL explains. One unpleasant related gotcha is implicit conversions across signedness and comparison of integral types with different signedness. -- Andrei

Shouldn't all these be documented?