It had previously attempted to create that table as part of the test setup, so it apparently concluded that it was a test table.
During human review, it explained that it had simply chosen a table name inspired by the codebase.
238 karma · joined August 17, 2012
It had previously attempted to create that table as part of the test setup, so it apparently concluded that it was a test table.
During human review, it explained that it had simply chosen a table name inspired by the codebase.
I would go further, and say we don't understand how next-token predictors work either. We understand the model structure, just as we do with the brain, but we don't have a complete map of the execution patterns, just as we do not with the brain.
Predicting the next token can be as trivial as a statistical lookup or as complex as executing a learned reasoning function.
My intuition suggests that my internal reasoning is not based on token sequences, but it would be impossible to convey the results of my reasoning without constructing a sequence of tokens for communication.
How much value is needed is determined by the society through a free market.
Are you familiar with functional safety classification and how this affects the development of systems? Would you draw conclusions from the failure rate of Siemens vacuum cleaners to the company's capability of building fission reactors?
Operate: PreussenElektra, EnBW, Vattenfall, RWE, EWN.
Or was that a rhetorical question for a solution with a zero catastrophic failure rate (in Germany)?
This thread is discussing GeckoView, which exposes extensive privacy settings.
There is a (hopefully growing) amount of apps based on GeckoView, which will make use and/or expose different variations of GeckoView settings to the user, depending on the purpose and target audience of the app.
You might disagree, but, for example, I consider the level of detail in privacy settings provided by Fenix (Nightly) to be a good balance between user control and comprehensibility.
> > GeckoView also exposes a WebExtension API > again to the app.
Again, taking Fenix (Nightly) as an example, the GeckoView WebExtension API is used to provide a growing selection of add-ons, many of which are aimed at the privacy-conscious user, including uBlock Origin, HTTPS Everywhere, NoScript and Privacy Badger.
GeckoView exposes a wide range of privacy (including anti-tracking and anti-fingerprinting) features in a (hopefully) comprehensive API, see https://mozilla.github.io/geckoview/javadoc/mozilla-central/..., and continues expanding its privacy settings.
> Some you can install extensions (you can't on this and on mozilla focus)...
GeckoView also exposes a WebExtension API, see https://mozilla.github.io/geckoview/javadoc/mozilla-central/..., and continues to expand extension support.
> ...some you can fiddle with user-UNfriendly settings in about:config...
You seem to have answered one of your own questions here.
I also have the impression that you might have not commented on the GeckoView library, but on some range of Mozilla products (you named Focus).
Seeking VBR MP3 with perfect accuracy is trivial by forward-reading. However, this is obviously highly inefficient on long duration seeks.
For instant seeking support, you need to (partly) depend on the optional VBR headers. This comes with its own set of issues, e.g., the most commonly used Xing header contains only 100 seek table entries, which may not provide enough resolution for large files.
I'm still surprised about the complete lack of support for those headers in AVFoundation, since I would consider it a low-hanging fruit in terms of improving usability for the majority of use cases (excluding pod casts).
Disclaimer: I've worked on MP3TrackDemuxer for Gecko/Firefox.
The plan is to make it the default in Firefox 51 on desktop, assuming the staged roll out is successful.
Also, the current approach will not considerably increase resource usage for heavy tab users as FF will only run one content process shared across all tabs.
I don't share questions as a matter of principle, fwiw.
You can find query time evaluation in the performance recap on the results page I linked. For NYC it's around 2.2s for the Dijkstra (baseline) and 27ms for the TP-based search.
For single-threaded pre-computation and shortest-path queries, I would expect you to need around 8GB for NYC, less for Toronto and you can get the Honolulu feeds to run on <2GB (which was my local test set).
Sorry for not being more specific or inaccurate.
You can find some GTFS feeds here: http://www.gtfs-data-exchange.com
Transfer patterns also behave robustly given real-time updates on the network, which we have shown here: http://stromboli.informatik.uni-freiburg.de/student-projects...
On top of being an excellent researcher, Hannah Bast is one of the best professors I've had pleasure of studying under and working with, so I'm happy to see her getting credit for this.