covariance

The below example compiles fine in regular Mono 2.10.9: namespace covarianttest { public interface ITest<out T> : IEnumerable<T> { } } However when I attempt compile it against MonoTouch 6.0.8 I receive this error: Error CS1961: The covariant type parameter 'T' must be invariantly valid on 'covarianttest.ITest' So am I to assume that MonoTouch doesn't support extending covariant/contravariant generic interfaces yet? If so what is the recommend workaround for this situation in MonoTouch? This actually depend on the compiler (and profile/runtime) not the Mono version. IOW some things might work

I have a generic class X<T> ; This class has a covariant part that I want to be able to access covariantly. So I factor it out into an interface IX<out T> . However, I want this interface to be visible only to the class itself, because it contains also methods that are ment to be private . I.e., inside the class itself, I can upcast to IX<T> and use it covariantly. E.g.: class X<T> : IX<T> { private interface IX<out T>{ // the private covariant interface void foo(); } // It grants access to the private method `foo` private T foo(){...} public T IX.foo(){ return foo(); } private static void

The Exact rules for variance validity are a bit vague and not specific. I'm going to list the rules for what makes a type valid-covariantly, and attach some queries and personal annotations to each of those rules. A type is valid covariantly if it is: 1) a pointer type, or a non-generic type. Pointers and non-generic types are not variant in C#, except for arrays and non-generic delegates. Generic classes, structs and enums are invariant. Am I right here? 2) An array type T[] where T is valid covariantly. So this means that if the element type T of an array T[] is covariant (reference or array

Is there a python statistical package that supports the computation of weighted covariance (i.e., each observation has a weight) ? Unfortuantely numpy.cov does not support weights. Preferably working under numpy/scipy framework (i.e., able to use numpy arrays to speed up the computation). Thanks a lot! statsmodels has weighted covariance calculation in stats . But we can still calculate it also directly: # -*- coding: utf-8 -*- """descriptive statistic with case weights Author: Josef Perktold """ import numpy as np from statsmodels.stats.weightstats import DescrStatsW np.random.seed(987467) x

I don't understand curve_fit isn't able to estimate the covariance of the parameter, thus raising the OptimizeWarning below. The following MCVE explains my problem: MCVE python snippet from scipy.optimize import curve_fit func = lambda x, a: a * x popt, pcov = curve_fit(f = func, xdata = [1], ydata = [1]) print(popt, pcov) Output \python-3.4.4\lib\site-packages\scipy\optimize\minpack.py:715: OptimizeWarning: Covariance of the parameters could not be estimated category=OptimizeWarning) [ 1.] [[ inf]] For a = 1 the function fits xdata and ydata exactly. Why isn't the error/variance 0 , or

I'm really enjoying working with C# 5.0 asynchronous programming. However, there are a few places where updating old code to be consistent with the TAP model is causing problems for me. Here's one of them - I'm not sure exactly why Task<TResult> is not covariant in TResult, but it's causing problems for me when trying to update a covariant interface to move from a synchronous to an asychronous pattern: Old code: public interface IInitializable<out T> // ** out generic modifier ** { /// <summary> /// Boolean to indicate if class is ready /// </summary> bool IsInitialized { get; } /// <summary>

Suppose I have these abstract classes Foo and Bar : class Foo; class Bar; class Foo { public: virtual Bar* bar() = 0; }; class Bar { public: virtual Foo* foo() = 0; }; Suppose further that I have the derived class ConcreteFoo and ConcreteBar . I want to covariantly refine the return type of the foo() and bar() methods like this: class ConcreteFoo : public Foo { public: ConcreteBar* bar(); }; class ConcreteBar : public Bar { public: ConcreteFoo* foo(); }; This won't compile since our beloved single pass compiler does not know that ConcreteBar will inherit from Bar , and so that ConcreteBar is a