Ok, sure.


On Mon, Apr 21, 2014 at 7:55 PM, Kenta Takagaki <notifications@github.com>wrote:

> In src/main/scala/breeze/linalg/functions/CanPad.scala:
>
> > +
> > +/**
> > + * @author ktakagaki
> > + * @date 04/16/2014.
> > + */
> > +trait CanPadRight[Input, Dimensions, Output] {
> > +  def apply(v: Input, optDim: Dimensions, optMode: OptPadMode): Output
> > +}
> > +
> > +object CanPadRight {
> > +
> > +  // <editor-fold defaultstate="collapsed" desc=" DenseVector 1D padding ">
> > +
> > +  @expand
> > +  @expand.valify
> > +  implicit def implDV_OptPadDim[@expand.args(Int, Long, Float, Double) T]: CanPadRight[DenseVector[T], Dimensions1, DenseVector[T]] =
>
> Actually, I started out with that, but it doesn't quite work, in the
> following 3 ways:
>
>    1.
>
>    The implicit resolution of the option case classes doesn't seem to
>    work, i.e.
>    padRight(testDVD, 7, Value(10d) ) cannot find the Impl3[DenseVector[Double],
>    Int, OptPadMode, DenseVector[Double]] in the UFunc object
>    2.
>
>    Given that Ufunc already uses implicits, one can't do padRight(testDVD,
>    7, 10d ) and implicitly convert the last 10d to Value(10d)
>    3.
>
>    One cannot use named variable calls with the UFunc implicits: padRight(testDVD,
>    dimensions = 7, mode=Value(10d))... not quite relevant here, but would
>    be very convenient if I put in more options along the lines of the Numpy
>    pad function... there is not a natural argument order for their myriad of
>    options.
>
> What do you think?
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/scalanlp/breeze/pull/225/files#r11836450>
> .
>