xi

Maybe you'd like to check FunSQL.jl, my library for compositional construction of SQL queries. It also follows algebraic approach and covers many analytical features of SQL including aggregates/window functions, recursive queries and correlated subqueries/lateral joins. One thing where it differs from dlpyr and similar packages is how it separates aggregation from grouping (by modeling GROUP BY with a universal aggregate function).

This is pretty close to how my Julia library [0] for composable construction of SQL queries works:

    From(foo) |>
    Where(Get.value .< 10) |>
    Join(From(bar) |> As(:bar), on = Get.bar.id .== Get.bar_id) |>
    Where(Get.bar.other_value .> 20) |>
    Select(Get.group, Get.value) |>
    Group(Get.group) |>
    Where(Agg.sum(Get.value) .> 100) |>
    Order(Get.group)

[0] https://github.com/MechanicalRabbit/FunSQL.jl

Are you serious? Regular Russian troops have been fighting and dying in Ukraine for weeks now.

http://www.nato.int/cps/en/natolive/news_112103.htm

http://uk.reuters.com/article/2014/08/28/uk-ukraine-crisis-r...

A Russian native speaker does not equal a Russian. About 2/3 of the population of Donetsk region identify themselves as ethnic Ukrainians. More than half of those name Russian as their native language.

Crimea was occupied by Russian forces in February. Military hostilities in mainland Ukraine started in April when Sloviansk has been captured by Russian ex-FSB officer Igor Girkin and his gang of Russian ultranationalists.

Which means that there is an "excess of 1.5 millions of people" in Donetsk Region, that "[people of] Donetsk Region mustn't be undestood [by the people from the rest of Ukraine], and Donetsk Region [and it's people] must be used as a resource instead" and "I don't know how to solve that problem [to remove excessive civilians], but the main thing is that some people must be physically eliminated".

Wow, this is truly creative editing. None of your insertions are implied from the context and the quotes you picked up are several minutes apart. In particular, he talks about 1.5 millions of people lacking meaningful job prospects as one of the causes of the unrest (which is true). A few minutes later, when he talks about about killing people, nowhere he implies millions of civilians, in fact, it's obvious he means armed militants.

Maybe the TV host didn't challenge him because his comments are already so backward and idiotic as to not need further emphasis.

I'll give you a better explanation: the TV host didn't challenge him because it never happened. The "expert" (another journalist, in fact) never suggested to "physically eliminate about 1.5 million of civilians of Donetsk and Luhansk regions that are not able to fit in Ukrainian Nation" or anything close to it.

EDIT: What's the downvote for? A lack of citations?

Maybe because of them? The article about Timoshenko is written by a serious antisemitic nutjob.

Orange juice?

...The Florida industry’s aggressive marketing of oranges and orange juice is a key feature of orange juice history, as it slowly developed demand for the product. In 1907 oranges became the first perishable fruit “ever” to be advertised. As crops expanded quickly, marketing became crucial to avoid overproduction. The growth of farmer cooperatives came largely out of a need to market the products. The Florida Citrus Exchange was organized in 1910 to market fresh citrus and also to do research on processing citrus. It created advertising programs and “built national and international sales organizations.”

http://shkrobius.livejournal.com/312073.html

Armin's implementation of `cached_property` is not entirely correct. Well, it works, but the branch where `value` is not `missing` is never executed: the object's `__dict__` takes precedence over the descriptor as long as the descriptor does not define `__set__` method.

Here is an implementation of `cached_property` I use:

    class cached_property(object):

        def __init__(self, fget):
            self.fget = fget
            self.__name__ = fget.__name__
            self.__module__ = fget.__module__
            self.__doc__ = fget.__doc__

        def __get__(self, obj, objtype=None):
            if obj is None:
                return self
            value = self.fget(obj)
            # For a non-data descriptor (`__set__` is not defined),
            # `__dict__` takes precedence.
            obj.__dict__[self.__name__] = value
            return value

