[#66126] Creation/Conversion methods/functions table for Ruby types — SASADA Koichi <ko1@...>
Hi,
5 messages
2014/11/07
[#66248] [ruby-trunk - Feature #10423] [PATCH] opt_str_lit*: avoid literal string allocations — normalperson@...
Issue #10423 has been updated by Eric Wong.
3 messages
2014/11/13
[#66595] [ruby-trunk - Bug #10557] [Open] Block not given when the argument is a string — bartosz@...
Issue #10557 has been reported by Bartosz Kopinski.
3 messages
2014/11/30
[ruby-core:66249] [ruby-trunk - Feature #9528] mathn.rb library
From:
martin.vahi@...1.com
Date:
2014-11-13 07:01:27 UTC
List:
ruby-core #66249
Issue #9528 has been updated by Martin Vahi.
I wasn't aware of the existence of the gamma function before reading Your comment. I guess I got a bit smarter due to Your comment. Thank You for that. :-)
According to some sources, including the
http://mathworld.wolfram.com/GammaFunction.html
it seems to me that the gamma function is an approximation. I think that a clean solution for functions that are based on approximations should always have a maximum error size as a second argument. For example,
sin(x)
is actually calculated through series and is never absolutely correct. Therefore the
sin(x)
cos(x)
gamma(x)
etc...
should be
sin(x,absolute_value_of_max_error=<some default value>)
cos(x,absolute_value_of_max_error=<some default value>)
gamma(x,absolute_value_of_max_error=<some default value>)
etc...
The IEEE_754
https://en.wikipedia.org/wiki/IEEE_floating_point
determines some "default" error "size" through its rounding. Due to the exponent mechanism of the IEEE_754, the same property that gives
fd_big=(9**99).to_f
puts "No difference detected." if fd_big == (fd_big+1.to_f)
there is no single minimum approximation-result-changing value for the error size. Therefore, to find a clean solution for the proper implementation of the gamma/sin/cos/etc. function(s), further work has to be done and that's probably going to be pretty complex and time consuming. However, it is a fact that the current Math.gamma(x) implementation is flawed, because it gives IEEE_754 "infinity" for Math.gamma(10000). That probably limits cryptography related experiments.
The good news is that it seems (at least to me) that dependency wise factorial of integers is very general. Even some forms of the gamma(x) formulae depend on factorials of integers. That's why it seems to me that the proposed
Fixnum.factorial
Bignum.factorial
do not clutter the stdlib. That is to say, as of my current comment, I stick with my initial proposal.
Well, one way or the other, I still thank You all for Your answers and efforts. :-)
----------------------------------------
Feature #9528: mathn.rb library
https://bugs.ruby-lang.org/issues/9528#change-49928
* Author: Umair Amjad
* Status: Open
* Priority: Normal
* Assignee: Zachary Scott
* Category: lib
* Target version: current: 2.2.0
----------------------------------------
I want to add factorial method mathn.rb file as feature of Math module.
---Files--------------------------------
the_code.rb (7.49 KB)
run_demo.bash (591 Bytes)
--
https://bugs.ruby-lang.org/