I think the problem is in deciding "when do I use the equivalent of map?" and
"when do I convert as a whole object?" For example, if I say
convert(Image, A)
I'm not asking to convert each _element_ of A to an Image, I'm asking to
convert _A as a whole_ to an Image. But now let's say I had an array-of-
arrays; then I might wish this would convert each element of the outer array
to its own Image. Of course, this would go horribly awry if I had decided to
represent a single image as an array of 3-vectors (for r,g,b)---I'd get
something completely unexpected out of that.
So basically, once you can have arrays-of-arrays-of-arrays-of..., it gets to
be a little tricky to read the mind of whoever called that function.
That said, there is a place for convenience functions that make certain
assumptions, especially in limited domains. Images, in fact, does that. But
the base convert function, being so fundamental to so many things, is
purposefully a bit finicky.
--Tim
On Friday, October 10, 2014 12:54:57 PM David van Leeuwen wrote:
> Hi,
>
> I seem to need convert() a lot, and especially for arrays this is somewhat
> of a nuisance. E.g.,
>
> convert(Float32, rand(2,3))
>
> does not work out of the box. Luckily, for the numeric types there are the
> functions float64(), float32() etc that can operate on arrays. This is all
> good, but for parameterized functions/types that need to convert to type T
> <: Real it seems a bit of a hassle to find the accompanying convenience
> function for type T.
>
> So I wonder, would it be possible to include in Base a function
>
> convert(T::Type) = <the convenience function for T>
>
> so that you could say
>
> t = Float32
> convert(t)(randn(2,3))
>
> My current solution for such conversion is
>
> map(x->convert(t,x), randn(2,3))
>
> but that doesn't seem great.
>
> An alternative would be to include in Base a number of declarations like
>
> convert(Float32, x) = float32(x)
>
> What is your view on this?
>
> ---david