The original paper, which is quite informative and easy to read: http://www.ploscompbiol.org/article/info%3Adoi%2F10.1371%2Fj...

You are right, now that I read the original article, it appears the particular ant genus they were studying does not use pheromone trails. Since this ant species gather seeds which are scattered by wind and could be brought back by a single ant, they don't need to build paths to the food source. Instead a returning ant interacts with other ants which are ready to leave and the rate at which ants leave the nest grows with the rate at which ants return back (so a leaving ant is a data packet, a returning ant is an ACK packet).

The paper: http://www.ploscompbiol.org/article/info%3Adoi%2F10.1371%2Fj...

AFAIK, it's completely decentralized. When a scout ant finds food, it returns back to the nest leaving a strong trail of pheromone. Ants tend to follow a pheromone trail and reinforce it on their return if they find food, so when a good source of food is found, a strong pathway is quickly established by a growing number of ants following the same route.

An ant may randomly leave a pheromone trail, which ensures that other, perhaps more attractive food sources are not missed. In general, the stronger the signal, the faster ants move with the less probability of diverging from the path.

This strategy ensures optimal area exploitation under varying conditions. For instance, if the food is concentrated in one or a few locations, you'll see a single column between the nest and the source, but when the food is scattered through the area, the ants would disperse too.

Source: an excellent book "Cells, Embryos and Evolution" where it was used as an example of how complex and seemingly organized and directed behavior could be achieved by a population of identical individuals acting under uniform rules.

I was about to prepare the query without ties and yes it is a lot harder than necessary and, more important IMO, much less readable/intuitive for people than have to maintain the code and that is exactly why different SQL dialects introduced ORDER BY/LIMIT/OFFSET/TOP/RANK etc.

Very good point.

In the book pointed out by Matt, Date explicitly states he's not saying ORDER BY is not useful, just that it doesn't return a relation and thus it's not included in the algebra.

My biggest gripe about ORDER BY, LIMIT and relational model is the fact that while Date and others made some attempts to express these operations in terms of relational algebra, they never (AFAIK) tried to do the opposite: alter the relational query model to naturally support them. It's not hard: just replace sets with sequences or arrays. It will gives you natural ORDER and SLICE operators as well as new aggregates FIRST, LAST, NTH. It solves duplicates without having to introduce bags, gives windowing functions for free and probably better represents how modern RDBMS interpret a query. Another hint why sequences may work better than sets is the fact that regular set operations such as INTERSECT and UNION (as opposed to UNION ALL, which becomes concatenation) are so rarely used in real-world queries.

I'm not even arguing that this is a good approach, but I think it deserves some discussion and it appears they never even thought of a possibility of changing the model treating it not as an instrument, but as a sacred scripture.

Thank you. I accept your answer with the note that you ignored my request to return only the latest post when there are more then one posts with the same number of comments, but it's not hard to adapt you query to satisfy this requirement.

However you can't do the same trick if I ask you to return the top 3 posts with the largest number of comments; or, to make the query more realistic, ask you to return the percentage of comments generated by the top 10% popular (by the number of comments) posts. Which is my point: pure relational algebra as advocated by Date et al in Tutorial D is less expressive than SQL, which probably explains the cold reception it got from the industry.

Edit: now that I think about it, you could do it without ORDER BY/LIMIT, but still it's harder than necessary.

That means #1 is totally relational (as an aside, you don't need ORDER BY or LIMIT for it either).

I would love to see it. Yes, you can do it in SQL, but I'd say it's not easy at all without ORDER BY and LIMIT or windowing functions and I don't know if you can do it in Tutorial D. For the reference, #1 is:

Show the blog post with the largest number of comments. If more than one exist, pick the latest.

The schema is:

    post(id integer, created timestamp)
    comment(id integer, post_id integer)

