eden_h
Tackling the privacy focus for GA is great, but they're a good deal of products out there that already fill that niche, not to mention the requirements of the privacy crowd usually being a venture into itself.
If you wanted to make it relatively competitive for marketing, the simplest addition would be adding labelling via regex for referrers.
i.e. - Some users want to be able to group Baidu, Google, DuckDuckGo, into a single bucket for comparison. Some users want to break them down into common market segments by country. "https://www.baidu.com/link?url=FyYbCZqj65Vc7A4XeSNrOcQCS2qFX...
is from your live demo referrers, and makes it difficult to actually assess the amount of traffic from Baidu. Using a regex label means that users can break down traffic from Paid/Organic marketing fairly quickly, and start to build up dashboards they can use.
If you ever extended it to allow multiple labels for each hit, could re-run the regex over past data, and could build reports off it, you'd easily have a benefit over GA that would start to wean the marketing crowd off it.
The big problem is the second part - lazy static doesn't allow you to run destructors, and this is one of the few times you really need a custom destructor to tell Rust to kill the CUBLAS/CUDNN pointers at appropriate times.
Ended up connecting it to a struct so that the destructor could be tied to the object rather than anything else, but lazystatic's (lack of) story around destructors definitely created a bunch of problems that weren't apparent until we started finding memory leaks.
Went to Plausible's website, it makes no mention of this type of blocking. That 13% could be eaten into significantly by removing that type of activity.
More convincing would be matching up activity across sites, and seeing for what sessions they differ. If this was a decrease in users who had significant sessions (>30 secs, for example), there'd be more meaningful conclusions to draw.
Dispatch in R is generally fine, but I see a great deal of UseMethod calls, and switch statements for types in the libraries I've worked with, which OTOH is just users using tools badly, but OTO R should enforce using a particular tool to solve problems. And R is particularly bad at enforcing anything, which is why we're left with S3, S4, and R6.
There's also the FFI issue across the board for Python/R where functions frequently barely clean naked FFI calls and leave it a complete mystery what's going on under the hood. I think R is generally worse at it though, where I've had memory leaks and sigterms that aren't visible in RStudio.
I do like the functional programming though. I had an excuse to use multi.argument.Compose from the functional library recently and it made me wish I had things like that to hand in all languages
Mostly regarding using BLAS etc in Rust rather than C++. It seems a little pointless as the unsafe nature is within the underlying code, so it only santises input/output.
A common strategy in GM is to attack on one front with your main army and drop a small amount of units into the back of their base. The opposition has to decide between spending their focus on the main battle or the dropped units.
AlphaStar doesn't have to worry about this - there's no gap between focusing on the front and the back at anything similar to a human.
Players usually use add hotkeys for camera positions to allow them to move around the map fairly fast. We can imagine a human player in this scenario responding by going
* Some actions to move army/setup * Use pre-existing camera hotkey to go back to base, view situation * Setup a new unit group * Move unit group to base to head off attack * Move workers to avoid economy loss * Go back to battle * Setup camera hotkey for battle * Flick between two battles as needed * Move workers back
If AlphaStar can view the two locations without that lag or without setting up new camera hotkeys for movement, there's a definite and sizeable advantage before we get into the amount of EPM involved. An action that is setting up a hotkey is significantly less valuable than one using a spell/moving a unit/attacking.
It's more of a reaction to the idea of changing an institution from the inside.
Your point is arguable if it was instead "How to implement a Ket in Rust", and even then it's a bit vague. I left with the same feeling that it was a bit barebones in terms of definition.
So it is unclear if this is data that is provided to Facebook servers but not accessible to Facebook, similar to options for Google's Analytics platforms, or if it is harvested by Facebook by permission of the app creator. Both options being shady, as it's not told to the user, but this video feels more like it's saying Facebook is actively tracking people, not App Designers are giving Facebook permission to track you in exchange for marketing analytics.
The data that is being provided is significantly too high, and the user should be made aware, but this video seems to only discuss it being API calls to the Analytics interface when using the app. I'd definitely expect there to be API calls when using an app, but how User ID tracking is done is probably the most potentially dangerous part here.
There's a few unanswered questions that I hope it's helpful to point out;
* Importers -> If I want to switch, how long will it take me to move from a potential system (Excel, Google Sheets, Salesforce, etc) into Wobaka?
* Integrations -> If I send an email can that come from my Outlook Gmail and be shown? Can I see emails from my colleagues towards a contact if they want to?
* What does a workflow look like? A gif of going from New Contact -> Adding them into an Org I'm talking to -> Sending the first message would do a lot here.
* How do I engage with my colleagues? Can I tag them in tasks, or pass things along to them?
On point of the post, Tidyverse is a great deal of bloat by loading unnecessary packages instead of specifics and creating namespace issues where two functions have the same name. It's generally fine for interactive work, but causes so many issues in development as you can't pick and choose what's loaded into the environment.
In line with what you're saying, meta-libraries make sense in terms of developing a line of packages towards a singular vision, but only make sense when the core libraries aren't expanded regularly. Maybe in these cases more of push needs to be made to supporting the existing tools?
R is an odd example though, as the standard libraries are loaded by default and I think only really comprise of basic stats/graphics/data.frame tools. I don't really believe a great deal of extra tools have been added to base R in the last few years, just improved in terms of speed and memory use (e.g 3.5.0's change to compiled packages)
The 'typical' response is either to make them into numeric variable, so 1-3 for 3 categories, or to make an individual column for each one. The first approach makes sense for ordinals, but not so much for actual categories, and the latter makes it difficult to group categories when a group of two categories together has more predictive capability than any single group. I know that LightGBM did a lot of work in this to optimise testing groups of variables, as testing every possible group in a large set is very intensive.
When I tried Catboost in R, I remember it downloading a large binary to work with, which put me off considerably, and predicting with it was pretty fragile, even for R. I trust Yandex about as much as I'd trust Google, but it seemed 'odd'.
They're both generalised solvers, but default Random Forests aren't the most common Forest these days - LightGBM/XGBoost are both using Gradient Boosted Forests by default, which would be a much more interesting comparison to a NN's Gradient Boosting.
They kinda cover it in the section in 3.1 and 3.2 with Bagging and Bagging -> RandomForest, but it'd be good for them to explain Boosted Trees here as well.
As far as I understand it, random forests are an aggregation of trained trees based on randomly sampled data points from the original data set. It doesn't necessarily make them more accurate on the training dataset, but it makes them more generalised and less likely to overfit (https://en.wikipedia.org/wiki/Overfitting), because the different trees are likely to focus on different characteristics of the dataset.
Boosted trees do become more accurate, as they resample, but give more priority to data points that weren't correctly classified by the earlier models.