Matthew Moss
10/10/2008 8:29:00 PM
>
> Just a preview of my solution (inspired by TZFile):
>
> Mod26=ModularBase.new(26)
> Mod8=ModularBase.new(8)
>
> def test_incompat_bases
> assert_raises(ArgumentError) do
> Mod26.new(1)+Mod8.new(1)
> end
> assert_nothing_raised do
> Mod26.new(1)+Mod8.new(1).to_i
> end
> end
>
> That said, please clarify on the behavior of a couple tests:
>
> #new
> def test_add_reverse
> a = Mod26.new(15)
> assert_equal(???, 15 + a)
> end
>
> #new
> def test_sub_reverse
> a = Mod26.new(15)
> assert_equal(???, 1-a)
> end
>
> #already defined
> def test_mul_int_reverse
> a = Mod8.new(15)
> assert_equal(77, 11 * a)
> end
>
> Clearly a Modulo +/*/- an Integer should give a Modulo
> Should the reverse relation promote the Modulo to an Integer, or
> promote
> the Integer to a Modulo (of the same base)?
This issue requires some sort of design decision, which I
intentionally left out of the requirements, so you may do what you
like in this respect, and perhaps explain why you made a particular
choice.
When I started experimenting with my own solution, my design choice
was that the result type of any operation was the same as the first
operand. I did this primarily for simplicity, since I didn't need to
raise errors for incompatible bases, and most operations became
trivial. Of course, this choice is not without problem, since some
operations that might normally be communitive (if compatible modulo
was enforced) are no longer communitive.
In context with your questions above and my particular design choice:
1. I didn't raise any errors for mismatched bases; I used the left
operand to determine the result's type.
2. As all your reverse tests (which should be considered by all
implementors) have a left Integer argument, all the answers would be
the same, and the domain would be the full integer set. So, from top
to bottom, I would replace ??? with 30 and -14.