Comment Re:Forgot your meds, did you? (Score 1) 192
the joke was lame the first time I saw it, but WE'VE GOT IT NOW
what ever happened to the rule that pranks played after midday meant that the prankster was the fool?
some people at
the joke was lame the first time I saw it, but WE'VE GOT IT NOW
what ever happened to the rule that pranks played after midday meant that the prankster was the fool?
some people at
Probably because it's easier to express, recognise and optimise tail-recursion under the functional paradigm than the imperative space, especially true for the close-to-metal languages like C/C++.
Funnily enough though, I may be wrong about this, but I don't believe that the IL has very good at tail recursive performance, so proper tail recursion is only used after some stack usage heuristic has been breached....
The function syntax is essentially shorthand for match with a single argument - both are valid in F# (and OCaml).
Your example includes some distractions like bigint literals (0I and 1I), and uses pattern matching, which doesn't exist in Python.
You have to learn the language to be effective, the wikipedia article was showing the F#-onic way of writing it - it's perfectly possible to rewrite this in a more imperative form as:
let rec factorial n = if n=0I then 1I else n*factorial (n-1I)
but pattern matching is a key part of the language. The compiler can detect whether all possible pattern states have been caught, which it can't do with if/then/else statements.
As the other posters commented, it's not dynamically typed (but it is very generic), and the #light syntax is indentation sensitive (fortunately, tabs are banned, which was the initial bane of my Haskell writing days).
But, I do suspect that IronPython is not a featured language of VS2010 for precisely the reason you say. M$ probably want F# to gain some traction before officially adding IronPython to VS (if they ever do, that is). Python does have some great ideas inspired by functional languages, but it's in no way a functional programming language. Python doesn't impose any type constraints, but I think that F# takes the approach that a lot of functionality can be expressed with generics, and others must be strongly typed - but the language tries it's best to infer those types for you, so you can usually rely on this, unless things get ambiguous.
I really like the pipe operator for making a flow of data more explicit:
List.fold reduceFunc (List.map someFunc fooList)
vs
fooList |> List.map someFunc |> List.fold reduceFunc
Also, there's some interesting implications about what type information is visible in the first example and second (hint: someFunc and reduceFunc know nothing about the data types in the first example).
I agree - it is important to get away from the concept of evolution as being life-based, and recognise that evolution is an emergent property of a system.
For the prion example, the key is to remember that incorrectly folded proteins accumulate and cause the prion disease - the proteins themselves are not the disease, but the accumulation is. If one folding configuration is more likely to cause other proteins to fold incorrectly, then it is natural to assume that this configuration will become eventually dominant, until a more effective configuration arises. Also, the accumulation of protein causes a feedback loop, increasing the likelihood of further malign folding. Presumably, the folding is sometimes imperfect, so this is the source of the all important mutations causing variety. Without the accumulation, I would presume that the configuration of folding has a benign effect.
So, folding configurations that increase the rate of malign folds or increase the rate of accumulation would be more successful in this feedback loop. Does this really justify the tag 'evolutionary'? It just seems that the natural progression of the disease causes what appears to be a natural selection process, but it's not clear at what point we should distinguish between a feedback loop and an evolutionary process, if indeed they are actually one and the same thing...
Evolution is an emergent property of a system - I'd be careful to distinguish how you would build a model to describe the system that can evolve (as you have here), and what actually happens in empirical settings.
It could be argued that Darwin only 'discovered' evolution in the Galapagos Islands, as the classical theory of natural selection is particularly pronounced in the flora and fauna there, and why other pioneers such as Mendel didn't make the same intellectual leap (especially since he was actually examining the very mechanisms of genetic evolution).
Not often or even never, but you still have to understand the maths, even if you're not the one originating it.
I work as a desk-aligned quant developer, and although I'm not a mathematician, I still have the gist of what the models are capable of pricing and why. Even back-office aligned IT staff who look after the databases and infrastructure should at least be aware of what concepts like delta, vega, rho, etc., are - just to know what data to check might have be wrong/changed when a support request floats your way. You'd be surprised how often someone inputs a percentage field a factor of 100 out...
The Japanese artist Yugo Nakamura designed a piece with a similar theme... in digital!
It's funny how analog time is glacially slow and digital time is totally manic.
Despite attaining lower than predicted weight reduction, these individuals experienced significant increases in aerobic capacity (6.3 ±6.0ml.kg-1.min-1; P<0.01), decreased systolic (-6.00 ±11.5mmHg; P<0.05) and diastolic blood pressure (-3.9 ±5.8mmHg; P<0.01), waist circumference (-3.7 ±2.7cm; P<0.01) and resting heart rate (-4.8±8.9bpm, p<0.001).
The reduced waist line should be an indicator of fat loss, I think people are confusing weight loss with fat loss. The take-home story should be to not rely on weight loss as an indicator of benefit from exercise - not that exercise doesn't reduce fat mass.
If it's not in the computer, it doesn't exist.