| Re: JULDAY-CALDAT problem [message #38233] |
Fri, 27 February 2004 08:17  |
James Kuyper
Messages: 425
Registered: March 2000
|
Senior Member |
|
|
Luciano wrote:
>
> Thanks David and Ben for your help. I've solved the problem by not
> using Julday and Caldat...
> David, if for the computer 0=10^-5 then is not me who has to start
> counting like a computer, it should be the other way around :)
>
> This is simply wrong and should be fixed at some level! I understand
> all the hardware, 0s and 1s, significant figures and related problems
> described in your "Help! The Sky is Falling!" section. But... don't
> you think this should be fixed somehow?
>
> If you ask me, 0 should be 0, and the computer should be able to know
> it...
There are ways to achieve that - they basically involve storing and
manipulation all the components of dates as integers, rather than
floating point. As long as floating point numbers are used, inaccuracy
is unavoidable, since you can't represent all the real numbers in a
finite non-zero range, using a representation that takes up a fixed
maximum about of memory.
|
|
|
|
| Re: JULDAY-CALDAT problem [message #38239 is a reply to message #38233] |
Fri, 27 February 2004 08:06  |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
Luciano wrote:
>
> Thanks David and Ben for your help. I've solved the problem by not
> using Julday and Caldat...
> David, if for the computer 0=10^-5 then is not me who has to start
> counting like a computer, it should be the other way around :)
>
> This is simply wrong and should be fixed at some level! I understand
> all the hardware, 0s and 1s, significant figures and related problems
> described in your "Help! The Sky is Falling!" section. But... don't
> you think this should be fixed somehow?
>
> If you ask me, 0 should be 0, and the computer should be able to know
> it...
0 is 0 on a computer. A number like 0.0 can, typically, be represented exactly. Same goes
for numbers like 1.0 or 2.0. When you start using 0.1's or 3.1415927's things get sticky.
And, when you start repeatedly adding and subtracting the sticky numbers that *can't* be
represented exactly, then the numeric precision issues crop up.
Having said all that, I hear you. It would be nice if the way we thought about these sorts
of problems was also how a computer handles them. When confronted with this sort of
situation, e.g. "the computer should be able to know", I just remember that a computer has
zero (exactly :o) intelligence. All the know-how and mistakes come from us.
cheers,
paulv
--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: JULDAY-CALDAT problem [message #38265 is a reply to message #38264] |
Thu, 26 February 2004 06:52 |
btupper
Messages: 55
Registered: January 2002
|
Member |
|
|
On Thu, 26 Feb 2004 07:19:10 -0700, David Fanning <david@dfanning.com>
wrote:
> Luciano writes:
>
>> Hi, maybe somebody has a clue about the following:
>>
>> IDL> aa=JulDay(11,18,1990,2,0,0)
>> IDL> Caldat,aa,m,d,y,h,mi,s
>> IDL> print,m,d,y,h,mi,s
>> 11 18 1990 2 0 5.3644181e-005
>>
>> Why does s=5.3644181e-005 and not s=0 as it should be?
>
> I think it is a question of using a computer to do the
> calculations rather than your fingers. :-)
>
> Floating point numbers have about 7 significant figures.
> Assuming 60 seconds in a minute, this number starts to
> vary in the seventh place. So, about as close to zero
> as you gonna get, I think.
>
> For a more complete explanation, see this article:
>
> http://www.dfanning.com/math_tips/sky_is_falling.html
>
Hello,
One additional thing to add to David's explanation is that JULDAY adds
a small offset to the seconds argument. I forget why, but the reason
is described in the documentation for JULDAY. You could test it out
by editing the JULDAY function so it does not add the offset. I'll
bet you still will not get the answer you expect because of the
condition David describes.
Ben
|
|
|
|
| Re: JULDAY-CALDAT problem [message #38266 is a reply to message #38265] |
Thu, 26 February 2004 06:19 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Luciano writes:
> Hi, maybe somebody has a clue about the following:
>
> IDL> aa=JulDay(11,18,1990,2,0,0)
> IDL> Caldat,aa,m,d,y,h,mi,s
> IDL> print,m,d,y,h,mi,s
> 11 18 1990 2 0 5.3644181e-005
>
> Why does s=5.3644181e-005 and not s=0 as it should be?
I think it is a question of using a computer to do the
calculations rather than your fingers. :-)
Floating point numbers have about 7 significant figures.
Assuming 60 seconds in a minute, this number starts to
vary in the seventh place. So, about as close to zero
as you gonna get, I think.
For a more complete explanation, see this article:
http://www.dfanning.com/math_tips/sky_is_falling.html
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
| Re: JULDAY-CALDAT problem [message #38313 is a reply to message #38261] |
Sun, 29 February 2004 14:50 |
Mark Hadfield
Messages: 783
Registered: May 1995
|
Senior Member |
|
|
David Fanning wrote:
> David Fanning writes:
>
>
>> I was asked about you and I related how your backhand is quite
>> famous on the newsgroup. That seemed to clinch it.
>
>
> Do you think I should bring my rackets? 20 below
> doesn't seem like it's *that* cold! :-)
Come on guys. I was reading an enthralling thread on JULDAY & CALDAT and
you drift off into Antarctica, or Arctica, somewhere cold anyway.
JULDAY and CALDAT are much more interesting.
--
Mark Hadfield "Ka puwaha te tai nei, Hoea tatou"
m.hadfield@niwa.co.nz
National Institute for Water and Atmospheric Research (NIWA)
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
