This is more complicated that with other types as Complex doesn't exist as far as the Java code knows. We solved this with Rational by implementing Fixnum + Rational as Rational + Fixnum - which I think for some reason is in fact the correct thing to do.

Where that isn't possible, like divide, we do convertToRational(Fixnum) + Rational.

@chrisseaton I can try to implement this if you haven't done so already

Yes please

It's probably much much easier now we have ruby() actually.

@chrisseaton Can you recommend how to add a Specialization like this for a non-core class? e.g. Matrix

How would the guard look? Would the specialization go in FIxnumNodes even though this is non-core?

I need a Fixnum#/ and I think this can be implemented in terms of Fixnum#* fixnum * matrix.inverse

I don't see why Fixnum#/ should have to know about a non-core class? In MRI the C code doesn't know about Matrix (I don't think it does), so why should our implementation?

I think you might find that through coercion, Fixnum / Matrix actually becomes Matrix / Matrix (or maybe something called Scala / Matrix), and it's not due to special casing of Matrix in Fixnum#/ - take a look in the Rubinius kernel at Numeric#redo_coerced and #math_coerce, and then Matrix#coerce.

We could do with a solid understanding of this - resist the temptation to special case for Matrix - I think there is a general solution in here somewhere.

@eregon @nirvdrum do you know anything about how this works?

@chrisseaton The spec that is failing is call the coerce_spec (library/matrix) so I think you are on the right track but I don't know where the coercion happens.

1 / Matrix[[0,1],[-1,0]]

Rubinius does

  def divide(o)
    Rubinius.primitive :fixnum_div
    redo_coerced :/, o
  end
  alias_method :/, :divide

Maybe look at adding a specialisation to Fixnum#/ that does redo_coerced :/, o.

Yes, this is just the coerce mechanism, actually even Rational and Complex do not need a special case, just Float and Integer (Fixnum and Bignum) since they don't coerce well between each other.
So there is Matrix#coerce, which returns a Scalar (a class defined by Matrix) and then Fixnum should just do the redo_coerced on it so 3 + matrix becomes Scalar.new(3) + matrix thanks to matrix.coerce(3).

I think it's even preferable to not have Rational/Complex specializations unless we need it, since the class check is imprecise and there is a better mechanism already defined by the normal semantics.

@chrisseaton Added redo_coerced to / here: dce0852 . Let me know if Rational/Complex should be removed.

Can you try removing them and see what happens? You need to try running any of the benchmarks as well (do bench debug to get the command, add --loop to the end and let it run for a while) as the Rubinius implementation of Time.now.to_f uses Rational and that gets pulled into what gets compiled for the benchmarks. If that seems ok and the specs pass it's fine to remove.

We don't use Time anymore I think, but the monotonic time. Also, if Process::CLOCK_MONOTONIC fails, Time#-(Time) is used which should have the proper optimization to not go by rational (converting time to float could additionally lose precision).