amuresan

Moving to exact predicates on top of floating point numbers would be a big speed boost. CGAL does this.

The link you posted is behind a login, do you have a public profile?

Hi Mihai! This is impressive work!

Are you aware of any other computational maths problems where a sufficiently motivated amateur could make an improvement on the state of the art?

93 is my best score so far

Great game! thanks for sharing

Related to the Coral accelerator, is it usable as a general accelerator outside AI workflows? When I looked into it, there was no general SDK on using the Coral, only an "ingest ML model" compiler.

Not surprising. It always seemed likely to me that there is model bias if you train your models on model generated data, like a feedback loop (second order effects?). Similar to how applying a linear system over and over stretches the inputs in the direction of its largest eigenvector.

Now wait till the generated content is indistinguishable from human content (to humans) and it will be hard to figure out what's in your training set.

What do you mean by crop in frequency domain? Low pass filtering i.e. removing higher frequency components?

Thanks, will give them a try. Any advice on what to get?

Getting an eink secondary monitor for my workstation. I use to get pretty bad eye strain that lasted for days from LCD screens. It got so bad I forgot how it feels to wake up without my eyes hurting. Now it's all gone.

The product offering of eink screens is virtually non-existent, the only usable one for interactive work that I found was the Dasung 13.3", which is the one I got.

Fair point. At the same time the exact computation paradigm is proof that problems like these can be solved in a rigorous way if you start with the right foundation.

By the way thanks for writing the article, it was a refreshing read.

One geometric model that actually handles numerical approximations is called exact geometric computation. It's pretty interesting and starts by explicitly tracking arithmetic errors in the operations you do. At its core it's a mix of interval arithmetics and multi-precision floating point. This is something you can do since the floating point implementations on most (all?) CPUs give you strong guarantees on the error bound of floating point arithmetic operations and these are usually within 1 ulp (unit in the last place) of the correct result. Now you have an interval for the result and can build your geometric constructs on interval arithmetic rather than classic, single point scalar arithmetic.

Geometry works with constructs, not numbers. An intersection is a construct, collinearity is a construct, orientation / handedness is a construct, etc. If you define your fundamental constructs to be rigorous then the algorithms you build on top will also be rigorous. If we consider the article's inside-outside test example, this result would be computed based on the intersections (intervals) we've computed. Since we know for sure the correct result is within our interval of error then inside-testing boils down to comparing intervals and we know there are three possible situations here: 1. [a, b] < [c, d]; 2 [a, b] > [c, d]; 3. [a, b] overlaps with [c, d]. In case 1 and 2 we have a robust conclusion and in case 3 we recompute the whole predicate with higher precision until it becomes decidable.

The golden standard for exact geometric computation is CGAL [1]. All the research around it is very interesting and refreshing to read.

[1] cgal.org