DateTime irrationality

[Len Lawrence]

I am starting to recode several home applications in Ruby/GTK2 after
16 years of Tcl/Tk and a foray into Ruby/Tk territory. The simplest
case would be my sidereal time widget which includes an Stime class,
severely pruned below to show the to_s method (which has been altered
to investigate the faulty behaviour described later).

----------------------------------------------------------------

require 'date'

class Stime

def to_s ( siderealtime )

z = siderealtime / 24.0
# h = (24.0 * z).to_i
c = Date.day_fraction_to_time( z )
c[3] *= 86400.0
c[2] += c[3]
c[3] = nil
# c[0] = h
sprintf( "%02d:%02d:%06.3f", c[0],c[1],c[2] )

end

end

puts stime.to_s( 9.334 )
puts stime.to_s( 13.603 )
t = 14.603
puts sprintf( "whatever = %06.3f = %s\n", t, stime.to_s( t ) )
puts stime.to_s( 18.765 )

----------------------------------------------------------------

Results:

09:20:02.400
13:36:10.800
whatever = 14.603 = 13:36:10.800 ???
18:45:54.000

I have established by trying a few values within the range 13.999 to
15.000 that the error is confined to the range 14.000 to 14.999. The
symptoms are the same on two 64-bit machines, one AMD Opteron (2) and
an Intel Core Duo. It ain't rational. Anybody ever seen anything
like this?

If the two commented lines are uncommented the to_s method always
returns the correct hour value in the string.
Date#day_fraction_to_time calls clfloor (which library?) and includes
an argument 1.to_r (to_r from rational.rb).

Len Lawrence

 

[Cliff Rowley]

I am starting to recode several home applications in Ruby/GTK2 after
16 years of Tcl/Tk and a foray into Ruby/Tk territory. The simplest
case would be my sidereal time widget which includes an Stime class,
severely pruned below to show the to_s method (which has been altered
to investigate the faulty behaviour described later).

Just a matter of curiosity as an avid astronomer, what are you working
on? ;-)

I have a few astro related projects I'm working on. I started using
Ruby but I fear it might be a little slow compared to others in some of
the operations I'm performing (looking up star data from the TychoII
catalog). What are your experiences? I considered using inline C but
it's a can of worms I haven't dared open yet (based primarily on the
fact I'm stuck on a Windows machine for development).

Anyways, I just thought it was cool to see someone else waxing astro
with ruby ;-)

Cliff

 

[Len Lawrence]

--- quoted text purged -----
Anyways, I just thought it was cool to see someone else waxing astro
with ruby ;-)

Will reply directly Cliff as it is a bit off-topic.

Len

 

[georgebudd]

I am starting to recode several home applications in Ruby/GTK2 after
16 years of Tcl/Tk and a foray into Ruby/Tk territory. The simplest
case would be my sidereal time widget which includes an Stime class,
severely pruned below to show the to_s method (which has been altered
to investigate the faulty behaviour described later).

----------------------------------------------------------------

require 'date'

class Stime

def to_s ( siderealtime )

z = siderealtime / 24.0
# h = (24.0 * z).to_i
c = Date.day_fraction_to_time( z )
c[3] *= 86400.0
c[2] += c[3]
c[3] = nil
# c[0] = h
sprintf( "%02d:%02d:%06.3f", c[0],c[1],c[2] )

end

end

puts stime.to_s( 9.334 )
puts stime.to_s( 13.603 )
t = 14.603
puts sprintf( "whatever = %06.3f = %s\n", t, stime.to_s( t ) )
puts stime.to_s( 18.765 )

----------------------------------------------------------------

Results:

09:20:02.400
13:36:10.800
whatever = 14.603 = 13:36:10.800 ???
18:45:54.000

I have established by trying a few values within the range 13.999 to
15.000 that the error is confined to the range 14.000 to 14.999. The
symptoms are the same on two 64-bit machines, one AMD Opteron (2) and
an Intel Core Duo. It ain't rational. Anybody ever seen anything
like this?

If the two commented lines are uncommented the to_s method always
returns the correct hour value in the string.
Date#day_fraction_to_time calls clfloor (which library?) and includes
an argument 1.to_r (to_r from rational.rb).

Len Lawrence

That's weird.

Looks like divmod is somehow confused on some machines....

On my Mac (ruby 1.8.6 (2007-03-13 patchlevel 0) [powerpc-
darwin8.9.0]):

irb(main):045:0> (14.9/24.0).divmod(1.0/24)
=> [13, 0.0375]


On my Linux box (ruby 1.8.5 (2006-12-04 patchlevel 2) [i386-linux]):

irb(main):002:0> (14.9/24.0).divmod(1.0/24)
=> [14, 0.0375]
irb(main):003:0>

 

[Len Lawrence]

On Sun, 05 Aug 2007 02:18:57 +0000, georgebudd wrote:

That's weird.

Looks like divmod is somehow confused on some machines....

On my Linux box (ruby 1.8.5 (2006-12-04 patchlevel 2) [i386-linux]):

irb(main):002:0> (14.9/24.0).divmod(1.0/24)
=> [14, 0.0375]
irb(main):003:0>

I am using ruby 1.8.5 (2006-08-25) [x86_64-linux-gnu]

For now I shall use a workaround.

Thanks

 

[Len Lawrence]

Just a matter of curiosity as an avid astronomer, what are you working
on? ;-)

I have a few astro related projects I'm working on. I started using
Ruby but I fear it might be a little slow compared to others in some of
the operations I'm performing (looking up star data from the TychoII
catalog). What are your experiences? I considered using inline C but
it's a can of worms I haven't dared open yet (based primarily on the
fact I'm stuck on a Windows machine for development).

Anyways, I just thought it was cool to see someone else waxing astro
with ruby ;-)

Sorry Cliff - my message to your gmail account bounced. This happens a
lot. IP not authorized to access server directly - use SMTP relay of ISP.
Haven't a clue.