Hi Boris, I think it takes too long to read through all of your
messages, so best to define a smaller proposal with exact details for
each feature you want.

On Sat, Apr 6, 2013 at 4:33 PM, boris_stitnicky (Boris Stitnicky)
<boris / iis.sinica.edu.tw> wrote:
>
> Issue #8223 has been updated by boris_stitnicky (Boris Stitnicky).
>
>
> So with another apology, I will use this space to write down a few more r=
emarks so that I do not forget about them. My line of thinking was as follo=
ws: The first step to the systematic solution of this problem would be to g=
eneralize zero. It means that the matrix elements would be required to be o=
f a class that has #zero method defined. As for Matrix.zero and Matrix.empt=
y, I think that there should be an option to tell them what this zero is (o=
r tell them the class that has #zero defined). Or perhaps we could play the=
 abstract algebra terminology and call it "additive_identity_element" inste=
ad of "zero". That would mean that Matrix would require its elements to com=
ply with at least monoid definition for matrix addition and multiplication,=
 and monoids necessarily need to have the additive identity element defined=
.
> ----------------------------------------
> Feature #8223: Make Matrix more omnivorous.
> https://bugs.ruby-lang.org/issues/8223#change-38316
>
> Author: boris_stitnicky (Boris Stitnicky)
> Status: Open
> Priority: Normal
> Assignee:
> Category:
> Target version:
>
>
> Let's imagine a class Metre, whose instances represent physical magnitude=
s in metres.
>
>     class Metre
>       attr_reader :magnitude
>       def initialize magnitude; @magnitude =3D 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
>     #=3D> 8.m
>     3.m * 2
>     #=3D> 6.m
>
> And with defined #coerce:
>
>     class Metre
>       def coerce other; [ self, other ] end
>     end
>
> Also this expression is valid:
>
>     2 * 3.m
>     #=3D> 6.m
>
> Before long, the user will want to make a matrix of magnitudes:
>
>     require 'matrix'
>     mx =3D Matrix.build 2, 2 do 1.m end
>     #=3D> 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 =3D Matrix.column_vector [1, 1]
>     mx * cv
>     #=3D> 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 su=
mmation 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 inst=
ances.
>
> In my real physical units library that I have written, I have solved this=
 problem by
> defining an =FCber zero object that produces the expected result, when su=
mmed with objects, that would otherwise not lend themselves to summation wi=
th ordinary numeric 0,
> and patching the Matrix class so that it uses this =FCber zero instead of=
 the ordinary one.
>
> But this is not a very systematic solution. Actually, I think that the Ma=
trix 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 n=
umeric 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 alm=
ost half a year, but I only gathered courage today to encumber you guys wit=
h this proposal. Please don't judge me harshly for it. I have actually alre=
ady seen something like this, in particular with bigdecimal's Jacobian (htt=
p://ruby-doc.org/stdlib-2.0/libdoc/bigdecimal/rdoc/Jacobian.html), which re=
quires that the object from which the Jacobian is computed implements metho=
ds #zero, #one, #two etc. Sorry again.
>
>
> --
> http://bugs.ruby-lang.org/
>