sqrt(2) must go

[Marco Leise]

Am 20.10.2011, 08:02 Uhr, schrieb Russel Winder <russel at russel.org.uk>:

> On Wed, 2011-10-19 at 23:36 -0400, dsimcha wrote:
>> On 10/19/2011 11:27 PM, Marco Leise wrote:
>> > And real can be used without protability problems on PowerPC or ARM?
>>
>> Yes, it's just that they may only give 64 bits of precision.  Floating
>> point is inexact anyhow, though.  IMHO the fact that you may lose a
>> little precision with very large longs is not a game changer.
>
> This is not convincing.
>
> One of the biggest problem is software development is that computers
> have two systems of hardware arithmetic that are mutually incompatible
> and have very different properties.  Humans are taught that there are
> abstract numbers that can be put into different sets:  reals, integers,
> naturals, etc.
>
> There are already far too many programmers out there who do not
> understand that computer numbers have representation problems and
> rounding errors.
>
> Another issue:
>
> 	sqrt ( 2 )
> 	sqrt ( 2.0 )
> 	sqrt ( 2.0000000000000000000000000000000000000000 )
>
> actually mean very different things.  The number of zeros carries
> information.
>
> Summary, losing precision is a game changer.  This stuff matters.  This
> is a hard problem.

Sure it matters, but performance also matters. If I needed the precision  
of a real, I would make sure that I give the compile the right hint. And  
adding zeros doesn't help. The representation is mantissa and exponent and  
your three examples would all come out the same in that representation. :)
Is this really a real life problem, or can we just go with any solution  
for sqrt(2) that works (int->double, long->real) and leave the details to  
the ones who care and would write sqrt(2.0f) ?