Select on solaris

ruby-talk
1

Hmm…ok. Without any testing on my own whatsoever, would testing against
empty? instead of nil? be a viable workaround?

I should get a chance to play with this more tomorrow.

Regards,

Dan

···

-----Original Message-----
From: Jeff Putsch [mailto:putsch@mxim.com]
Sent: Wednesday, August 21, 2002 4:17 PM
To: ruby-talk@ruby-lang.org
Subject: Re: select on solaris

djberge@qwest.com writes:

-----Original Message-----
From: jeff Putsch [maito:putsch@mxim.com]
This does not seem right. First, there is never any data
on the error
object, so why is select saying there is? Second once the
end of the
file is reached, why is select continuing to claim both
descriptors
have data? I’m sure I’m doing something wrong…

err is in IO object, it’s not the data contained within the object.

I know err is an IO object. My choice of words was cleary poor. The
issue I’m having is #select takes an array of IO objects and should
wait for data to become available on them. It then (should) returns an
array of objects that are ready.

The behavior I’m observing is that it ALWAYS returns, claiming all my
IO objects have data ready on them (even after an EOF on the IO
object). The reality is not all the objects do. In the
example(s) I posted
the “err” object should not have data at all, so it should
not be in the
array of ready object, yet it is.

That, hopefully, better explains what I am seeing and why I
need advice
on solving the problem.

2

Hmm…ok. Without any testing on my own whatsoever, would testing against
empty? instead of nil? be a viable workaround?

Nope. Here’s a simple test case:

#!/usr/sepp/bin/ruby

def run_command
f = IO.popen(“cat /etc/hosts”)

while not (r=select([f])).empty?
  p r
  p r[0][0].gets.to_s
end

end

run_command

And here’s the output:

