sqrt(2) must go

[Marco Leise]

Am 20.10.2011, 22:37 Uhr, schrieb Marco Leise <Marco.Leise at gmx.de>:

> 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) ?

Forget what I said. If a 64-bit mantissa floating point type doesn't exist  
on all systems this doesn't work.