I read it and the book as well, but I wouldn't call it excellent. What I read there is a reluctant admission of failure to incorporate an important operation to his query model. I see no attempt to analyze why it doesn't work or adapt the query model to make ORDER a regular operation.

People mean different things when they say relational model, so to clarify, by relational model I mean a model in which data is represented as sets of N-tuples of fixed structure, and queries are constructed using set-based operations such as filtering and Cartesian product.

Also, when I say path-based access, I mean access that follows predefined links between entities (in SQL, provided by FOREIGN KEY constraints). Those are well supported by object model and ORMs, as opposed to arbitrary joins, which aren't.

You don't need a relational model to represent one-to-many relations, in fact, an object model such as provided by many ORMs could represent them perfectly. In your first example, `figure.vertices` could be a list of vertices associated with a figure, and `vertex.figure` is the figure which owns the vertex. Similarly mutual object or list references could represent other singular or plural relationships. Though I agree it requires referential loops and cannot be expressed well in a pure hierarchical model such as in many novel no-sql databases.

ORDER BY, LIMIT/OFFSET have to do with presentation of data. So, although it's highly desired that a language based on the relational model supports them, they have nothing to do with the model per se.

By fit poorly I mean that you cannot express most real-world business inquiries using pure relational primitives without ORDER BY or LIMIT/OFFSET and that's why I think relational algebra is not usable per se. SQL fixed this problem by adding many non-relational constructs, but but without any sense of consistency or direction.

I also strongly disagree that ORDER BY and LIMIT/OFFSET are presentational operations since I often use them not only for wrapping the outer SELECT, but also within correlated subqueries.

To show some proof, here are a few queries which are hard or impossible to express in relational algebra:

1. Show the blog post with the largest number of comments [^].

2. Show the tags associated with the blog post with the largest number of comments.

3. For each blog category, show the 3 top blog posts by the number of comments.

[^] If more than one exist, pick the latest.

NULL is a completely different beast and this is the only real thing one can consider problematic.

I think NULL is only hard because relational model is a wrong way to look at the data. If you see an entity attribute not as a column of a tuple, but as a function from an entity set to some value domain, the fact that the attribute is nullable just means that the function is not total. There is a well developed mathematical apparatus for partial functions, in which NULL becomes a bottom value injected to the value domain, and tri-valued logic is simply a monotonic extension of regular Boolean operators.

People conflate "relational" with "SQL", because of the historical accident that SQL is the most popular way to query relational data. Then when SQL isn't a good fit for their problem, they think relational is not a good fit for their problem, which is almost certainly not true.

For most practical purposes, SQL is the only way to query relational data. In the absence of alternatives, it's natural to conflate the notions of SQL databases and relational databases. I agree that SQL is a mess, but I don't think an approach based on pure relational primitives would make it better; in fact, I think SQL is a mess specifically because of lack of expressiveness in the pure relational primitives. NULL, ORDER BY, LIMIT/OFFSET, opaque keys, windowing functions, transitive closures, etc fit poorly into the relational model.

The original motivation for relational databases is to have path-independent access to data. This is a really powerful idea.

I agree with both assertions, but in many applications, path-based access makes the total majority of queries, and SQL or relational model provides little means to distinguish them from other equi-joins or arbitrary join conditions. In my opinion, it would be better to start with a navigational path-based database model, and extend it to allow constructing new paths dynamically.

I'd guess premiere just means offered for the first time.

GPLv3 and AGPLv3 are mutually compatible, that is, you could link GPL code to AGPL code and vice versa.

You might be interested in a project I've been working on lately: http://htsql.org/ -- it's a high-level query language that compiles into SQL. The syntax was motivated by URLs and XPath; the semantics is based on navigational model. As opposed to many other non-SQL query languages, it supports analytical queries including aggregates and projections.

I, for one, prefer fors and ifs to high order functions when reading and writing Python code. I use the latter very sparingly and only when it does not violate the overall "pseudocode" feel of the code. For that, generator expressions and functions like `any`, `all`, `sum` are of great help.

