I am trying to get a better understanding of what reasoning could possibly mean. So far, I am thinking that more we are able to compress knowledge more it's an indicator for reasoning. I would like to understand more about these, please tell me where my understanding is lacking or point me what I should learn more regarding this.
I was wondering if I could get a different way of thinking about reasoning machines as such. Reasoning models are trying to just externalize the reasoning through chain of thought or fine-tuning on reasoning focused dataset.
They all seem very hacky and not really reasoning. I wanted to see if there are alternative fundamental ways to think about reasoning as end by itself.
"Once, Zhuang Zhou dreamed he was a butterfly, a butterfly flitting and fluttering about, happy with himself and doing as he pleased. He didn't know that he was Zhuang Zhou.
Suddenly he woke up and there he was, solid and unmistakable Zhuang Zhou. But he didn't know if he was Zhuang Zhou who had dreamt he was a butterfly, or a butterfly dreaming that he was Zhuang Zhou. Between Zhuang Zhou and the butterfly there must be some distinction! This is called the Transformation of Things"
My understanding is rudimentary, but it doesn't alter the system. But it fixes what state the system should have to produce the given observation, retroactively. Which is counterintuitive in lot of ways. It can be thought as if the observation caused the determination of past state. Do I make sense or I am just talking absolute non-sense.
One of them is per family and other per person (family of size 1). Is it even comparable? I am not saying it is lesser, it's pretty high, probably 200% not 560% if I am right.
Family size of 1 is given as 108L each, but average usage per member of a family of 2.3 people is given as 89L each, so presumably an average total household usage in Flanders would be about 2.3 x 89 = 205L. I'm not sure where OP gets the 202L number from, it doesn't appear anywhere on the page. Possibly mis-reading a date as a consumption, hence I'm using capital L for Litres.
That's more than 5x less than the US. It's quite plausible the average family size and environmental conditions in Flanders differ quite a bit from that in the US, but it's still a huge disparity, and according to the second link a lot of that seems to be down to domestic irrigation. Tackling that wouldn't be very popular, of course.
The headline says 74000l/household/year. Divide by roughly 365 days a year = 202.7392l/day. I made a rounding error and didn't read further down. Still a very useful approximation I'd say.
Was about to mention this. If I recall correctly, the 2d-sphere index rounds geospatial coordinates to 5 decimals. Very occasionally, I found it would distort polygon geometries just enough to cause them to become invalid (e.g. overlapping geometries), which causes the index build to fail.
In my recent experience working with collections containing million of documents, each containing a geoJSON-style polygon/multipolygon representing a property (i.e. a block of land), I found invalid geometries to occur for about 1 document in 1 million. For a while, I suspected the data-vendor was the cause, however it became more puzzling when other geospatial software confirmed they were valid. Eventually we traced the issue to the 2d-sphere index.
A very clever workaround was suggested by a colleague of mine, inspired by [1]. It preserved the original geometries. In each document, we added a new field containing the geometry's extent. A 2d-sphere index was then built on the extent field instead of the original geometry field. Invalid geometries were no longer an issue since we were dealing with much simpler geometries that were substantially larger than the max precision of the index.
When running geoIntersects queries on our collection of millions of documents, we did so in 2 steps (aggregation queries):
1. GeoIntersects on the extent field (uses the index).
2. On the result set from the last step, perform geoIntersects on the original geometry field (operates on a much smaller set of records compared to querying the collection directly)
The same things get invented over and over again and named different things depending on the field. Sometimes it's not immediately clear that they are the same things mathematically.
Very interested in your idea. How does concurrent updates work with the augumented trees? I have been thinking about the same for a while something like CouchDB but segment aggregations (monoid) augumented so we can do interval queries over time too. But the only thing bothering is augumented trees are notorious of contention on concurrent updates. Do you have any ideas on merging back if we have multiple versions of augumented trees.
The probability of the `b` being chosen for A is 1 (No other choice) and for B it is 1/2. The probability of `b` being chosen for both (The only common token), is |{(b,b)}| / |{(a, a), {(a, b)}| = 1/2 which is jaccard's similarity |{b}|/|{a, b}|
I could have explained that a bit better I suppose.
