coriolinus
commented
5 years ago I haven't used Haskell at all for half a decade, and I was only at a student level even then, so I'm going to attempt to recast this in Rust terms that I'm more familiar with. I think you're saying that the key fact about a resistor is that it has an Ohms value. Whether it's a single component, or a combination of other resistors, is immaterial.
In Rust, we'd express that like this:
pub trait Resistor {
fn ohms(&self) -> f64;
}We would then have students re-work their previous resistor implementation in terms of this trait:
impl Resistor for (Color, Color, Color) {
fn ohms(&self) -> f64 {
// students adapt existing work to fill this in
unimplemented!()
}
}We'd then have students write the composite types Serial and Parallel, which also implement Resistor and compute the appropriate resistances:
pub struct Serial {
rs: Vec<Box<dyn Resistor>>,
}
impl Resistor for Serial {
fn ohms(&self) -> f64 {
unimplemented!()
}
}
pub struct Parallel {
rs: Vec<Box<dyn Resistor>>,
}
impl Resistor for Parallel {
fn ohms(&self) -> f64 {
// students fill this in with existing work
unimplemented!()
}
}If I have understood you correctly, then I agree: this sounds like an interesting continuation of the resistor exercises.
WRT your additional thoughts:
-
The data type
Resistoris given as a newtype wrapper around(Color, Color, Color).I think this isn't actually true; it's a typeclass instead.
-
But that means there is no constructor for a resistor with infinite resistance
Wouldn't it be straightforward to define some zero-size-type implementing
Resistorwhich always returned positive infinite resistance? -
...some composite resistors don't have such a representation
That's because Resistor shouldn't be a newtype wrapper, but a typeclass/trait.
-
...this representation has another bad property
I don't see what's wrong with saying that nonequal resistors can have equal resistance
yawpitch
sshine
This exercise is proposed in the context of the Haskell track, but I'm posting it here because I like the idea of sharing exercise ideas across, and monoid abstractions exist in other languages, too. In the process of porting resistor-color-trio in exercism/haskell#869, it occurred to me that resistors are monoids in two ways:
When you put them in series, they form an additive monoid (resistance adds up) with (black, black, black), better known as a wire, as the identity resistor. And when you put them in parallel, you don't exactly get a multiplicative monoid, since n resistors in parallel add up like 1/R = 1/R₁ + 1/R₂ + ... + 1/Rₙ. What's the identity resistor for a parallel circuit?
It isn't a wire, since then the current would follow the path of least resistance, which would always end up being the wire. A neutral resistor in a parallel circuit is any non-conductive material with infinite resistance. For example, my willingness to code in another language than Haskell.
Putting resistors in series and in parallel is neat in practice for making non-standard resistors or when you run out of a certain kind of resistor.
Haskell has some machinery for dealing with types that are monoids in more than one way: while one can define
instance Monoid (Sum Resistor) where ...for the built-inSumtype, it seems necessary to define one's ownParalleltype and makeinstance Monoid (Parallel Resistor) where ...instead.Having this exercise in succession of resistor-color-trio leads to interesting thoughts:
Resistoris given as a newtype wrapper around(Color, Color, Color).But that means some composite resistors don't have such a representation:
But that's okay, because this representation has another bad property:
(We don't compare
Resistors for equality in -trio, so we live with it there.)