For example, I have nothing against the code like this:

    if any(foo.is_cond for foo in foos):
        do(bar)

It may work better in ML-derived functional languages because function definitions there, both anonymous and named, are extremely lightweight. This part of the language is highly optimized by necessity as high order functions is the only way to express iteration and other control flow constructs. But in Python, though not particularly heavyweight, function definitions don't mix well with regular code.

Also I'm not sure if the author is completely fair with his loop example. Add a few local variables, `break` or `continue`, and the high order form may actually become less intuitive.

See http://www.python.org/dev/peps/pep-0374/ for the rationale; but keep in mind it's more than two years old so some of the criticisms may not longer apply.

While each of your individual complains may make sense, as a whole, they are amusingly self-contradictory.

You start with arguing for groundbreaking changes in the semantics and internal API, which practically render every single binary extension obsolete. Then you complain about minor semantics changes that forced you to do simple mechanical conversion.

Don't you think C extension authors would be equally or even more upset at having to rewrite their extensions from scratch? Even with the minimal incompatibilities on the C API level, it took ~2 years to port numpy/scipy, do you believe it would have ever happened if the changes you advocate for were introduced? Well, had the scope of Python 3 included removal of GIL and a JIT compiler, I doubt we had a single release yet while the usage of Python 2.x would be on decline (see the sad story of Perl 6).

Concerning your individual complaints.

It makes no effort to move towards the multicore era -- very minor changes would make the language potentially scale much better.

"Very minor changes"? I seriously doubt it. Besides, I'm sure you didn't miss the announcement: we are already in the "cloud" era. ;)

Print syntax changed.

It was probably done to remove two ugly special forms:

  print foo,
  print >>file, foo

Doesn't strike me as a good example. It was a problem both for introspection tools and C API, it was discouraged for a long time and hardly in use. I can't believe there's a single tear shed for the loss of it.

Oh. And just to be ass-backwards, we'll call the executable "python" just like in Python 2. If you install Python 3, and scripts begin with #!/usr/bin/python, suddenly your system breaks.

That's what `make altinstall` is for, which is thoroughly documented in the section "Installing multiple versions" of README. If somebody doesn't read installation instructions, perhaps it's their fault after all?

"very hard to optimize", "very minor changes", "seriously broken"

Seriously, it's not very specific. A lot of heat, not enough sense.

Well, I don't entirely agree here; there are some valid concerns about Py3-specific design decisions. Take, for instance, conversion of `str` to Unicode. That

* significantly increases the memory footprint as every character requires 2-4 bytes to encode.

* does not provide 1-to-1 correspondence with certain Asian encodings.

* creates an impedance mismatch between Python and byte-oriented filesystem/internet protocols.

Personally, I believe total Unicodification in Py3 was worthwhile, but from some perspective, it could be seen as a regression.

That said, I'd love to hear what specifically in Py3 could cause such a burst of hate.

Care to elaborate?

I can stringify a list by saying map(str, numbers), because str() happens to be a function that I can map with. But I can’t capitalize a list in that way, because capitalize() is a method.

Yes, you can:

    >>> map(str.capitalize, ['alpha', 'beta', 'gamma'])
    ['Alpha', 'Beta', 'Gamma']

Of course we know what defaulting is. Why is it bad?

I wonder who is that we you refer to. Is applicative a Bourbaki-style pseudonym for a group of aspiring Haskell hackers?

I never said it is bad, it looks like a useful and convenient mechanism. My complaint is about its non-genericity. Indeed, it is limited to numeric literals only; even to reuse it for string literals, you need a compiler extension.

A general coercion, understood as something different from a function (pack, unpack), would have to coerce between two types of wildly different structures.

By general coercion, I mean implicit conversion not limited to numeric literals (or string literals, with an extension) only.

Try C.

Hacking the Python interpreter or making a Python wrapper for a library written in C is a good way to learn C for a Python programmer.