InfinityClass = Class.new
Infinity = InfinityClass.new
class << InfinityClass
def new; Infinity end
end
class InfinityClass
def method_missing(name, *args, &blk )
Infinity
end
def to_s; "biiig"; end
end
puts Infinity
puts Infinity + 1
puts 3 * Infinity
unfortunately in order to make the last work you have to redefine Fixnum#*
etc etc which does not
seem pratical and I suppose that Infinity should be returned under certain
circumstances which means that
in an expression like
a op b, b could easily be Infinity
Cheers
Robert
Infinity = " a heck of a long time"
# Sorry could not resist
I suppose you would like things like
Infinity * 3 = Infinity etc. etc.
···
On 7/22/06, hadley wickham <h.wickham@gmail.com> wrote:
Others have answered the main question here but it's worth noting for
the future that just because it says infinity doesn't mean a constant
exists with that name. Check this out:
irb(main):001:0> class A; end
=> nil
irb(main):002:0> class B; end
=> nil
irb(main):003:0> A, B = B, A
(irb):3: warning: already initialized constant A
(irb):3: warning: already initialized constant B
=> [B, A]
irb(main):004:0> A
=> B
irb(main):005:0> B
=> A
Does anyone know a definition for Infinity that does work on all
platforms? Here's what I use; I have no idea how robust it really is:
Infinity= begin
result= [ Float::MAX**Float::MAX, Float::MAX**2, Float::MAX*2].max
result.infinite? ? result : result=1.0/0
rescue: Float::MAX #maybe 1.0/0 doesn't work on some systems?
end unless defined? Infinity
#there's also this way:
999999999999999999999999999999999999999999999999e99999999999999999 #but stuff like that sometimes returns zero, so it doesn't seem as reliable.
#(plus it generates a warning)
···
On 7/22/06, Marcel Molina Jr. <marcel@vernix.org> wrote:
Others have answered the main question here but it's worth noting for
the future that just because it says infinity doesn't mean a constant
exists with that name. Check this out:
Yes, but a lot of languages provide some way of accessing the
"constants" that represent special floating point numbers: Inf, -Inf
and NaN
Facets has Infinity (actaully it was deprecated for a while until I
fixed. Your post inspired me to fix it, so it's now back in the very
latest version. Thanks!)
It uses the constant INFINITY. Is that cool? Or is there some sort of
general practice of using Inf?
Others have answered the main question here but it's worth noting for
the future that just because it says infinity doesn't mean a constant
exists with that name. Check this out:
Yes, but a lot of languages provide some way of accessing the
"constants" that represent special floating point numbers: Inf, -Inf
and NaN
I think Matz vetoed anything that required IEEE floating point a little while ago. So ... for Ruby code to use Inf, -Inf or NaN, there would need to be special care taken to maintain portability.
Facets has Infinity (actaully it was deprecated for a while until I
fixed. Your post inspired me to fix it, so it's now back in the very
latest version. Thanks!)
That's great! Thanks.
It uses the constant INFINITY. Is that cool? Or is there some sort of
general practice of using Inf?
> Yes, but a lot of languages provide some way of accessing the
> "constants" that represent special floating point numbers: Inf, -Inf
> and NaN
I think Matz vetoed anything that required IEEE floating point a little
while ago. So ... for Ruby code to use Inf, -Inf or NaN, there would
need to be special care taken to maintain portability.
Thanks for that explanation, although it does worry me a little, I
understand that getting floating point working precisely correctly
across multiple platforms is very hard.
> Facets has Infinity (actaully it was deprecated for a while until I
> fixed. Your post inspired me to fix it, so it's now back in the very
> latest version. Thanks!)
That's great! Thanks.
> It uses the constant INFINITY. Is that cool? Or is there some sort of
> general practice of using Inf?
> Yes, but a lot of languages provide some way of accessing the
> "constants" that represent special floating point numbers: Inf, -Inf
> and NaN
I think Matz vetoed anything that required IEEE floating point a little
while ago. So ... for Ruby code to use Inf, -Inf or NaN, there would
need to be special care taken to maintain portability.
Thanks for that explanation, although it does worry me a little, I
understand that getting floating point working precisely correctly
across multiple platforms is very hard.
Which is *precisely* why dozens of hard core applied mathematicians and computer scientists, the IEEE and SIAM (Society for Industrial and Applied Mathematics), and nearly every vendor of equipment intended for scientific computing, both large and small, developed and embraced the IEEE standards! Note that there are actually *two* IEEE standards. The one most of us think of is the 32-bit/64-bit one that's implemented in Intel hardware. However, there was another looser standard which did not specify bit for bit behavior but only the computational requirements. The IEEE floating point standards are happy exceptions to the rule that nothing good was ever designed by a committee.
Some important vendors of such equipment -- Cray, FPS and IBM -- adhered to neither of these standards. Digital/Compaq/HP adopted it for the Alphas but kept the Vax line at its historic format for compatibility. But *new* architectures almost entirely adopted IEEE -- there is little reason not to do so. At some point in the evolution of Ruby, the number of actual users of non-IEEE platforms will be negligible. Just out of curiosity, how many users of non-IEEE Ruby are there on this list, and what fraction of the total list membership does that represent? Feel free to decline to answer if you're in a classified shop.
In article <44C3B1F8.3040608@cesmail.net>,
"M. Edward (Ed) Borasky" <znmeb@cesmail.net> writes:
Some important vendors of such equipment -- Cray, FPS and IBM -- adhered
to neither of these standards. Digital/Compaq/HP adopted it for the
Alphas but kept the Vax line at its historic format for compatibility.
But *new* architectures almost entirely adopted IEEE -- there is little
reason not to do so. At some point in the evolution of Ruby, the number
of actual users of non-IEEE platforms will be negligible. Just out of
curiosity, how many users of non-IEEE Ruby are there on this list, and
what fraction of the total list membership does that represent? Feel
free to decline to answer if you're in a classified shop.