cs702, fantastic comment. I am sorta poking around this area too. I'd be curious what benchmark you're using to evaluate performance amongst these repos? If you're up for it, shoot me an email -- my email is in my profile.
Great question. Every cell carrier processes images before delivering to the recipient. Like, if you send 3 or more photos almost every cell carrier will downsize the images. While this isn't an extensive test, I just tried renaming a PDF to a GIF and it failed to send on Google Voice and T-Mobile.
Related, are there better representations for music than standard notation (or MIDI)?
I'm wondering what the higher convolution levels could look like, if this was a CNN analyzing an image. Something between a the complete Ableton/Logic export and a MIDI file. Being able to capture the "feel" of a song (or a section within a song) strikes me as an important milestone towards designing really good generative music.
How do you think about backtesting? There are a few short-only shops that specialize in finding frauds. If you get their historical 13-Fs, how would you score against them in terms of precision/recall?
And I guess more broadly, how does alpha with your system compare to a portfolio that holds all short positions by big long/short funds (ex thematic shorts)? Meaning, those guys have full-time humans that focus on this... can you beat them? Very interesting if so.
RE: backtesting we use SEC enforcement actions related to fraud (10b-5) as our gold label. That said, there is no gold label for absence of fraud so our backtested metrics are probably slightly better than they seem.
We've never tried to score a short fund on their precision/recall but unofficially, Hindenburg Research has the highest concordance with our models in deployment.
Re: alpha -> our focus is on extracting red flags that are similar to what a forensic accountant/analyst would find. AI-assisted research rather than AI driven.
trading on fraud signals alone is pretty hard, you need another event. we havent done quant testing of our risk scores in a while. We definitely should do proper quant backtesting though.
Very true. I would gladly pay for a feed of financial news, but instead of "clicks" it optimizes on market movement. News articles from sources that, in the past, have predicted market activity.
I.e. "this blog mentioned NYSE:TEVA, and the next day the stock moved materially, therefore site_ranking++". (You'd probably have some TF/IDF saliency metric too, so that a site that mentions all stocks is penalized.)
Higher-end can mean a lot of things, especially when talking consumer grade. I generally translate consumer grade high-end as being more aesthetically pleasing vs operationally. My expertise are more aligned with industrial grade equipment where size is typically not the limit. I've deployed a 16ft x 9ft high-res LED display for a customer in the past. That's something you don't normally find at BestBuy or even at their Magnolia outlets.
They're not more expensive _just_ because of the lack of ads subsidization.
They also generally are just better built. The expected hours of operation and MTBF of the components is generally much higher than consumer displays. Many of the ones I dealt with had metal cases and stronger glass.
They're expected to stand up to much more abuse or often be installed in places where they're inconvenient to service.
If you wanted to build a non-smart panel with the expected lifespan of a typical consumer TV a significant portion of the current cost could likely be cut if it were done at scale.
Is the "smart features" actually making money for the TV manufacturers?
A good question to think about. How can we, as consumers, incentivize the TV manufactures to focus on building good product that actually liked by users, and still making good money.
It is quite well know ( mentioned multiples times in this thread and in every other TV discussions for he past years ) the smart features collect data and shows you ads which earn the manufactures a continuous stream of revenue.
approx $75k with control system for a 5mm pixel pitch. The control system is required for source input mapping/transformation onto the display. Here's footage from 4ft away https://bit.ly/3y5AuhW running at 30fps 60hz.
You could expand the cutoff date by modeling lookalike audiences. A 2018 account that votes on similar things to a 2008 account might be admitted. This affords the moderator an easy “exploration” spigot they can tune up or down.
It’s one thing for a startup to do this while small.
A whole other level of evolution to do it while you’re large. Imagine Apple suddenly publishing their roadmap. This type of organizational neurogenesis done as an adult is impressive.
EDIT: I am in admiration of the change, regardless of opinion on the value of public roadmaps. It’s just rare to see big companies make big changes. Sign of youthful vitality and health, in my opinion.
Yeah. All Cloud deprecations have a minimum of a year notice, usually as an email, ahead of multiple follow up emails as the year draws close. It's in the terms.
Additionally, you can also get this information in the public release notes https://cloud.google.com/release-notes twice-monthly GCP newsletter, and for G Suite administrators in their news area. "Sigh."
While it's only for enterprise customers, AWS has a weekly email containing upcoming launches which are under NDA. It also has what amounts to recaps of recent launches, blog posts etc. Only the launches section is not publically available.
The upcoming launches section is literally just an HTML table with two columns: service name on the left and a brief summary on the right like "Add support for X Y.Y". It's almost funny how so much effort goes into fancy blog design when the "real" news is just distributed through a basic plain text email :)
---
To a certain extent, roadmaps become redundant for enterprise customers too in that you start to influence feature request priorities via your dedicated account manager(s)
Vendors may often prioritise a feature requested by medium enterprise to keep them content since if they don't address their features in a timely manager, they may go elsewhere when their contract comes up for renew.
---
I suppose that's why UserVoice type of forums are always a wasteland because the big players can get all the attention?
It's also behind the scenes so perhaps naturally, the result you're left with is acres of "9999 votes for feature X, submitted 14 years ago" and a Product Owner saying "Sorry, no news to report on this just yet"
Apple is a poor choice, because they consider keeping their roadmap under wraps an not only a competitive advantage, but a core part of their company ethos.
If you want the full-blown thing, there's a whole book called "Inside Apple" which details the whole long-term extremely secretive nature of their business (this was back from the Steve Jobs era).
Apple is similar to Disney in their core business model being anti-golden-rule. Not "treat others as you would like to be treated" but "treat others as you want to treat them, and insist they treat you as you want". Don't care about respecting others' trademarks or ideas, take creative bits from everyone, be super vigilant and protective (even antagonistic) about anyone else who uses any of your ideas.
The claim should be completely indisputable. It's well known that teams within Apple are not privy to the roadmaps of other teams, even teams working on a different aspect of the same project.
Lot of secret projects and buildings in SJC that belong to apple. No Apple logos, sign an NDA in the lobby, meet in conference room outside the working area. It is indisputable.
Which is completely different from Amazon, I’m not even considered an SDE - I am a consultant at AWS - I can get read only access to source code of services if I request it.
The downvotes must be coming from asking about the latter point since it's clearly institutionalized. The former is interesting to ask about though, how is keeping product roadmaps a competitive advantage in Apple's case? Which teams is this especially so, and on which products is it in their interest for the roadmap to be out in the open?
Google provides rather detailed roadmaps for GCP, they are really useful. They are under NDA, but customers should be able to get access. I think this recent "C2C" announcement has link for signing up[1]. I was invited, and your account manager should be able to invite you.
Thank you! We work really hard on the GCP roadmap program, keeping it fully accountable, and pushing against interesting transparency limits.
A public GCP roadmap is also in longer plans but there's a few internal flows we want to improve first. I'm especially trying to reduce the number of sites people need to visit, and want to ultimately see it land in a common place where authenticated users also see the non-public / NDA aspects.
And seconding this advice on access. If you are a GCP customer, your account manager is able to add your account for access. My contact info is in my profile and I can reach your account team if you have difficulties.
My first reaction was very different from yours; the desire to dogfood feels excessive, to me, and negates the point in having a public roadmap in the first place.
Am I wrong for presuming that the people who would most care about GitHub's public roadmap probably aren't even GitHub users?
EDIT: Thanks for the replies, everyone. Seems like I hadn't fully comprehended the range of features available to paying members - given this knowledge, choosing to do the roadmap in this form makes more sense to me.
Am I wrong for presuming that the people who would most care about GitHub's public roadmap probably aren't even GitHub users?
Free tier users, maybe not.
But paying users care very much about what they can expect for their outlay of money in the years to come. Roadmap presentations for paid software are _de rigueur_; they help keep your paying customers on your platform.. They're just not often shared openly like this.
Github has a vested interest in attracting more and more free-tier customers though. Then they go to companies and influence tool purchasing decisions and help feed the paying customer funnel. So this seems like a risk with some postive calculus behind it. It could be that free-tier users didn't know they wanted to know the roadmap, and now that they do they'll be happy they know about it.
> Am I wrong for presuming that the people who would most care about GitHub's public roadmap probably aren't even GitHub users?
I think so. I'm a GitHub user and I like being able to view their roadmap.
Think about it this way. GitHub is a giant piece of software that developers use. Software changes, and developers are particularly sensitive to this. We're constantly fixing bugs and factoring code to support dependency shifts (or choosing to snapshot ourselves at some preestablished point of stability).
Given our sensitivity to change and how important GitHub's product is to our productivity it's crucial that we're not hit with surprises. A properly communicated roadmap helps avoid that -- thought admittedly it does take some work on our part as customers to parse it. That said this is no different than reading release notes and documentation for the software and libraries we use elsewhere in our day to day.
Thank you! We couldn't have said it better ourselves. Let us know if you have any other feedback on what we can provide you to plan better. And thanks for your use of GitHub!
problem is, this roadmap doesn't contain any specifics in contrast whats required from startups. It's just a fancy way of saying "we gonna do more source code versioning stuff".
Can you explain why? I really don’t see the draw of public roadmaps. I buy a product because it works for me now. If there are improvements I need in the future the company either implements them or they don’t. A public roadmap doesn’t improve my experience at all. In fact, I might be less likely to buy the product.
This feels like it opens github up to the vocal minority to scream and yell publicly about features they want. Some of which could negatively impact other users. And github will have to succumb to the pressure of that minority.
I fail to understand how an open roadmap would make you less likely to buy a product. If you compare two products with the same current feature set but one has an open roadmap and one has none - are you saying physical access to a roadmap would deter you from buying that product and instead buy a product that has no roadmap?
A public roadmap functions as a communications tool and sounding board. However, it does not negate strong product leadership or moderation of course.
Interestingly, my small SaaS was using GitHub projects as a public roadmap for the last 2 years already! Even at our small scale it has already proven useful for finding beta users, getting feedback etc.
With Github I’m not so sure. The online mob usually gets what they want. Having said that, the overlap between those paying the most for Github and those demanding the most might be 100%.
