CompleteSkeptic

There actually is some work (https://arxiv.org/abs/2003.13630) claiming that FLOPS are a poor measure of real-world performance - with some of the more recent FLOP-efficient models actually running slower than older models.

This isn't directly relevant to PP-YOLO, but I'm surprised roboflow is still promoting "YOLOv5" - despite that model not having an associated paper and it not being made by the authors of the previous YOLO's.[1]

The ML community has been asking the authors of that model to rename their project[2] because they are basically stealing publicity by making it seem like the next version of YOLO, despite its performance being worse than that of YOLOv4.[3]

Roboflow has deflected this in the past by claiming they don't know if "YOLOv5" is the correct name[4], but by continuing to promote it, they are directly supporting it. In fact, I wouldn't be surprised that their claim of not being affiliated with Ultralytics to be either false or a half truth, given that all the top pages about "YOLOv5" were done by roboflow, including the first official announcement.[5]

[1] https://github.com/AlexeyAB/darknet/issues/5920

[2] https://github.com/ultralytics/yolov5/issues/2

[3] https://github.com/AlexeyAB/darknet/issues/5920#issuecomment...

[4] https://blog.roboflow.ai/yolov4-versus-yolov5/

[5] https://blog.roboflow.ai/yolov5-is-here/

An appropriate quote: "If you can't intelligently argue for both sides of an issue, you don't understand the issue well enough to argue for either."

There are many people for whom the declarative paradigm is a huge plus. I would say there are at least 2 major approaches in running fast neural networks: 1. Figure out the common big components and make fast versions of those. 2. Figure out the common small components and how to make those run fast together.

Different libraries have different strengths and weaknesses that match the abstraction level that they work at. For example, Caffe is the canonical example of approach 1, which makes writing new kinds of layers much harder than with other libraries, but makes connecting those layers quite easy as well as enabling new techniques that work layer-wise (such as new kinds of initialization). Approach 2 (TensorFlow's approach) introduces a lot of complexity, but it allows for different kinds of research. For example, because how you combine the low-level operations is decoupled from how those things are optimized together, you can more easily create efficient versions of new layers without resorting to native code.

I think he was referring to the fact that the request completes in finite time isn't a tight enough bound.

State-of-the-art results no longer require unsupervised pretraining with autoencoders or RBMs, but back when unsupervised pretraining was more popular, top researchers were rationalizing that it was consider more biologically plausible than the standard nets trained with back prop, since brains generalize through observing a large amount of data over their lifetime to quickly recognize new objects and since the nets aren't trained for a specific task, they would hopefully generalize better and be a step closer to general intelligence.

You may be interested in DBpedia, which gets its data from wikipedia but presents it in a structured format (for example, the page for Clojure: http://dbpedia.org/describe/?url=http://dbpedia.org/resource...), though for this case, it seems the data is already on wikipedia.

Yup! We were about to implement something like that, but we realized Reagent's model of having atoms store the state worked pretty well with javelin's FRP, and once you break down the state into atoms, the cursors aren't needed anymore.

I wouldn't go so far as to say that Reagent's model is perfect. Definitely pretty good, but we've had some issues that were somewhat non-obvious.

If you're worried about it being maintained, there was actually a great discussion of this post on the clojure subreddit (https://www.reddit.com/r/Clojure/comments/2jq0cu/om_no_troub...) where others talk about Reagent having a community-maintained fork with new features.

Out of curiousity though, what kind of helper methods would you be looking for? I found it pretty comprehensive on its own (though I do have some utility methods for some niche uses involving hierarchical atoms).

If any of my post sounded as if I was complaining about the lack of syntactic sugar, I apologize as that was not at all my intention. The best practices and syntactic ugliness didn't matter to us at all after the learning curve. We wrote some macros to solve the problem, and didn't have to think about it anymore. We used sablono as well, so the syntax was almost the same as that of Reagent.

The biggest problems that we faced with Om were how normal Clojure-y things just didn't work with it, and how the app state had to be kept in a tree instead of a DAG (mostly the latter), which created issues with consistency, performance, or both.

> trying to put mutating state into the application state object

How you're supposed to use Om is put all the mutable state into a global atom. I didn't mean putting reference types in the global atom or anything horrible like that, but the problems with cursors being pointers still exist.