Yup. Thanks Kristoffer. I did a few more little things in julia and
figured it out before I saw your post:
function(x::Real, y::Real)
return 2x - y
end
function(x::Real, y::Array{Real, 1})
return 2x - y[1]
end
First one works; second one does not.
It is the use of Array, a compound object. I guess that means types aren't
covariant (is that the right term?). It's unfortunate. ML and some of the
lisps would probably handle it. It's not a big deal. It is documented but
you sort of have to put a few concepts together. It's sort of cool that
the parametric type function signature DOES work. Less familiar concept to
code, but the user of the method doesn't see it.
On Thursday, October 8, 2015 at 2:43:08 AM UTC-7, Kristoffer Carlsson wrote:
>
> There is a difference between an abstract type like Number and a type
> parameterized by an abstract types like Vector{Number}.
>
> While it is true that for example Float64 is a subtype of Number it is not
> true that Vector{Float64} is a subtype of Vector{Number}.
>
>
>
> On Thursday, October 8, 2015 at 11:35:05 AM UTC+2, [email protected]
> wrote:
>>
>> Thanks Tomas, but what you are saying seems to violate the manual.
>>
>> Here is the verbatim example:
>>
>> (from Chapter 12, "Methods", page 104)
>>
>> As you can see, the arguments must be precisely of type Float64. Other
>> numeric types, such as integers or 32- bit floating-point values, are not
>> automatically converted to 64-bit floating-point, nor are strings parsed as
>> numbers. Because Float64 is a concrete type and concrete types cannot be
>> subclassed in Julia, such a definition can only be applied to arguments
>> that are exactly of type Float64. It may often be useful, however, to
>> write more general methods where the declared parameter types are abstract:
>>
>>
>> julia> f(x::Number, y::Number) = 2x - y;
>>
>> julia> f(2.0, 3)1.0
>>
>>
>> This method definition applies to any pair of arguments that are
>> instances of Number. They need not be of the same type, so long as they
>> are each numeric values. The problem of handling disparate numeric types is
>> delegated to the arithmetic operations in the expression2x - y.
>>
>>
>> Can't see how that is different than my use of the abstract type Real.
>> In fact, the above example from the manual naturally works with Real.
>>
>>
>> Is there something special about one-line function definitions?
>>
>> I think my objection stands unless there are more rules or I missed
>> something and defined the function incorrectly or did the type restriction
>> incorrectly.
>>
>> Still confused.
>>
>
