Also, from my limited experience with a single OLED screen, it seems that most stuff was created for a certain kind of screen without as much colour fidelity, and now that stuff seems far more...obnoxiously "saturated"?...on an OLED screen.
> I've heard that there are screen lifetime issues?
This has gotten much, much better, especially with "tandem OLED" where you just stack two of 'em on top of each other. It should be fine these days.
> Also, from my limited experience with a single OLED screen, it seems that most stuff was created for a certain kind of screen without as much colour fidelity, and now that stuff seems far more...obnoxiously "saturated"?...on an OLED screen.
That's up to the display manufacturer to calibrate the screen. The content should just be what it is and specify its colorspace properly. (Note, "properly" depends on the environment around you, so if you really care about this you have to participate too.)
Lots of devices that come with OLED displays come with a "vibrancy" mode turned on by default that oversaturates colors until you turn it off. It does look great at a glance tho!
Conversely lots of contents is produced on/for less-than-stellar displays and gamma+color-profiles-be-damned overcompensate with more saturated colours at the data level because it's going to show up toned down.
When a display is actually able to put out the colours it then looks gaudily oversaturated. I've had such problems already with non-OLED "somewhat† calibrated" good quality screens as well.
† I mean I did not calibrate them, they were factory calibrated with a good enough test curve slip in the package.
Pixel aperture ratio has increased drastically since the early displays. This drops current density for a given amount of light output, and there's a nonlinear relationship between current density and segregation so that helps a ton.
Deuterium helps make more light per unit current, improves current density, improves lifetime.
Microlensing of your customers will accept narrower viewing angle, improves brightness and lifetime in the same way.
There was a time that OLED problems were so huge Lenovo cancelled their usage on laptops for many years (e.g X1 Yoga Series). It was so bad that I got the next generation laptop for free when it was released.
Why would you generate SQL using another programming language? To me that sounds like something you'd only do if you're deep in an ORM with no escape hatch. For data analysis tasks, that's extremely unergonomic and you should definitely just write normal SQL. Use the ORM for CRUD. I've never seen an ORM that won't let you drop down to regular SQL for ad-hoc queries.
Editor completion is an extremely low ranking aspect for choosing technologies for data analysis. If SQL is the better tool but you're not using it because it doesn't have editor completion, then you need a better editor. It pains me when people prioritise "developer experience in VS Code" over "actually the correct technological choice".
I ask this sincerely, as I’ve seen many scenarios over the years where a tool like Django is used to manage a Postgres database, solely that the schema migrations are captured in version control. A .sql file can be in version control, but rolling back a git commit is not the same as being able to roll back a schema migration in the actual database.
Sure, happy to go into it. Firstly we need to distinguish between version control of DQL and DDL.
In the context of comparing SQL and Pandas, we're mostly talking about DQL, so version control for this is exactly the same as any other query code.
For the DDL side that you're asking about, indeed just version controlling SQL files won't work, you need to use a proper migration tool. There are many available that do pure SQL migrations in the same way Django works (a sequence of up/down operations to perform or revert a migration). Personally I use migrate[1].
So you really can achieve the same thing. Personally I like this approach because it can do anything Django can, but it can also do more complicated migrations that can't be expressed by an ORM's DB-agnostic abstract layer. Pure SQL migrations also decouple your database schema from your ORM/framework, which I think is sensible anyway; databases & data tend to be much stickier than apps & frameworks.
A downside here is that you need to do some extra work to keep models in sync with the schema. But the point I was making with my original post is that you can totally use ORMs for CRUD and auto-generate away all that boilerplate, _in addition to_ using raw SQL for complicated data analysis. My point is it's not binary, you can mix them, and there's nothing forcing you to generate _all_ your queries if you use an ORM for most of them. Use the ORM to manage schema, then SQL for a one-off query - still works.
You roll back a schema migration on a dev/test database by nuking it and regenerating it, probably with the same tools you use to manage the rest of your environment.
You don't rollback a schema migration to a production database, because that is impossible. What has been done cannot be undone.
"Correct technological choice": I think relational algebra style APIs (a la Polars) are the "correct technological choice" here. SQL is just a tool to express relational algebra, and I'm not sure it's a good one.
I personally love any of the IDEA platform products, such as IntelliJ Ultimate, DataGrip, and also DataSpell.
For strictly analysis, I’d recommend DataSpell as it’s more oriented towards that. Additionally, it has built in functionality to do sql queries in notebook cells and will save to a variable which is a data frame.
Possible, maybe. End up with a working machine? Probably not. There are alternatives like coreboot [1] libreboot [2] system76 [3] but this isn't something that can be flashed to just any board. These alternatives would have to become supported by the manufacturer upstream from the dodgy resellers that end up on Amazon and I don't know if that might actually make it easier for dodgy players to replace it with a backdoor version. The low-end devices like mini-PC's do not have dual firmware options like some of the Asus mobo's and a few other mainstream vendors.
No, because if my case holds more genera (and I suspect it does), the answers are in part out of sheer frustration, and therefore prone to being similar to the last one given.
I didn't exactly rage quit but did think it was silly.
I wouldn't describe teal as blue or green any more than I'd describe purple as red or blue, so being forced to pick felt silly. Like being forced to choose my seventh favorite Norwegian glacier - technically its a valid question but my answer is necessarily going to be arbitrary.
The root problem is a lack of imagination that cannot fathom how the person making the judgement might find themselves in the position of the judged, in the not-so-far-future.
The good news is that reality does not care whether or not you lack imagination. One can only marvel then, at the sequence of events that lead to the "unthinkable".
The implication is we don't live in a peaceful society. Violent coercion is just disguised as men in suits writing contracts that are economically infeasible to challenge backed up by skewed access to the State's means of physical violence.
In many ways, one could make the argument, a world where everyone is on an equal footing to do violence is preferable to one in which it is restricted to only a few.
Proponents will speak to deterrence and preservation of ‘liberty’/non-despotism, opponents will speak to the very real death toll inflicted by these weapons.
That's ridiculous, markets can absolutely "lie". Markets are aggregates of particpant sentiment and are wrong if that sentiment is wrong. One clear example is when a company is committing fraud that boosts their stock price.
Human beings, in aggregate, tend to be pretty good at predicting some things that individual humans can't (classic examples being number of objects in a jar or weight of an animal) and markets are a weighted and incentived system that exploits this property.
Prediction markets are better at predicting somethings and worse at others and their fallibility is also dependent on how well they're are structured.
1) Bioreactors have available many options other than antibiotics for controlling bacterial growth.
2) A bioreactor is not "basically just an animal with a severely curtailed feature set". A bioreactor is not even "basically an organ with a severely curtailed feature set".
3) What precisely do you mean by "sterile techniques will only get you so far, especially at scale"?
There are actual issues with lab-grown meat. In a nutshell: nutritional quality, and the high degree of post-processing likely needed in order to make them palatable in terms of texture and taste.
TL;DR when someone reasons by analogy, doubt everything they say.
Also, from my limited experience with a single OLED screen, it seems that most stuff was created for a certain kind of screen without as much colour fidelity, and now that stuff seems far more...obnoxiously "saturated"?...on an OLED screen.