> There are some floats that can go even smaller than this, but they are "denormal" and may incur a large runtime overhead (they are intended to prevent underflow / minimize loss of precision in certain computations involving very small quantities, and aren't supposed to be used in normal calculations).

We were taught something else in university.
Small overhead, though CPUs can handle them (not software implemented)
and they are used when needed, you can't choose to use it or not to use it.

On Tue, Jul 23, 2013 at 09:39:05AM +0200, David wrote:
> > There are some floats that can go even smaller than this, but they are "denormal" and may incur a large runtime overhead (they are intended to prevent underflow / minimize loss of precision in certain computations involving very small quantities, and aren't supposed to be used in normal calculations).
> 
> We were taught something else in university.
> Small overhead, though CPUs can handle them (not software implemented)
> and they are used when needed, you can't choose to use it or not to use it.

Well, I learned this from Wikipedia, so I'm not 100% sure whether or not it's accurate:

http://en.wikipedia.org/wiki/Denormal_number#Performance_issues


T

-- 
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan

On Tuesday, 23 July 2013 at 03:14:17 UTC, Ali Çehreli wrote:
> 1) There shouldn't be warnings at all; what we call warnings should be errors.
>
> I agree with that completely.

Not really. At least my (and, as far as I understand, Jonathan) point of view is that warnings should be either error or subject to static analysis tools. Simply making all warnings errors makes them unusable as they may prohibit some pretty legitimate code patterns (though rarely legitimate). There should not be a warning that can change language semantics depending on compiler flag.

On 07/23/2013 08:05 AM, Dicebot wrote:

> On Tuesday, 23 July 2013 at 03:14:17 UTC, Ali Çehreli wrote:
>> 1) There shouldn't be warnings at all; what we call warnings should be
>> errors.
>>
>> I agree with that completely.
>
> Not really. At least my (and, as far as I understand, Jonathan) point of
> view is that warnings should be either error or subject to static
> analysis tools. Simply making all warnings errors makes them unusable as
> they may prohibit some pretty legitimate code patterns (though rarely
> legitimate).

From my C and C++ experience, I am under the impression that warnings can be eliminated by changing code while maintaining the same behavior.

> There should not be a warning that can change language semantics depending
> on compiler flag.

I see compiler flags as parts of the environment just like the architecture of the cpu, string imports, floating point precision, and anything else that can be checked during compilation time...

Thank you, I finally understand: The view is, warnings should not make any difference in compilation; the programmers can read the compiler output and act accordingly if they so wish.

Ali