solinent

Note that there's no way to observe a particle without some form of entanglement, though.

> [...] quantum physics on a deep, intuitive level, probably do not.

Intuition and understanding are two different things. Our intuition behind quantum mechanics is obviously wrong--quantum mechanics doesn't even obey regular logic! Quantum logic gets rid of a rule, for example.

So it's probably impossible to develop an intuitive understanding if that is your criteria.

As we've progressed, we slowly just get used to new abstractions. The concept of zero, negative numbers, complex numbers, rationals, reals, they were all very non-intuitive to the people at the time but were required to understand the science of the time.

The biggest problem in mathematics has never been proving theorems. Mathematics was never focused on proof until the formalization of math became popular approximately 100 years ago. Mathematics is used as a tool to explain the world and to create the least-complex model which predicts the data.

So computers can aid us in verifying our work--but ultimately we aren't interested in determining all the possible logical theorems. Instead, we're only interested in finding the logically valid theorems which serve the above purpose of explaining the patterns in the world concisely.

It's a subtle difference, but for computers to solve that problem requires for them to have a certain understanding of humans and our goals with science.

I think that's more than 10 years out.

I think quantum mechanics is well-understood, the mathematics behind it provide us with excellent predictions.

I think because at its core it is a probabilistic (or perhaps there are many worlds, but the implications are identical) theory--there is some inherent uncertainty in the predictions. This uncertainty builds up over time if left unmeasured, due to the chaotic nature of the system. We won't be able to result this uncertainty until we have more precise and accurate measurement devices.

I was thinking, the only real way for us to progress was to get the results out of CERN we were expecting--either smaller particles or some detection method which allows us to peer even deeper into the atom.

I think certain physicists are tired of the search for a unifying theory since it probably won't help us make better predictions. We need to get out there and get new empircal data.

Yup, my definition of interpretation was limited for pedagogical purposes, but I should have been clearer. The propositional logic version is much simpler to understand, but the implications of the theorem are much more interesting in first-order logic, so introducing all of this nomenclature may be too much for someone who isn't motivated yet.

Essentially, all logically valid formulae have proofs in first-order logics.

Remember, logically valid formulae means that if you enumerate all possible interpretations (boolean values for the variables), the formulae remains true.

So you could prove everything that ever exists by creating a set of all possible proofs using the given deduction rules.

A class is fundamentally about implementing object semantics. This simply means everything (eg. all objects) are an instance of some class. It has methods which can be used to operate or communicate with other objects or itself.

Data-structures are put most simply as ways of organizing data. The organization of the data implies a specific layout--a way of representing your data as a table of integers, ie. in RAM.

After reading the article, I don't see a meaningful distinction between objects and data structures. A data structure can be represented as an object, especially in OOP languages where it must be.

A general class doesn't necessarily lay out its data in any particular way--which allows abstraction over the data representation of the class.

However, some classes are made which are designed in a manner which guarantees a certain data layout. std::vector with its contiguous memory requirement comes to mind.

To add to this, the c++ conception of a "concept" or haskell's concept of a "typeclass", or even a generic class, is really what this article is talking about. Or even Java or Go's interfaces. There is absolutely no way to guarantee a specific data structure through an interface, typeclass, or concept, since they fundementally do not mention their data representation at all.

    g f x 

would not be the same as

    (g . f) x

you need the right associative function application operator $, ie.

    g $ f x

or simply

    g (f x)

Only 2000IU per day. I'd like to see one with 10000IU.

I can imagine this happening in template code:

    template <typename T>
    bool isNumberInfinity(T number)
    {
        return isinf(number);
    }

    template <>
    bool isNumberInfinity(Number number)
    {
        return number == Number::INF;
    }

So instead of specializing ints, we rely on isinf working for ints, instead of doing the "correct" thing:

    template <>
    bool isNumberInfinity(int number)
    {
       return false;
    }

This is a very contrived since I'm using template functions, which are practically useless, but it holds for any data structure which holds a type that is meant to behave somewhat like a "number".

The "assembly language" for ML would actually be the lambda calculus. Scheme isn't really defined unless you're talking about some standard, and the semantics of the language are probably just defined in English.

A Boeing can't reproduce, and cannot heal itself.

(edit: I mean to say that there are processes that evolution has evolved that have eluded us and may continue to elude us indefinitely)