A sibling and me constructed a con-lang, and we tried reverse polish order where you say the terms before the connectives.
It failed badly. While it's easy to construct sentences that way, it puts immense cognitive load on the receiver. Probably because you don't have any structure in which to put all these terms thrown at you, we reasoned, so we reversed the order to get structure (connectives) first, followed by the terms.
It wasn't better. Turns out, receiving a structure with a bunch of holes to be filled later also results in high cognitive load.
Why? My guess is that the cognitive load mainly comes from the number of unfinished structural connections. To minimize that, you need to transmit a tree in such a way that the terms come as close as possible to the connective. In other words, not bottom or top first, but "side first".
I believe this is why infix notation is so popular. While you parse "A and B" or "X + Y" you never have more than one open connection. When you parse "(+ X Y)" you have two open connections after reading the "+". Five levels deep that begins to matter a lot.
I like the purist lispy idea of operation-first expressions, but I struggle to make my mind actually work like that. If you like clojure-type threading macros, consider that they do something similar to infix notation: they reduce the number of open structural connections during parsing.
Someone who holds this view would probably have to make the definitions more precise, so that if you live in a deterministic reality, you actually cannot conceive of a universe that isn't deterministic. You can throw around words like "indeterministic", but you cannot precisely simulate something indeterministic using only deterministic ingredients, and hence, for some precise definition of "conceive", cannot conceive such a universe.
I believe that you are more real than Donald Duck if and only if the future is not yet determined.
In philosophy, theories of time are categorized in A- and B- theories [1].
In B-theoretic time, the difference between past, present and future is only subjective. Objectively, all points in time exist and are equally real. I view this to mean that there isn't any particular difference in the degree of reality between our reality and any mathematical model or imagined reality. Only with A-theoretic time are you objectively more real than Donald Duck.
Author here. I chose tkinter because it's included in Python, or so I thought. I wanted to minimize the complexity of installation.
The README lists alternatives and why I find them insufficient. Okular allows free-hand annotations, but not saving those for later use. It allows inserting custom saved stamps, but these will not be visible in other PDF readers.
> We have so many online tools available to convert Volume units, but not every online tool gives an accurate result and that is why we have created this online Volume converter tool.
Then it converts 231 in^3 to 0.99999994293884 U.S. gal, while 1 U.S. gal converts to 231 in^3.
Backblaze is terrible, but you will likely only find out when you need to restore.
When backup excluded some files, they blamed antivirus software and recommended to go without.
They actively deleted their only backup because the client couldn't read the original files (which was due to disk error).
They admitted that there isn't any guarantee or even effort to make the backup consistent - after asking me to explain the concept.
The only reason I still have my data is because of the very expensive cleanroom disk rescue that they of course refused to pay for - because why try to do what you can to compensate for failing at your only job?
That's why I'd like to see a web archive doing this, so that most publicly accessible content gets a timestamp. That way, it would be suspicious to present an image of an event in the far past that should've been published long ago.
This can also be done anonymously for private files, as a feature of backup systems. That way, you could get the ability to prove to anyone that a certain piece of content was created before that timestamp. It would cost a minimal storage overhead, and the cost of time-stamping can actually decrease with more users.
It appears you can. At least searching for "buy your own debt" gives results for entities who claim to help you do so, without tanking your credit score. "You're certainly not going to take legal action against yourself".
I feel like that would fail. The reason is that Gödel numbers are rather arbitrary, and will therefore be rather far from a form that insights can be gleaned from. They are a representation of a representation, using the fundamental theorem of arithmetic only as a trick to encode any string of symbols into one integer.
As an example of just how arbitrary Gödel numbers are, consider the expressions `((3*n)+1)` and `((n*3)+1)`. Those expressions are clearly equivalent, yet the Gödel numbers for those two expressions are wildly different, with a relation that is rather complex.
IIUC Gödel himself never "used" or analyzed Gödel numbers as such, only the idea that they could be constructed.
Well, your customers are mostly going to be human. For instance, I'm a human and I'd love to spend $500 for someone, who knows what they're doing, to coach/guide me over chat/email through the process of validating a business idea in a high quality way. I don't think it'd come down to more than 5h of work.
One way of scaling it that has already been done is to use the customer's humanness, by selling a book. That scales. Now, if the price point is $500 for a small but high quality business idea validation, what can you do that's better than selling a book on how to do it? Could you train coaches, who then can bill over $100/h and let the customer execute on it? Willing customer right here.
I would greatly appreciate a service that fills this need, but your approach has a bad smell. The second you mention using AI for generation, I'm no longer interested. I'd rather pay 10 times whatever you had in mind and get human help. Make whatever internal tools you want to streamline the process, but don't take the humans out of the loop when it comes to something as important as validating a business idea.
An open source, generic, semantically aware diff/patch toolchain.
This is a fairly big undertaking, including at least:
- A standard for representing and installing grammar information. Perhaps a file in /usr/share/grammar/ for each programming language, packaged in each language's own tools. Since not all languages are context free, the format must support more advanced grammars as well, at least indexed grammars, maybe more. Perhaps grammars should be able to depend on and extend each other (e.g. HTML can have a JavaScript node), perhaps they definitely should not.
- A new text-based diff/patch format that is less line based so that the difference can be communicated on a more semantic level, while still retaining exact reproduction i.e. B = patch(A,diff(A,B)). Add and delete should probably still be the only supported operations, but maybe not.
- A standard for representing semantic weight. The patch operation is deterministic but diff is not, i.e. given A and B, there are many possible patches that, applied to A, would correctly produce B. The job for the diff tool is to find a patch that both is guaranteed to correctly produce B, and as closely as possible describes the difference the same way a human would. Example: In Python, removal of an If condition and promotion of the contained 100 line code block should not be represented as delete 101 lines and as 100 lines. Rather, it should be represented as delete 1 line and delete 100 indents, on the correct level. The semantic weight information that allows diff to choose the best representation in most cases, might be produced using ML. Imagine a collaborative effort to produce training data using commits from open projects, where in most cases a human would simply select the patch candidate that is most easily understood. The semantic weight representation would probably have concepts for other operations than add and delete.
- The actual patch and diff tools. Patch implements only the patch format and has no dependency on grammar or semantic weight data. Diff is where the effort lies. Perhaps some languages are not best served by the generic approach with grammar and semantic weight. In these cases, diff should be pluggable. Perhaps /usr/share/diff can contain configuration for each language e.g. whether it uses a certain grammar and semantic weight file or a custom binary. It also needs some way of detecting which language to use for a certain file.
The vast majority of version control information (including git) is snapshot-based, meaning that among the many possible patches from A to B, none is preferred by the version control data. We are completely free to improve the way our tools select these patches, and it will be completely backward compatible with the existing wealth of version control history. We'd just be able to look at it with more clarity.
It failed badly. While it's easy to construct sentences that way, it puts immense cognitive load on the receiver. Probably because you don't have any structure in which to put all these terms thrown at you, we reasoned, so we reversed the order to get structure (connectives) first, followed by the terms.
It wasn't better. Turns out, receiving a structure with a bunch of holes to be filled later also results in high cognitive load.
Why? My guess is that the cognitive load mainly comes from the number of unfinished structural connections. To minimize that, you need to transmit a tree in such a way that the terms come as close as possible to the connective. In other words, not bottom or top first, but "side first".
I believe this is why infix notation is so popular. While you parse "A and B" or "X + Y" you never have more than one open connection. When you parse "(+ X Y)" you have two open connections after reading the "+". Five levels deep that begins to matter a lot.
I like the purist lispy idea of operation-first expressions, but I struggle to make my mind actually work like that. If you like clojure-type threading macros, consider that they do something similar to infix notation: they reduce the number of open structural connections during parsing.