aml4td / aml4td/website

Some questions/comments on Categorical Predictors

Open
#39 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
HTML
Stars
171
Forks
17
Avg merge
12d 6h
Merged PRs (30d)
2

Description

  1. The example with each agent working with a single customer type introduced in 5.2:
    1. I think the row-wise sum comment could use some clarification; it's the sum among agents with a given customer type, and the single customer type column?
    2. Later, in 5.4.3, the example is reused, but I think the language is stronger: "agent was aliased with the customer type" to me means there's a one-to-one correspondence rather than the many-to-one relationship I think the original insinuated. And in a one-to-one relationship, the effect encodings will end up being identical, so the argument fails. Separately: can we add a ref-link?
  2. Figure 5.1 typo "distirbution"
  3. In 5.4, I would expect to see some mention of coarsening the categories according to domain knowledge (e.g. states into regions). Maybe also model-based coarsening that uses other predictors?
  4. The Cerda & Varoquaux citation seems to deal more with encodings that take the string nature of the predictor into account, with a hint of natural language processing to it.
  5. In 5.4.2, I'm not sure whether adding a -1 to the hashing values leads to "fewer collisions"; it depends on what exactly you mean by a collision, and I'm not familiar with the cryptography literature to say. But in a parametric model, it's still enforcing some arbitrary constraint.
  6. The intro to 5.3.2 says "different" supervised tool, but it's the only supervised tool in the chapter.
  7. In 5.5, I'd like a small note about integer-encoding the values being reasonable for certain models. (Again, "will be discussed more later", but a preview would be nice.)

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Review the chapter sections 5.2, 5.3.2, 5.4, 5.4.2, 5.4.3, and 5.5, along with Figure 5.1 and the Cerda & Varoquaux citation. Resolve the wording, reference, typo, encoding, coarsening, and integer-encoding questions in the chapter source. Done means the examples and claims are accurate, cross-referenced, and clear.

Written by the indexing model from the issue text.

Assessment

Tech stack
html
Domain
documentation
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.