# Modular Arithmetic (#179)

**URL:** <https://www.ruby-forum.com/t/modular-arithmetic-179/151124>\
**Category:** Ruby\
**Created:** [October 17, 2008, 4:48am UTC](https://www.ruby-forum.com/t/modular-arithmetic-179/151124 "2008-10-17T04:48:03Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![mansfiem](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/fbc32d/32.png) [@mansfiem](https://www.ruby-forum.com/u/mansfiem)\
**Post date:** [October 17, 2008, 4:48am UTC](https://www.ruby-forum.com/t/modular-arithmetic-179/151124/1 "2008-10-17T04:48:03Z")

</div>

Apologies for the severely late summary.

I’m going to examine the solution from _Andrea F._ for this week’s  
quiz. It’s quite simple and easy to follow, and it is quite similar to  
some of the other solutions. (Note that I’ll examine this in a  
different order than Andrea’s presentation, but it does not affect the  
solution.)

First, initialization:

```
 class Modulo

   def initialize(n = 0, m = 26)
     @n, @m = n % m, m
   end

   def to_i
     @n
   end

```

This is pretty straightforward; Andrea stores the numeric value and  
the modulus, and provides a way to convert the class to an integer. As  
`@n` is returned without using the modulus operator, care must be  
taken to always assign `@n` correctly. The initializer does this, and  
is the only assignment to `@n` here, so it’s safe.

Next, comparison operations:

```
   include Comparable

   def <=>(other_n)
     @n <=> other_n.to_i
   end

```

Andrea makes use of the `Comparable` module, which supplies the  
various comparison operators provided the class provides the `<=>`  
operator. Since this is essentially dealing with integers, it simply  
performs the `<=>` on the integer portions. We know `@n` is an  
integer, and the call to `to_i` ensures the right-hand side is an  
integer as well.

Next, arithmetic:

```
   [:+, :-, :*, :**].each do |meth|
     define_method(meth) { |other_n| Modulo.new(@n.send(meth,

```

other\_n.to\_i), @m) }  
end

A nice little bit of metaprogramming is shown here. Andrea uses the  
`define_method` method defined on `Module`, of which `Class` is a  
subclass. (Confused yet?) Since each of the arithmetic operators will  
look basically the same, this removes redundancy and reduces the  
amount of code. The alternative would have been this:

```
   def +(other_n)
     Modulo.new(@n + other_n.to_i, @m)
   end

```

But repeat that for every operator. Using `define_method` inside the  
loop removes the redundant code and, potentially, will support other  
operators by simply adding them to the list. The only other cost, so  
to speak, is that you must use `send` to replace actual use of the  
operator, but this is certainly something every Ruby programmer knows,  
or should know.

If the class ended there, most basic use would be covered… at least  
until someone tried `3 + Modulo.new(5)` instead of `Modulo.new(5) + 3`. That’s because integers don’t know anything about the `Modulo`  
class. Fortunately, there is a nice technique available for dealing  
with this issue:

```
   private

   def coerce(numeric)
     [numeric, @n]
   end

 end

```

The example `3 + Modulo.new(5)` is equivalent to `3.send(:+, Modulo.new(5))`. The integer `3` doesn’t know what a `Modulo` object  
is, so it calls `coerce`. That is, `Modulo.new(5).coerce(3)`. It’s now  
the responsibility of `Modulo#coerce` to provide values that integer  
addition can deal with. As shown, Andrea returns an array of the  
original first argument (currently in `numeric`) and the value of the  
`Modulo` object (in `@n`). This is sufficient for integer addition to  
work, which will produce the expected value `8`.

So ends Andrea’s `Modulo` class. This design is similar to most of the  
others, and follows the convention I suggested on the mailing list:  
that the left argument of any arithmetic operation determines the  
result’s type. So `Modulo.new(5) + 3` generates a new `Modulo` object,  
while `3 + Modulo.new(5)` generates a new integer. Both have a value  
of 8, but this non-communitivity could potentially become confusing.  
Consider if you were adding two `Modulo` objects, one using a modulus  
of 26, the other a modulus of 10? What should the result be? Someone  
who didn’t know or expect the left-hand-side rule might get unexpected  
results.

The solution from _Ken B._ addresses this by providing  
`ModularBase`. This module provides:

1. A way to create “modulo” factories, to ease the creation of  
multiple values using the same modulus.
2. All the methods needed to perform arithmetic and comparisons.
3. A way to check that two modulo values were created from the same  
`ModularBase`.

The last ensures that confusion can’t occur when mixing bases. Such  
operations simply won’t work, and will instead throw an exception.  
Note that this does not completely prevent a developer from mixing  
bases, but he must now be explicit about it.

```
 Mod26 = ModularBase.new(26)
 Mod11 = ModularBase.new(11)

 a = Mod26.new(23)
 b = Mod11.new(179)
 puts a + b # This raises an incompatible bases

```

ArgumentError…

```
 puts a + b.to_i # ... but this is safe.

```

And Ken also promotes all operations involving integers to  
`ModularBase` instances as well, a nice feature. (See his `coerce` for  
how this works.)

Thanks for the submissions. Tomorrow, a little more “elementary”  
mathematics…