Re: Why does 1.2 % 0.01 not equal to zero?
- From: Tom <Thomas-911@xxxxxxxxxxxxx>
- Date: Tue, 05 Aug 2008 19:27:54 -0500
Hey Pete --
My integer method is sort of a back door cheat. It avoids the real
issue of imprecise binary representation of rational numbers. If the
question was posed by a student who needs to convince their instructor
of sufficient understanding ... I much prefer your approach. If on the
other hand it is part of a control/descision block of code ... I
prefer the simplification my method represents and it is one I have
used several times. I consider double % double a trap of sorts that
introduces results often forgotten by those who have not used it
recently. Neither approach is bullet proof; however, the inconsistent
results of the % operator on floats or doubles is so insidious ... I
have a hard time convincing myself that it is a good feature within
C#.
What happens when one has >>
1.20000001 % 0.01
In the above case the 0.00000001 remainder might be very important?
So checks against the RHS value of 0.01 are not a good practice. In
this case the multiplier would need to be 100,000,000 and
Int32.MaxValue = 2,147,483,647 issues start to emerge.
Eventually even the 128 bit decimal representation fails to provide
sufficient accuracy. Irrational numbers such as 1/3'rd and Pi are not
accurately represented even with decimal utilization. I think it false
to make statements such as: "Usage of decimal type assures
_sufficient_ accuracy."
Int32.MaxValue = 2147483647
Int64.MaxValue = 9223372036854775807
decimal.MaxValue = 79228162514264337593543950335
In summary:
1) A thorough understanding of the entire mathematical methodology
used and its inherent precision is necessary. A deep understanding of
the problem domain is mandatory and this is not a trivial task. It
requires the researcher(s) (physicist, engineer, mathematician, etc.)
and the computer scientist to work together.
2) If you see float % float or double % double in code ... become
very concerned.
-----------------------------------------------
My observed speed enhancement converting to integers was associated
with huge stock data files where the data was fully loaded into ram to
avoid hard drive i/o speed issues. In this specific case there was a
lot of numerical summation work being done (integrations, averages,
statistics, etc.) in a dynamic tuning algorithm with lots of looping
within the optimization routine.
Once values such as 987.125 were converted to 987125 the rewritten
program ran in approximately 1/5'th the time as the program using
doubles for data storage. I was thrilled to have results in 12 minutes
vs 1 hour. Situations where such improvements can be had are rare ...
but in my case it involves code in continuous operation and is one of
the best performance enhancements I have stumbled onto. In the texts
and courses I have been exposed too ... the speed differences between
integer math and doubles (or floats) has been ignored. (I have never
learned assembly nor been exposed to the very low level compiler
optimization methods.)
I encourage those where performance is critical to evaluate the
possibility of using integers. The conversion is not a simple process.
It is tricky enough where I suggest side-by-side testing between
integer code and doubles code until all ambiguities are understood and
removed.
-- Tom
.
- Follow-Ups:
- Re: Why does 1.2 % 0.01 not equal to zero?
- From: Peter Duniho
- Re: Why does 1.2 % 0.01 not equal to zero?
- References:
- Why does 1.2 % 0.01 not equal to zero?
- From: Bernard.Mangay
- Re: Why does 1.2 % 0.01 not equal to zero?
- From: Tom
- Re: Why does 1.2 % 0.01 not equal to zero?
- From: Peter Duniho
- Why does 1.2 % 0.01 not equal to zero?
- Prev by Date: Re: How expensive is brush creation?
- Next by Date: Re: Why does 1.2 % 0.01 not equal to zero?
- Previous by thread: Re: Why does 1.2 % 0.01 not equal to zero?
- Next by thread: Re: Why does 1.2 % 0.01 not equal to zero?
- Index(es):
Relevant Pages
|
