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
Len Lawrence wrote:
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
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>
···
On Aug 4, 8:35 am, "Len Lawrence" <l...@tarazed.demon.co.uk> wrote:
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
Will reply directly Cliff as it is a bit off-topic.
Len
···
On Sat, 04 Aug 2007 22:57:22 +0900, Cliff Rowley wrote:
--- quoted text purged -----
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.
···
On Sat, 04 Aug 2007 22:57:22 +0900, Cliff Rowley wrote:
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
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
···
On Sun, 05 Aug 2007 02:18:57 +0000, georgebudd wrote:
