float equality

[spir]

On 02/21/2011 08:52 AM, Kevin Bealer wrote:
> == Quote from Walter Bright (newshound2 at digitalmars.com)'s article
> ...
>> I do understand that if you have a full symbolic representation, you can do so
>> with zero losses. But Kevin's proposal was not that, it was for a ratio
>> representation.
>>
>> All it represents symbolically is division. There are plenty of other operations.
>
> I'm just answering the original poster's question.  You're right though -- it's not
> a complete numerical system, (and I don't propose it for inclusion in the language
> or even necessarily the library.)
>
> I had two goals:
>
> 1. To solve the basic problem the original poster was asking -- if you are working
> with simple decimals and arithmetic you can get completely accurate representations
> this way.  For some cases like simple financial work this might work really well.
> e.g. where float would not be because of the slow leak of information with each
> operation.  (I assume real professional financial work is already done using a
> (better) representation.)

The few financial libs/types I have met (it's not my glass of bier) all used 
plain integers ;-)
(after all, 1.23 € or $ is a plain integer when counted in cents...), with a 
fixed or variable decimal scale factor.
(what I talk about in another post, I just realise it)

> 2. To explain why the 'simple' task of representing something like .1 wasn't as easy
> as it looks.  In other words, why the people who designed float weren't just brain
> dead.  I think they really knew what they were doing but it shocks most people at
> first that a modern computer can't do what they see as grade school arithmetic.
>
> I think for some purposes though, lossless domain specific representations can
> be a good tool -- if you can represent a problem in a way that is lossless you can
> maybe do better calculations over long series than working with 'double' and taking
> the accuracy hit.  This is necessarily an application specific technique though.

I think some typical features, or solutions to implement given features, used 
in present programming languages, are historic traces from times when 
scientific computations where the only, then the typical, use of computers. I'm 
not far to think that fractional numbers (id est, numbers able to represent 
/measures/) form a domain-specific feature -- thus belong to library (lol).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com