kd0amg

I don't think I've met anyone who learned to write a good proof without significant human instruction. That is probably something to be expected because much of what makes a "good" proof is social expectations, but I see a lot more cases of unjustifiable leaps of logic than excessive, obvious detail.

> For simplicity but without loss of generality, assume there are n past price changes, each of which is either UP (1) or DOWN (0). How many possible trading strategies are there? Suppose we allow a strategy to either be long, short, or neutral to the market. Then the list of all possible strategies includes the strategy which would have been always neutral, the ones that would have been always neutral but for the last day when it would have been either long or short, and so on. In other words, there are three possibilities for each of the n past price changes; there are 3^n possible strategies.

The number of possible n-move histories is 2^n, not n. That means there are 3^(2^n) possible strategies. Nondeterministically searching that space in polynomial time does not work. The claim that a strategy could be verified in O(n) time is dubious as well since the size of a full description of a strategy is (in the worst case) exponential in the length of history it considers. So their claim that finding a technical strategy which performs well in backtesting is in NP is not proven.

They repeat the same error later:

> there are 2^(t + 1) possible strategies (because every possible strategy is a mapping from 2^t different possible sequences of 1’s and 0’s of length t into two possible choices, LONG or OUT)

There are other issues, like assuming a strategy that backtests well will continue performing well in the future.

Yes.

I’m not sure I’d call that “constructive”.

The method for constructing the algorithm is given!

> intended as a mark of erudition of the gentlemen able to use them correctly rather than for practical communication

This is pretty much the same impression I got, though I came from the other direction. I was kind of surprised how many StackOverflow posts ask about adapting a fix_problem() method to fix some very_similar_problem.

I'm not sure why you continue to insist that responses to your comments are just about how macros happen to be implemented in Common Lisp.

Everyone jumped on it, as production lisps don't implement macros this way. … This is about mental models, not implementation details

It looks to me like you're the one who brought up implementation details, talking about what happens "at a very low level." You're the one who has presented a questionable implementation strategy as a mental model and has been corrected on it multiple times by multiple people. Everyone else has been describing the semantics of macros. Having separate timelines for expansion and execution is a semantic distinction, not merely a common implementation strategy.

And in my opinion this thread is full of experts who have forgotten what it's like to not understand how macros work.

Your confusion is because you insist on a mental model of macros that is incompatible with their semantics. Letting that model go is necessary in order to understand macros. Otherwise, refusing to distinguish expansion time from run time, you are working towards reinventing fexprs.

I have seen a lot of people in my area assert that my political will should be subordinate to theirs because I came from somewhere else. Last place I lived, the notion that a particular demographic I fall into should be kept out of the general housing market when possible due to pricing others out was not just a fringe idea but part of several (ultimately successful) city council candidates' platforms. Perhaps people in your area are less nutty about outsiders.

If someone can't afford to live in some area…

Yes, those who can't afford the rent can live elsewhere, so rent control is not needed.

If you mean run-time functions that act a bit funny about evaluation order, that mental model is incompatible with common introductory examples like `let`.

One class of use cases not covered in the blog post is that a variable appearing as a function's argument can only be a bound occurrence, a use of some name already in scope. A variable appearing as a macro's argument can be the binding occurrence of that name. This is why (using Racket examples) match, define-struct, for/list, and such things aren't functions.

[1]: https://docs.racket-lang.org/reference/match.html?q=match#%2...

[2]: https://docs.racket-lang.org/reference/define-struct.html?q=...

[3]: https://docs.racket-lang.org/reference/for.html?q=for%2Flist...

GP's suggestion seems to be that non-conspirators would not actually be willing to pay that much -- a bit like a pump-and-dump scheme, but only the IRS gets duped.

The vast majority of non-dense areas have much less of a tech scene than New York and Chicao. I would expect that what draws tech workers is career opportunity more than high or low density and that density is more driven by how municipal government responds to the changing local job market.

This is not the case for HTTP. A network protocol is an agreement about the meaning of certain clusters of bytes sent over a network. When someone operates an HTTP server, a reasonable person could conclude that they take HTTP messages to mean what HTTP says they mean. A lot of cases get more interesting because there is also something generally understood to mean, "Please don't access the following resources by automated scraping, independently of whether my server decides to grant those requests."

But outsidetheparty already mentioned honest comparison with other work too, before bringing up documentation.