HN user

usgroup

2,683 karma
Posts156
Comments1,132
View on HN
emiruz.com 6mo ago

Snakes and Ladders: A Statistical Analysis

usgroup
1pts0
emiruz.com 6mo ago

Explainable Query Tagging (NLP)

usgroup
1pts0
emiruz.com 6mo ago

Explainable Unsupervised Query Tagging

usgroup
2pts0
emiruz.com 6mo ago

Snakes and Ladders: a short statistical analysis

usgroup
2pts0
github.com 6mo ago

PyEvidence: Practical Evidence Theory for Python

usgroup
6pts0
github.com 6mo ago

Pyevidence: Practical Evidence Theory

usgroup
1pts0
en.wikipedia.org 6mo ago

Alias Method

usgroup
2pts0
emiruz.com 8mo ago

Dempster-shafer and reasoning about sets

usgroup
22pts8
emiruz.com 8mo ago

Dempster-Shafer and modelling beliefs about sets

usgroup
1pts0
en.wikipedia.org 8mo ago

The SETL Programming Language

usgroup
13pts5
www.theguardian.com 9mo ago

Bank of England warns of growing risk that AI bubble could burst

usgroup
7pts1
emiruz.com 10mo ago

Learning from Heuristics

usgroup
7pts0
emiruz.com 11mo ago

A short statistical reasoning test

usgroup
56pts27
emiruz.com 11mo ago

A short statistical reasoning test

usgroup
2pts0
emiruz.com 1y ago

Machine learning without true labels and noisy heuristics

usgroup
2pts0
emiruz.com 1y ago

Fitting models to noisy heuristic labels

usgroup
3pts0
emiruz.com 1y ago

LLM bootstrapped HN article ranking model from a user description

usgroup
1pts0
emiruz.com 1y ago

Bootstrapping a HN article ranking model from a user description

usgroup
1pts0
emiruz.com 1y ago

Kelly fractions for independent simultaneous bets

usgroup
2pts0
news.ycombinator.com 1y ago

Ask HN: Which language for Advent of Code in 2024?

usgroup
29pts31
emiruz.com 1y ago

Packing group membership data into an integer

usgroup
1pts0
github.com 2y ago

Data Science with Fortran

usgroup
2pts1
emiruz.com 2y ago

Blocking, covariates and optimal experiment design

usgroup
2pts0
emiruz.com 2y ago

Metric Learning with Linear Methods

usgroup
1pts0
www.youtube.com 2y ago

LLMs and recursive reduction in output diversity [video]

usgroup
2pts0
github.com 2y ago

1BRC in Awk, Haskell and Fortran

usgroup
3pts0
github.com 2y ago

Some Data Science with Haskell

usgroup
5pts0
doisinkidney.com 2y ago

What is good about Haskell?

usgroup
5pts0
doisinkidney.com 2y ago

Deriving numbers, recursion and more from basic combinators

usgroup
2pts1
github.com 2y ago

Tsetlin machine – the other AI toolbooks

usgroup
2pts0

Well that would be extra information. Wherever you find the edge of your information, you will find the "problem of induction" as presented above.

This issue happens at the edge of every induction. These two rules support their data equally well:

data: T T T T T T F

rule1: for all i: T

rule2: for i < 7: T else F

SWI Prolog is just fine, and you'll find it to be batteries included unlike many other choices. The first thing to learn is the "Prolog state of mind", or how to express your intentions in Prolog without trying to turn it into a functional or imperative programming language.

Prolog will show you another way of thinking. If it does not then you are doing it wrong.

Personally I don't like the Standard ML based mash-ups.

I think Curry is an interesting take on logic programming. A sort of Haskell meets Prolog.

I can recommend "Simply Logical". I also suggest Advent of Code as a nice way to cut your teeth with expressing thoughts with Prolog.

Generally speaking, Prolog syntax is ridiculously simple and uniform. Its pattern matching is the most universal of any programming language partly because of this.

Yeah that sounds like me too. Prolog became a fetish a few years ago. I used it intensely for 2 years, wrote a lot about it, until it became a part of me. Its intangible what it does to you, but its the dual of what you might expect.

I think this article is problematic because Prolog is truly a different paradigm which requires time to understand. Laments about no strings, no functions and "x is confusing" read like expectations of a different paradigm.

Prolog is also unusual in a sense that it is essential to understand what the interpreter does with your code in order to be able to write it well. For vanilla Prolog, that's not so hard. However, when constraint programming and other extensions are added, that becomes much harder to do.

Thanks for this reference; I found this paper interesting, but it is a satisfiability solver. Inherently it cannot quantify the probability of a subset of events, but it can find a probability assignment given a set of constraints. I.e. prove possibility. More usefully it can show that no such assignment is possible.

I think that's overly reductivist. In the general case DS operates on up to 2^M sets where M is the cardinality of the hypothesis space: worst case scenario. That's not true if hypotheses are hierarchical, or if evidence is frequently about the same set, or there just isn't enough evidence to fuse to get to 2^M.

In the worst case scenario there are efficient approximation methods which can be used.

I think more often people cast the widest net and then filter what comes back based on “is this better than what I have”.

I’m not sure that the process the author describes is all that common in practice even if it is eminently sensible.

The question doesn’t ask for that —- it explicitly asks us to control for over estimation of the fraction — although I rather like your interpretation as an extension.

The Jeffrey posterior in the answer is closed form and Bayesian. The other answer is a profile likelihood.

Neither involve Monte Carlo sampling. Both are general and principled.

I agree it could be clearer but as a general rule, if you find an interpretation under which the question doesn’t make sense, try considering another interpretation.

From the question:

“However, it is very important that the uncertainty in the number of trials is taken into account because over-estimating a fraction is a costly mistake.“

Seems fairly clear to me that you’re supposed to use a lower bound estimate to take into account variance on the fraction due to the number of trials in a way to bounds the chance of over estimation.

Further, there is no need for a heuristic when there a several statistical models for this exact problem with clear properties. Some are given in the answer.

This is a strange dichotomy. N years post CS undergraduate the majority of what you know will be self-taught, but how you've put it together in your head will be different with a theoretical background than without.

A theoretical background is valuable. It distills hundreds of years of other people's learnings. Ceteris paribus, if you do not have it, you are at a disadvantage.