John, I hear you. I agree with you that type instability is not very helpful, and indicates problems with program design. However, I believe that provided the program cannot resolve the types properly (as it couldn't in the original design of my program, because I haven't provided declarations of variables where they were getting used, only in their data structure types that the compiler apparently couldn't see), the optimization for loop performance cannot be successful. It certainly wasn't successful in this case.
How would you solve the problem with storing a function and at the same time allowing the compiler to deduce what values it returns? In my case I store a function that always returns a floating-point array. However, it may return a constant value supplied as input to the constructor, or it may return the value provided by another function (that the user of the type supplied). So, the type of the return value is stable, but I haven't found a way of informing the compiler that it is so. Petr On Thursday, December 11, 2014 8:20:20 PM UTC-8, John Myles White wrote: > > > The moral of this story is: If you can't or won't declare every single > variable, don't do loops. They are likely to be a losing proposition. > > I don't think this lesson will serve most people well. It doesn't reflect > my experiences using Julia at all. > > My experience is that code that requires variable type declarations > usually suffers from a deeper problem that the variable declarations > suppress without solving: either (a) there's some insoluble source of > ambiguity in the program (as occurs when calling a function that's passed > around as a value and therefore not amenable to static analysis) or (b) > there's some subtle source of type instability, as happens sometimes when > mixing integers and floating point numbers. > > -- John > >
