When a and b are 1-dimensional sequences, numpy.cov(a,b)[0][1] is equivalent to your cov(a,b). The 2×2 array returned by np.cov(a,b) has elements equal to cov(a,a) cov(a,b) cov(a,b) cov(b,b) (where, again, cov is the function you defined above.)
Firstly, this is indeed how it works in C++: the return type of a virtual function in a derived class must be the same as in the base class. There is the special exception that a function that returns a reference/pointer to some class X can be overridden by a function that returns a reference/pointer … Read more
According to someone who may be in the know… The justification is that the advantage of covariance is outweighed by the disadvantage of clutter (i.e. everyone would have to make a decision about whether to use Task or ITask in every single place in their code). It sounds to me like there is not a … Read more
OK, I figured I should have my take on it, instead of just posting comments. Sorry, this is going to be long, if you want the TL;DR skip to the end. As Randall Schulz said, here _ is a shorthand for an existential type. Namely, class Foo[T <: List[_]] is a shorthand for class Foo[T … Read more
Think of it this way, if you were to do such a cast, and then add an object of type Foo to the list, the list of strings is no longer consistent. If you were to iterate the first reference, you would get a class cast exception because once you hit the Foo instance, the … Read more
With <out T>, you can treat the interface reference as one upwards in the hierarchy. With <in T>, you can treat the interface reference as one downwards in the hiearchy. Let me try to explain it in more english terms. Let’s say you are retrieving a list of animals from your zoo, and you intend … Read more
What about a generic base class? public class Poo { } public class RadioactivePoo : Poo { } public class BaseAnimal<PooType> where PooType : Poo, new() { PooType Excrement { get { return new PooType(); } } } public class Dog : BaseAnimal<Poo> { } public class Cat : BaseAnimal<RadioactivePoo> { } EDIT: A new … Read more
UPDATE: This answer was written in 2011. After two decades of people proposing return type covariance for C# they have been implemented. See Covariant Returns in https://devblogs.microsoft.com/dotnet/c-9-0-on-the-record/. It sounds like what you want is return type covariance. C# does not support return type covariance. Return type covariance is where you override a base class method … Read more
Set is invariant in its type parameter because of the concept behind sets as functions. The following signatures should clarify things slightly: trait Set[A] extends (A=>Boolean) { def apply(e: A): Boolean } If Set were covariant in A, the apply method would be unable to take a parameter of type A due to the contravariance … Read more
Variance will only be supported in a safe way – in fact, using the abilities that the CLR already has. So the examples I give in the book of trying to use a List<Banana> as a List<Fruit> (or whatever it was) still won’t work – but a few other scenarios will. Firstly, it will only … Read more