There is no obvious way to specify the aggregate function for the index. about fin

[s-leroux]

• OTOH, some use cases seem hard to express at first sight without explicit index selection. For example: "Calculate the average prices per month"

What about:

serie.select(
  (fc.named("MONTH"), fc.month, "DATE"),
  (fc.named("PRICE"), "CLOSE"),
).sort_by(
  (fc.concat, "MONTH", "DATE"),
).group_by(
  "MONTH",
  (ag.avg, fc.named("AVG PRICE"), "PRICE")
)

Few comments:

• In a group_by clause/predicate, the aggregate function for the index defaults to fc.first as it is hard-coded now:

  fin/fin/seq/serie.pyx

  Line 226 in 8352851

  row = [ self._index.py_values[start] ] # XXX Hard-coded aggregate for the index

• both select and group_by explicitly state the columns in the result series. But join operations work on the full series column set. What should be done for sort_by? Should the behavior be consistent between all predicates, for example, saying the only select can change the column set? It seems rather impracticable for group_by, though.

[s-leroux]

From c058cfb and now on, I will experiment with removing the index "special" column.

Some previously implicit things will have to now become explicit, like specifying the join column(s). This will cause problems with the operator version & and |.

[s-leroux]

... or we may make the index a "hidden" property of the serie to keep track of their order for operations that require implicit knowledge of that?

[s-leroux]

... or we may make the index a "hidden" property of the serie to keep track of their order for operations that require implicit knowledge of that?

I didn't manage to achieve something satisfying. Having a "hidden" index is not such a good idea as it rapidly become confusing for the user. Hard coding the index as columns[0] was not very convincing either.