[#25257] [Bug #2030] Math.gamma(x) seg faults for integer x larger than 2<<63-1 — Hiro Asari <redmine@...>
Bug #2030: Math.gamma(x) seg faults for integer x larger than 2<<63-1
[#25272] [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Yui NARUSE <redmine@...>
Feature #2032: Change the license to "GPLv2+ or Ruby's original".
Issue #2032 has been updated by Kazuhiko Shiozaki.
On Fri, Sep 4, 2009 at 1:10 PM, Kazuhiko Shiozaki<redmine@ruby-lang.org> wrote:
Hi,
If readline's change in license is the primary reason for reevaluating
Issue #2032 has been updated by Eric Hodel.
Issue #2032 has been updated by Shyouhei Urabe.
Issue #2032 has been updated by Shyouhei Urabe.
Hi,
> To avoid enbugging a new bug, we must choose the another solutions.
2010/6/6 Urabe Shyouhei <shyouhei@ruby-lang.org>:
(2010/06/06 20:27), Yusuke ENDOH wrote:
Hi,
On Tue, Jun 8, 2010 at 09:12, Yusuke ENDOH <mame@tsg.ne.jp> wrote:
Hi,
On Jun 14, 2010, at 22:48, Yusuke ENDOH wrote:
[#25275] Ruby platform interface — vondruch@...
On Wed, Sep 2, 2009 at 11:17 AM, <vondruch@amberg.cz> wrote:
Excerpts from message of Wed Sep 02 13:03:22 +0300 2009:
[#25285] [Feature #2033] Move Core Development to Git — Run Paint Run Run <redmine@...>
Feature #2033: Move Core Development to Git
On Sep 2, 2009, at 11:19, Run Paint Run Run wrote:
>> * Opens Ruby development to a wider range of contributors. Ruby- and
On Wed, Sep 2, 2009 at 4:29 PM, Eric Hodel<drbrain@segment7.net> wrote:
On Wed, Sep 2, 2009 at 19:50, Jeremy Kemper <jeremy@bitsweat.net> wrote:
Short summary:
On Sat, Sep 5, 2009 at 4:54 PM, Ron
On Sat, Sep 5, 2009 at 16:43, Rick DeNatale <rick.denatale@gmail.com> wrote:
Run Paint Run Run wrote:
Issue #2033 has been updated by Yui NARUSE.
> Some commiter of Ruby live on Windows.
Jon wrote:
2009/9/4 Urabe Shyouhei <shyouhei@ruby-lang.org>:
Michal Suchanek wrote:
2009/9/4 Urabe Shyouhei <shyouhei@ruby-lang.org>:
The point I suspect that a lot of those pushing for the move to git
On Sep 4, 2009, at 12:51 PM, Eleanor McHugh wrote:
Issue #2033 has been updated by Yukihiro Matsumoto.
Ruby is a basic infrastructure that needs to be stable. If it goes as agile as
[#25306] [Feature #2034] Consider the ICU Library for Improving and Expanding Unicode Support — Run Paint Run Run <redmine@...>
Feature #2034: Consider the ICU Library for Improving and Expanding Unicode Support
[#25360] [Bug #2043] incompatible character encodings — Vit Ondruch <redmine@...>
Bug #2043: incompatible character encodings
[#25367] [Bug #2048] Thread#raise: Handling of Current Exception — Run Paint Run Run <redmine@...>
Bug #2048: Thread#raise: Handling of Current Exception
[#25394] Unmaintained code (Was: Move Core Development to Git) — Eric Hodel <drbrain@...7.net>
On Sep 4, 2009, at 02:16, Urabe Shyouhei wrote:
I'll volunteer to maintain delegate.rb.
I'll volunteer to maintain English.rb and tempfile.rb.
I would gladly maintain find, observer & ostruct if that can be of any
I think that one responsibility of maintainers of a component should be
On Sat, Sep 5, 2009 at 1:59 AM, Eric Hodel<drbrain@segment7.net> wrote:
[#25420] [Bug #2054] Onigurma Isn't Documented — Run Paint Run Run <redmine@...>
Bug #2054: Onigurma Isn't Documented
[#25442] turning off indentation warnings — Aaron Patterson <aaron@...>
Is there a way in 1.9 to turn off only indentation warnings? I like
Hi,
Hi,
On Sep 22, 2009, at 8:19 PM, Nobuyoshi Nakada wrote:
On Sep 24, 2009, at 12:01 PM, Aaron Patterson wrote:
>>>> I've looked into adding a global variable. I think it looks better,
[#25506] [Bug #2072] Segmentation faults with libxml-ruby and ruby 1.9.1 — 賢司 高橋 <redmine@...>
Bug #2072: Segmentation faults with libxml-ruby and ruby 1.9.1
[#25540] [Bug #2095] Oniguruma No Longer Understands Unihan Characters — Run Paint Run Run <redmine@...>
Bug #2095: Oniguruma No Longer Understands Unihan Characters
[#25571] Implicit block argument in Procs — Cody Brocious <cody.brocious@...>
I ran into some block behavior I thought was a bit odd. Calling a
[#25587] Minimalist Ruby Install for Windows — Mike Hatfield <oakraven13@...>
Hi everyone,
[#25630] [Bug #2114] Array Hash inconsistency — Wim Yedema <redmine@...>
Bug #2114: Array Hash inconsistency
[#25632] [Bug #2117] Binding to a class, a method from the class's superclass's metaclass, fails — "Shane O'Brien" <redmine@...>
Bug #2117: Binding to a class, a method from the class's superclass's metaclass, fails
[#25634] Kernel.eval("local_variables",binding) bug in Ruby 1.9 — Howard Yeh <hayeah@...>
Hi,
[#25635] [Bug #2119] 'gem' method has problem when gems are in ~/.gem and no version requirement is given — Cezary Baginski <redmine@...>
Bug #2119: 'gem' method has problem when gems are in ~/.gem and no version requirement is given
Issue #2119 has been updated by Cezary Baginski.
[#25644] [Bug #2121] mathn/rational destroys Fixnum#/, Fixnum#quo and Bignum#/, Bignum#quo — Charles Nutter <redmine@...>
Bug #2121: mathn/rational destroys Fixnum#/, Fixnum#quo and Bignum#/, Bignum#quo
Charles Nutter wrote:
On Sat, Sep 19, 2009 at 12:28 AM, Joel VanderWerf
Hi,
On Sun, Sep 20, 2009 at 3:29 AM, brian ford <brixen@gmail.com> wrote:
[#25679] Ruby 1.9 pack('m') and unpack('m') not round tripping — Mikel Lindsaar <raasdnil@...>
Hello all,
[#25681] [Bug #2127] Fiber#resume - segfault inside C extension — Suraj Kurapati <redmine@...>
Bug #2127: Fiber#resume - segfault inside C extension
[#25709] [Bug #2131] f(not x) => syntax error — "James M. Lawrence" <redmine@...>
Bug #2131: f(not x) => syntax error
Issue #2131 has been updated by James M. Lawrence.
[#25756] syck maintenance? — Ryan Davis <ryand-ruby@...>
Has anyone taken this over?
Ryan Davis wrote:
There are about 15 open issues relating to yaml/syck.
[#25764] [Proposal] Maintainer confirmation and discharging process — Yugui <yugui@...>
2009/9/25 Marc-Andre Lafortune <ruby-core-mailing-list@marc-andre.ca>:
Hi,
[#25769] A challenge: Enumerator#next in JRuby — Charles Oliver Nutter <headius@...>
I have a challenge for anyone who wants to discuss, propose
In article <f04d2210909251312q46bd51c0teacc4b0a8c417f0c@mail.gmail.com>,
On Fri, Sep 25, 2009 at 8:57 PM, Tanaka Akira <akr@fsij.org> wrote:
In article <f04d2210909252208k4fd66540u54a5d280613bb043@mail.gmail.com>,
On Sat, Sep 26, 2009 at 6:38 AM, Tanaka Akira <akr@fsij.org> wrote:
On Sat, Oct 17, 2009 at 3:31 PM, Charles Oliver Nutter
For what it's worth, although solution 3 is not very pretty, it could
Hi,
On Fri, Sep 25, 2009 at 7:35 PM, Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
[#25796] [Bug #2144] Split functionality of Float#inspect and Float#to_s — Roger Pack <redmine@...>
Bug #2144: Split functionality of Float#inspect and Float#to_s
[#25820] [Feature #2152] Split functionality of Float#inspect and Float#to_s — Roger Pack <redmine@...>
Feature #2152: Split functionality of Float#inspect and Float#to_s
Issue #2152 has been updated by Marc-Andre Lafortune.
> Issue #2152 has been updated by Marc-Andre Lafortune.
Hi,
Hi,
Issue #2152 has been updated by Roger Pack.
Hi,
Hi,
[#25831] event hook in 1.9? — Ryan Davis <ryand-ruby@...>
> /**
Ryan Davis wrote:
[#25841] [ANN] Ruby Developer's Meeting 20091013 — Yugui <yugui@...>
Hi,
[#25853] [Bug #2160] JSON can't parse input where top-level object is a string — caleb clausen <redmine@...>
Bug #2160: JSON can't parse input where top-level object is a string
Issue #2160 has been updated by Tim Bray.
Tim Bray wrote:
[#25865] struggling to convince myself 1.9's constant lookup rules make any sense — "ara.t.howard" <ara.t.howard@...>
[#25876] Fate of Win32API.rb? — Jon <jon.forums@...>
Spelunking the ruby-core Nabble archives and Redmine hasn't yet shed any
Hello,
[ruby-core:25624] [Bug #1532] Improved matrix.rb [patch]
Issue #1532 has been updated by Marc-Andre Lafortune.
File f_matrix_access.diff added
File a_matrix_creation.diff added
File b_matrix_empty.diff added
File c_matrix_trace.diff added
File d_matrix_cleanup.diff added
File e_matrix_enum.diff added
Here is my previous patch simplified and broken down in 6 successive patches (a-f)
*** Summary ***
The following changes are completely compatible for code that used the library in a mathematically sound manner. Potential incompatibilities would arise only for usage that does not make mathematical sense.
* API changes *
(a) Argument checking for matrix creations
Current: "although matrices should theoretically be rectangular, this is not enforced by the class" (as per documentation)
Change to: "matrices must be rectangular, otherwise an ErrDimensionMismatch is raised."
This would make the library behave in a sane manner, with error messages that are dependable and follow the established principle of detecting errors early [ruby-core:23664]
Patch attached: a_matrix_creation.diff
(b) Handle edge case Matrices
Like Mathematica, MatLab and others, the library should deal properly with matrices with a number of columns or rows of 0.
Patch attached: b_matrix_empty.diff
(c) Matrix#trace should raise an ErrDimensionMismatch if the matrix is not square
Mathematically speaking, the trace is only defined for square matrices (ref: wikipedia, mathworld)
Raising an ErrDimensionMismatch would bring #trace in line with #inverse
Patch attached: c_matrix_trace.diff
(d) Matrix#compare_by_row_vectors, Vector#compare_by and Vector#init_elements should be made private or disappear.
As per the documentation, these are not meant to be used.
Patch attached: d_matrix_cleanup.diff
* Compatible API changes *
(e) Enumerators should be returned when no blocks are given for methods like #map, etc...
This would bring the library in line with Ruby 1.8.7+ which returns enumerators in such cases
Patch attached: e_matrix_enum.diff
(f) Consistent results when accessing elements with out of bounds indices.
This would make the library in line with Ruby 1.8.7+ which returns enumerators in such cases
Patch attached: f_matrix_access.diff
*** Detailed examples of problems ***
(a) Argument checking for matrix creations
1) Plain wrong arguments:
Matrix[nil] # => no expection is raised
Matrix[:hello] # => no expection is raised
Matrix[4] # => no expection is raised
Later on, confusing results or strange errors will happen. My two favorites:
Matrix[:hello].rank # ==> NoMethodError: undefined method `quo' for "e":String
Matrix[42].transpose # ==> Matrix[[0], [1], [0], [1]]
# or Matrix[[0], [1], [0], [1], [0], [1], [0], [0]]
# (depending on the platform)
2) Most methods will result the wrong result or raise an unintuitive error in case of uneven rows
Matrix[[1,2],[3]].rank # ==> NoMethodError: undefined method `-' for nil:NilClass
Matrix[[0,0],[0,0]] + Matrix[[1,2], [3,4,5,6,7,8]] # ==> does not raise error
Matrix[[1,2],[3]].square? # ==> true
3) Array-like arguments
Moreover, basic conversion to arrays should be attempted, in particular from Vectors:
a = Matrix[[1,2],[3,4]] # => Matrix[[1, 2], [3, 4]]
b = Matrix.rows([a.row(0), a.row(1)]) # => Matrix[Vector[1, 2], Vector[3, 4]]
a == b # => false
The attached patch matrix_creation.diff changes the behaviour and documentation to insure that arguments passed to the Matrix creators are correct.
(related to redmine issues #1517, 1515)
(b) Handle edge case Matrices
Matrix[].row_size # ==> 0, ok!
Matrix[].column_size # ==> raise an error, should be 0
Matrix[].determinant # ==> raise an error, should be 1
m = Matrix[[], []]
m.transpose.transpose == m # ==> false, should be true for any m
While an alternative would be to raise and error, the best solution is to handle empty matrices properly, both 0x0, 0xn and nx0, as does Mathematica, MatLab, GNU Octave, etc...
See doc and references to the literature in:
http://www.gnu.org/software/octave/doc/interpreter/Empty-Matrices.html
(c) Matrix#trace should raise an ErrDimensionMismatch if the matrix is not square
Matrix[[1],[2]].trace # ==> returns 1, which makes no sense mathematically
Matrix[[1,2]].trace # ==> raises a NoMethodError: undefined method `[]' for nil:NilClass
(d, e) Enumerators should be returned when no blocks are given for methods like #map, etc...
No additional comment
(f) Consistent results when accessing elements with out of bounds indices.
m = Matrix[[1]] # Example with 1x1 matrix
m[2,0] # ==> NoMethodError: undefined method `[]' for nil:NilClass
m[0,2] # ==> nil
m.row(2) # ==> TypeError: can't dup NilClass
m.column(2) # ==> Vector[nil]
m.minor(2..2, 0..0) # ==> NoMethodError: undefined method `collect' for nil:NilClass
m.minor(0..0, 2..2) # ==> Matrix[nil]
Accessing elements should behave in a consistent way if either row or col is out of bounds
Moreover, Matrix[nil] is not a matrix!
Solutions:
1) To be consistent with array lookup using [], Matrix#[] should return nil for out of bounds elements.
2) #row, and #column should return nil, to be coherent with with Array#at, etc... and be most useful.
3) The same way Matrix#row and #col can be related to Array#at,
Matrix#minor should have similar semantics to Array#slice. If either starting point
is out of bounds, nil is returned. Otherwise a Matrix is returned, although it can
be smaller than what was requested. This is similar to
[:a, :b].slice(3..10) # => nil
[:a, :b].slice(2..10) # => []
[:a, :b].slice(1..10) # => [:b]
Matrix[[1], [2]].minor(0..10, 2..10) # => nil
Matrix[[1], [2]].minor(0..10, 1..10) # => Matrix[[], []]
Matrix[[1], [2]].minor(1..10, 0..10) # => Matrix[[2]]
(see redmine #1518)
Cleanup, optimizations and bug fixes present in the original patch have already been committed.
*** Closing notes ***
Numerous and very basic bugs have been present for a long time (issues #1020, 1531, 2106, 2107, 2108 all fixed in upcoming versions of Ruby). This seem to indicate that very few people, if any, actually use the matrix library.
Nevertheless I believe that fixing it is important. Moreover I think we should not hesitate in modifying the API for edge cases as long as maintain compatibility for the potential few users using the library correctly.
I would be happy and honored to be the maintainer of this library.
----------------------------------------
http://redmine.ruby-lang.org/issues/show/1532
----------------------------------------
http://redmine.ruby-lang.org