[[#IO:0x4a848], , ]
“#\n”
[[#IO:0x4a848], , ]
“# Internet host table\n”
[[#IO:0x4a848], , ]
“#\n”
[[#IO:0x4a848], , ]
“127.0.0.1\tlocalhost \n”
[[#IO:0x4a848], , ]
“172.17.100.124\tblue.mxim.com blue\n”
[[#IO:0x4a848], , ]
“\tparis.mxim.com loghost\n”
[[#IO:0x4a848], , ]
“172.17.100.5\tparis.mxim.com loghost\n”
[[#IO:0x4a848], , ]
“”
[[#IO:0x4a848], , ]
“”
[[#IO:0x4a848], , ]
“”
[[#IO:0x4a848], , ]

As you can see, once the lines in the file are exhausted, #select still
returns (it should block forever at that point) and it claims the
IO object has data ready to be read on it (it doesn’t). If I check for
f.eof? in the while loop, I can detect the end of the data.

Checking with #eof? when using Open3.popen3 is a bit trickier because
it is conceivable to me that I’d get an eof on stdout, but not stderr. Still
doable.

I can check in the while loop to see if I actuall read data. This really isn’t
a good solution.

I still think there is something wrong with the behavior of #select. It should
not return until there is data ready. Picture an IO.popen() call to
a long running process that periodically spits data, but only at 30
second intervals. The current behavior of #select will cause the loop
to run quite a lot of iterations doing nothing but noticing there
really wasn’t any data (your basic busy wait).

That’s why I think #select is broken, or I’m not using it right.

I should get a chance to play with this more tomorrow.

Any help/insight is greatly appreciated. Thanks.

Jeff.

···

On Thu, Aug 22, 2002 at 06:45:19AM +0900, Berger, Daniel wrote:

Jeff Putsch Email: putsch@mxim.com
Maxim Integrated Products Office: (503)547-2037
High Frequency CAD Engineering

3

Alan McConnel pointed me to this problem.

Having written the program I have some questions.
Is it in good ruby style?
How could it be improved?
Is there a way to trade RAM for speed?
How does it do arithmetic on very long strings w/o taking more
RAM?

John

Program follows:

=begin
Test the hypothesis that for any integer the process of adding it to
its reverse will eventually yield a palindrome, For example,
consider 69: 69+96=165;165+561=726;726+627=1353;1353+3531=4884

I rubified this and discovered this phenom:
The number 169 does not settle on a palindrome after
more than 62k tries. But while the program slows to two
tials a minute on a 233Mhz Pentiun, it does not increase
in RAM used. The length of the number generated
for a try is .41 times the try number. So attempt
62,000 involves adding 2 numbers 25,420 digits long.

     Actually, the program decreased in size after it had
     been running for a  short while. I imagine that the decrease
     came at a gc following the switch to bignuum.

=end

trylimit = 10
160.upto(170) do |j| # check 160 to 170 for
palindromeability

tststr = j.to_s # Would a reverse method for
bignum help?
palfound = false # unnecesary variable?

trylimit.times do |tries|
#puts tststr ############ trace
newstr = (tststr.to_i + tststr.reverse.to_i).to_s
if newstr == newstr.reverse
#print " pal ", newstr, “\n” ############# trace
palfound = true
break
else
tststr = newstr
end
end
print j, " No palindrome in “, trylimit, " tries.\n” unless
palfound
end

4

An article on slashdot recently pointed out that of all the numbers under
10000 (could have been heaps more…), only one number had not been
“solved”. It was 196. Some bright spark has expanded it to numbers
containing millions of digits, and still no palindrome.

I think you made a typo in “169 does not settle on a palindrome after more
than 62k tries”, as my program testifies:

$ ./lycheral.rb 169
169
→ 169 + 961 = 1130
→ 1130 + 311 = 1441

In answer to your questions, I found your code difficult to follow, and
offer my own (written a few days ago) as an alternative. It does not do
the same thing, rather you saw an example of its usage just above. I
don’t know anything about performance of large number operations, however.

(Code at the bottom.)

Cheers,
Gavin

···

Alan McConnel pointed me to this problem.

Having written the program I have some questions.
Is it in good ruby style?
How could it be improved?
Is there a way to trade RAM for speed?
How does it do arithmetic on very long strings w/o taking more
RAM?

John

Program follows:

=begin
Test the hypothesis that for any integer the process of adding it to
its reverse will eventually yield a palindrome, For example,
consider 69: 69+96=165;165+561=726;726+627=1353;1353+3531=4884

I rubified this and discovered this phenom:
The number 169 does not settle on a palindrome after
more than 62k tries. But while the program slows to two
tials a minute on a 233Mhz Pentiun, it does not increase
in RAM used. The length of the number generated
for a try is .41 times the try number. So attempt
62,000 involves adding 2 numbers 25,420 digits long.

     Actually, the program decreased in size after it had
     been running for a  short while. I imagine that the decrease

came at a gc following the switch to bignuum.
=end

trylimit = 10
160.upto(170) do |j| # check 160 to 170 for
palindromeability

tststr = j.to_s # Would a reverse method for
bignum help?
palfound = false # unnecesary variable?

trylimit.times do |tries|
#puts tststr ############ trace
newstr = (tststr.to_i + tststr.reverse.to_i).to_s
if newstr == newstr.reverse
#print " pal ", newstr, “\n” ############# trace
palfound = true
break
else
tststr = newstr
end
end
print j, " No palindrome in “, trylimit, " tries.\n” unless
palfound
end

#!/usr/local/bin/ruby -w

A Lychrel number is one that DOES NOT form a palindrome

when it is added to its reverse.

class Numeric

14541 → true

1242345 → false

def palindrome?
self == self.reverse
end

754 → 457

def reverse
self.to_s.reverse.to_i
end
end

87 →

87 + 78 = 165 →

165 + 561 = 726 →

726 + 627 = 1353 →

1353 + 3531 = 4884, a palindrome

def lychrel_expansion(n)
puts n
until n.palindrome?
r = n.reverse
puts " → #{n} + #{r} = #{n += r}"
end
end

Handle arguments, which can be positive integers or

ranges.

for n in ARGV
case n
when /^\d+$/
lychrel_expansion(n.to_i)
puts “\n\n”
when /^(\d+)-(\d+)$/
range = $1.to_i … $2.to_i
for i in range
lychrel_expansion(i)
puts “\n”
end
end
end

5

“Gavin Sinclair” gsinclair@soyabean.com.au wrote in message news:36436.203.185.214.34.1029983451.squirrel@webmail.imagineis.com…

An article on slashdot recently pointed out that of all the numbers under
10000 (could have been heaps more…), only one number had not been
“solved”. It was 196. Some bright spark has expanded it to numbers
containing millions of digits, and still no palindrome.

Gavin,

I have stated in this post:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&c2coff=1&safe=off&selm=67828976.0207060804.7caff93c%40posting.google.com&rnum=1

that there are a lot of errors regarding the 196 number. To quote
myself:

“99% of the web pages on the Internet regarding the 196 Palindrome
Quest believe that 196 is the only number that does not solve out (or
the only number under 10,000 that does not solve out). This is not
true. Obviously, 691 (196 reversed), or 295 (the outer digits equal
the same sum: 1+6 = 2+5) both do not solve out either, because after
the first iteration of these numbers, they all result in the same sum
as 196 does after one iteration: 887 (and thus, 887 never solves out,
either, since it is the second step of the 196 sequence). Find more
about Lychrel numbers (numbers that do not solve out via
reversal-addition) on Wade’s pages: http://www.p196.org/”

Jason Doucette

6

Thanks for that.

I guess those numbers may not be so interesting after all (though that was
always in question). I knew that continuations of 196 (of which there are
perhaps 6 under 10000) wouldn’t appear to complete. I didn’t think of the
“other ways to get to 887” problem. I expect that would generalise, too: there
must be heaps of numbers that get caught up in 196’s web indirectly.

I’d like to know if there are any other starting points that have nothing to do
with 196 or its descendants. Do you know of any?

Gavin

···

----- Original Message -----
From: “Jason Doucette” JasonADoucette@hotmail.com
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Monday, September 02, 2002 1:38 AM
Subject: Re: Palindrome for integers

“Gavin Sinclair” gsinclair@soyabean.com.au wrote in message
news:36436.203.185.214.34.1029983451.squirrel@webmail.imagineis.com…

An article on slashdot recently pointed out that of all the numbers under
10000 (could have been heaps more…), only one number had not been
“solved”. It was 196. Some bright spark has expanded it to numbers
containing millions of digits, and still no palindrome.

Gavin,

I have stated in this post:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&c2coff=1&safe=off&selm=67828
976.0207060804.7caff93c%40posting.google.com&rnum=1

that there are a lot of errors regarding the 196 number. To quote
myself:

“99% of the web pages on the Internet regarding the 196 Palindrome
Quest believe that 196 is the only number that does not solve out (or
the only number under 10,000 that does not solve out). This is not
true. Obviously, 691 (196 reversed), or 295 (the outer digits equal
the same sum: 1+6 = 2+5) both do not solve out either, because after
the first iteration of these numbers, they all result in the same sum
as 196 does after one iteration: 887 (and thus, 887 never solves out,
either, since it is the second step of the 196 sequence). Find more
about Lychrel numbers (numbers that do not solve out via
reversal-addition) on Wade’s pages: http://www.p196.org/”

Jason Doucette
Jason Doucette - World Records - 196 Palindrome Quest, Most Delayed Palindromic Number

7

“Gavin Sinclair” gsinclair@soyabean.com.au wrote in message news:018301c251d0$0f3ba610$882386cb@nosedog…

Thanks for that.

I guess those numbers may not be so interesting after all (though that was
always in question).

Yes, once I realized that 196 was not the only number that never
resolves into a palindome (I, too, was tricked into believing that it
was, before I thought more about it), it became much less
interesting…

I knew that continuations of 196 (of which there are
perhaps 6 under 10000) wouldn’t appear to complete.

…but, once I realized that there are only 4 Lychrel Threads under
10,000 (meaning only 4 unique sequences which all other non-solving
numbers converge into), it made the problem very interesting once
again - since it means that there is something peculiar about these
numbers.

I didn’t think of the
“other ways to get to 887” problem. I expect that would generalise, too: there
must be heaps of numbers that get caught up in 196’s web indirectly.

I’d like to know if there are any other starting points that have nothing to do
with 196 or its descendants. Do you know of any?

Please visit Wade VanLandingham’s site:
http://www.p196.org/
Particularly, the Lychrel Records page:
http://home.cfl.rr.com/p196/lychrel.html
You will see that they have found 29,813 Lychrel Threads (unique
sequences which all other non-solving numbers converge into) for all
numbers under 1,000,000,000.

You may also be interested in my web site:

It shows my involvement of the 196 Palindrome Quest, but also my
search for the Most Delayed Palindromic Number. I hold the current
world record with:
100,120,849,299,260
It takes 201 iterations to resolve into a palindrome.
http://www.jasondoucette.com/cgi-bin/pal.cgi?100120849299260