Aplicativo sin un functor

Question

Tengo un tipo Image que es básicamente una c-matriz de flotadores. Es fácil crear funciones como map :: (Float -> Float) -> Image -> Image, o zipWith :: (Float -> Float -> Float) -> Image -> Image -> Image.

Sin embargo, tengo la sensación de que también sería posible proporcionar algo que se parece a una instancia aplicativo en la parte superior de estas funciones, lo que permite manipulaciones a nivel de píxel más flexibles como ((+) <$> image1 <*> image2) o ((\x y z -> (x+y)/z) <$> i1 <*> i2 <*> i3). Sin embargo, el enfoque ingenuo falla, ya que el tipo de imagen no puede contener elementos distintos de flotantes, por lo que es imposible implementar fmap como tal.

¿Cómo podría implementarse esto?

Answer 1

Al leer los comentarios, estoy un poco preocupado de que el tamaño esté debajo de la alfombra aquí. ¿Hay un comportamiento sensato cuando los tamaños no coinciden?

Mientras tanto, puede haber algo que pueda hacer con sensatez en las siguientes líneas. Incluso si sus matrices no son fáciles de hacer polimórficas, puede hacer una instancia Applicative como esta.

data ArrayLike x = MkAL {sizeOf :: Int, eltOf :: Int -> x} 

instance Applicative ArrayLike where 
    pure x     = MkAL maxBound (pure x) 
    MkAL i f <*> MkAL j g = MkAL (min i j) (f <*> g) 

(Los entusiastas en cuenta que me he tomado el producto de la (Int ->) aplicativo con la inducida por el maxBound, min) monoide (.)

podría hacer una correspondencia limpia

imAL :: Image -> ArrayLike Float 
alIm :: ArrayLike Float -> Image 

por proyección y tabulación? Si es así, puedes escribir código como este.

alIm $ (f <$> imAL a1 <*> ... <*> imAL an) 

Por otra parte, si se desea envolver ese patrón como un operador sobrecargado,

imapp :: (Float -> ... -> Float) -> (Image -> ... -> Image) 

es un ejercicio de programación estándar en la clase de tipos! (Pregunte si necesita más información).

El punto crucial, sin embargo, es que la estrategia de envoltura significa que no necesita simular con sus estructuras de matriz para poner la superestructura funcional en la parte superior.

Answer 2

¿Cómo esperaría realizar operaciones en píxeles en una imagen? Es decir, para ((+) <$> image1 <*> image2), ¿le gustaría realizar todas las operaciones en Haskell y construir una nueva imagen resultante, o tendría que llamar a las funciones C para hacer todo el procesamiento?

Si es la primera, la respuesta del cerdo es el enfoque que tomaría.

Si, en cambio, se requiere que todas las manipulaciones de imágenes se manejen a través de C, ¿qué tal crear una pequeña DSL para representar las operaciones?

Answer 3

que obtendrá un tipo de composición mucho más Image si se generaliza el tipo "pixel" de Float y se extienden desde finitos & discretas de dominio (arrays) a infinito & dominio continuo. Como una demostración de estas generalizaciones, consulte el documento Functional Images y una galería correspondiente de (muestreos finitos de) example images. Como resultado, obtiene instancias de Monoid, Functor, Applicative, Monad y Comonad. Además, los significados de estas instancias están completamente determinados por las instancias correspondientes para las funciones, que satisfacen el principio de clase semántica morfismos, como se describe en el documento Denotational design with type class morphisms. La sección 13.2 de ese documento describe brevemente las imágenes.