From: "boris_stitnicky (Boris Stitnicky)" Date: 2013-04-09T03:42:02+09:00 Subject: [ruby-core:54117] [ruby-trunk - Feature #8223] Make Matrix more omnivorous. Issue #8223 has been updated by boris_stitnicky (Boris Stitnicky). marcandre (Marc-Andre Lafortune) wrote: > > If you stick with Metre class, like in this example, then coerce 0/1 to a homemade Scalar class (like Matrix does). > If you go for the more generic MagnitudeWithUnit, then coerce it to MagnitudeWithUnit(0, SCALAR) or something. > In both cases, it should work fine. I'll take a look at that Scalar, thanks. > Still, if you want to be serious about your library, 0 + 42.some_unit should work, and this is what you should focus on. I want to be serious about my library. I want to make it the best of something like 5 other Ruby unit libraries out there. I must admit that pragmatically, it saves keystrokes in the interactive mode, if the user is allowed to type 7.m.s����� + 1 #=> 8.m����� rather than of having to tediously type 7.m.s����� + 1.m.s����� It is a perilous feature, because the user needs to keep in mind... 7.km.h����� + 1 #=> 10.6.km.h����� ...what the standard unit of speed is 1.m.s�����, not 1.km.h�����. I still want to have this feature, but keep it optional, only when the user explicitly turns it on. The biggest problem with this feature is the necessary coerce behavior, which will have to return an advanced object with operator-specific behavior (#+, #-, #*, #/, #**, #== and whatnot) defined. I'll focus on this in the near future. It would seem that with 0, there would be no such problems, because `something + 0` is always `something`. But unfortunately, this does not hold well with units that have offsets, such as Celsius degrees. So the user would still have to keep in mind that 0 in the context of temperatures means 0.K rather than 0.��C. (Of course, filling matrix with Celsius temperatures is out of question, because only kelvins support addition, celsius + kelvins give celsius and celsius + celsius raise QuantityError.) ---------------------------------------- Feature #8223: Make Matrix more omnivorous. https://bugs.ruby-lang.org/issues/8223#change-38368 Author: boris_stitnicky (Boris Stitnicky) Status: Open Priority: Low Assignee: marcandre (Marc-Andre Lafortune) Category: lib Target version: Let's imagine a class Metre, whose instances represent physical magnitudes in metres. class Metre attr_reader :magnitude def initialize magnitude; @magnitude = magnitude end def to_s; magnitude.to_s + ".m" end end Let's say that metres can be multiplied by a number: class Metre def * multiplicand case multiplicand when Numeric then Metre.new( magnitude * multiplicand ) else raise "Metres can only be multiplied by numbers, multiplication by #{multiplicand.class} attempted!" end end end And that they can be summed up with other magnitudes in metres, but, as a feature, not with numbers (apples, pears, seconds, kelvins...). class Metre def + summand case summand when Metre then Metre.new( magnitude + summand.magnitude ) else raise "Metres can only be summed with metres, summation with #{summand.class} attempted!" end end end Now with one more convenience constructor Numeric#m: class Numeric def m; Metre.new self end end We can write expressions such as 3.m + 5.m #=> 8.m 3.m * 2 #=> 6.m And with defined #coerce: class Metre def coerce other; [ self, other ] end end Also this expression is valid: 2 * 3.m #=> 6.m Before long, the user will want to make a matrix of magnitudes: require 'matrix' mx = Matrix.build 2, 2 do 1.m end #=> Matrix[[1.m, 1.m], [1.m, 1.m]] It works, but the joy does not last long. The user will fail miserably if ze wants to perform matrix multiplication: cv = Matrix.column_vector [1, 1] mx * cv #=> RuntimeError: Metres can only be summed with metres, summation with Fixnum attempted! # where 2.m would be expected In theory, everything should be O.K., since Metre class has both metre summation and multiplication by a number defined. The failure happens due to the internal workings of the Matrix class, which assumes that the elements can be summed together with numeric 0. But it is a feature of metres, that they are picky and allow themselves to be summed only with other Metre instances. In my real physical units library that I have written, I have solved this problem by defining an ��ber zero object that produces the expected result, when summed with objects, that would otherwise not lend themselves to summation with ordinary numeric 0, and patching the Matrix class so that it uses this ��ber zero instead of the ordinary one. But this is not a very systematic solution. Actually, I think that the Matrix class would be more flexible, if, instead of simply using 0, it asked the elements of the matrix what their zero is, as in: class << Metre def zero; new 0 end end But of course, that would also require that ordinary numeric classes can tell what their zero is, as in: def Integer.zero; 0 end def Float.zero; 0.0 end def Complex.zero; Complex 0.0, 0.0 end # etc. I think that this way of doing things (that is, having #zero methods in numeric classes and making Matrix actually require the class of the objects in it to have public class method #zero defined) would make everything more consistent and more algebra-like. I am having this problem for already almost half a year, but I only gathered courage today to encumber you guys with this proposal. Please don't judge me harshly for it. I have actually already seen something like this, in particular with bigdecimal's Jacobian (http://ruby-doc.org/stdlib-2.0/libdoc/bigdecimal/rdoc/Jacobian.html), which requires that the object from which the Jacobian is computed implements methods #zero, #one, #two etc. Sorry again. -- http://bugs.ruby-lang.org/