High battery drain during standby on Linux can be due to the system not entering the proper sleep state. I had this happen to me on an AMD machine lately, in that case disabling secure boot solved the issue.
Here is a pretty detailed blog post in checking if that is the problem and how to deal with it on intel systems
Suprised there is so much love for Poetry. Having only used it sparingly (and having some dependency issues with it at the time) I do not see the benefits over conda (miniforge version to easily avoid anaconda) or mamba if you care about speed.
Conda is missing a significant number of python packages and many they do have are perpetually out of date - coincidentally that includes poetry and pdm.
Capasso's [1] group has been working on projects like this for a couple of decades. It falls within the realm of work on metasurfaces. At a high level you can consider the silicon working in a sub wavelength regime, so that the optics interacts with an effective material which is engineered by changing the geometry of the sub wavelength features. They recently launched a startup [2] to commercialise the developed capabilities.
Voila is quite nice but I find panel [1] is the best option these days. It has plenty of widgets, including those from Voila which can be used as a backend, a few different ways of defining callbacks and has added nice features lately like autoreload if you are using scripts instead of notebooks [2] and new fast HTML elements so it's super easy to define custom widgets straight from the web. They have a discussion page comparing the project to the standard alternatives (dash, streamlit, voila etc) [3]. The docs could do with improving but their discourse is very active [4].
We find that design decisions like forcing data scientists to code UI callbacks are big limiters to adoption, which is intuitive as that's pretty close to telling them to write JavaScript in Python. Same thing for styling ("CSS in Python".) They can in theory, but rather spend time on other things.
So far, the only low-code PyData framework we saw that avoids most "JS in Python" is StreamLit. However, even there, it is still awkward in practice, so we still see limited adoption by folks who are fine with notebooks, so rarely goes beyond a champion. So there is room to grow.
I would still recommend panel, it is perfectly straightforward to make a clean UI in pure python and the "depends" approach to interactivity works just by adding decorators to functions. You can prototype in either notebooks or scripts, particularly with the auto reload feature which I believe is inspired by streamlit.
I don't think you're getting the difference between possible & clean for programmers, vs. easy & straightforward for the target market. Most non-engineers don't want to spend time learning and tweaking this stuff, they want to work on the analysis, domain problem, and later, sharing it with others, not spending hours learning & debugging development & UI stuff. That's time away from their actual work & their families.
Ex: It took me awhile to appreciate StreamLit's builtin layout: it largely eliminates "HTML-in-Python", so one less thing. Likewise, decorators are weird magic, so yet another educational hurdle. If a tool could do excel -> dashboard, most would rather that! While I love that stuff, and I can recommend it to coders, I've learned to not recommend it to teams that can't guarantee everyone is... which is most. It sounds like Panel is slowly reinventing StreamLit, but as StreamLit isn't even there yet, for most corporate use, I'd be trying to do much more than catchup on this specific aspect if you want it to be relevant here.
Fun story: a PhD friend for a much-lauded company on HN led a team of ~20 analysts. About ~2 people loved Python, and the rest would write pages of SQL to avoid it.
Thanks for the response and context. I work in a different domain to data science and it's fair to say that most people I work with would prefer writing a few 10s of lines of python than many pages of SQL!
Regarding your second point, looking at streamlits announcements page [1] it seems many features being added, layouts/themes and session state/callbacks for example, indicate to me that streamlit is heading in the direction of panel/dash more than the other way. Streamlit also emphasizes using decorators for caching [2], which I agree can end up with some overall state that is a bit magic.
Overall I think the optimal use cases are a bit different for the sets of tools, and I find the approach of dynamically calculating a full script for every change of a slight widget quite onerous, and actually just not feasible for the use cases I have.
Right, but the key is "you must do X" vs "later, and only if you want, you can optionally layer on X". Users of StreamLit disinterested in programming noise have a lot fewer framework-mandated operational burdens than Panel because the smart defaults are smart. In contrast, anyone using Panel has do a lot more practically + conceptually to get a minimally reasonable result. That's the difference between 1-2 people in a team/org being successful, vs most.
Though again, I'm not a zealot: the StreamLit starting point is still too high in my experience for most teams, so both are wrong. For most people, the default should be no Python, at most SQL or whatever DB lang, and optionally drop down to Python for some cool bits. Ironically, I just got off a call a few hours ago where this exact issue makes us excited about starting with StreamLit, yet we're also already scheduling tools to replace it with something more realistic for 10X+ wider enterprise adoption.
Yeah, first realised this when it became clear that all the "breakthrough infections" (with the 0.1% rate for fully vaxed) were actually "breakthrough hospitalizations" and that the US was not actually tracking the former consistently.
For the second point I guess it depends on the jurisdiction, there was a nice chart from the CDC in an Ars article indicating how you should still expect a relatively higher rate of vaccinated people in hospital when the vaccination rate is high (and also less people in hospital overall!).
Looks nice, I used a more complicated version during undergrad for a physics lab. It was great as you could explore length contraction, time dilation etc, and also had toggles for enabling some of the really crazy relativistic effects. https://people.physics.anu.edu.au/~cms130/RTR/
Plotly is quite nice but I find Dash's use of HTML for layouts a bit forced. For dashboards I have been using Panel, which supports plotly plots, which keeps things closer to pure python https://panel.holoviz.org/index.html
Will likely pop up on Ian's YouTube channel (techtechpotato) sometime soon. The one leading into this chat about Tenstorrent has nearly been up for a week https://m.youtube.com/watch?v=sMvudTBBQNw
This article is not that clear (there is no frequency shift occuring). As others say, the authors are using speckle imagery, which relies on the wavevector of the illuminating beam (rather than the frequency). By adding the hyperbolic metamaterial the authors can access wavevectors beyond the diffraction limit, so that once they do the appropriate prost processing achieve super resolution imagery.
It's not directly related but reciprocal space and Fourier imaging is quite interesting for those that are not aware of it (such as estimating the size of a crystal lattice by looking at the diffraction pattern)
Yes - the technique is called ptychography [0] and there have been several recent electron microscopy papers too demonstrating how this technique (image reconstruction from Fourier space patterns) can reach beyond instrumental resolution limits [1, 2].
Most computer folks are actually unaware that physicists were doing fourier transforms using optics long before the FFT existed. You can do physical convolutions using lenses.
...Am I having a stroke? Aren't you just talking about a prism? It converts time domain to frequency/space domain, just like the cochlea in the ear does with mechanical time-series.
As it happens, I did this in a physics lab just a couple of weeks ago. The basic setup is that if you pass a collimated beam of light through a mask and then focus it with a lens, the focus will contain the 2D Fourier transform of the pattern on the mask. Adding another lens does another Fourier transform getting the original image back (but flipped). By masking appropriate sections of the Fourier transform, you can physically implement various filters — e.g. a low-pass filter becomes a mask letting through only the central portion of the Fourier transform. One I remember trying is that if you take a periodic pattern like a rectangular grid, and then pass the Fourier transform through a thin slit, you can filter out only the horizontal or only the vertical component of the grid. Pretty cool stuff.
Lenses bend EM waves proportionately to their frequency, so it naturally separates the different frequencies. Bam, you've described your EM source in the frequency domain.
> Lenses bend EM waves proportionately to their frequency
Is this exact? I was under the impression that it's a linear approximation that's generally good enough for optical component glasses over the range of visual wavelengths.
(I always found it a bit frustrating that in my Mechanical Engineering undergraduate classes, they almost always introduced linear approximations without any discussion about the conditions under which the approximations held. Sometimes, they didn't even mention that the linearization was an approximation.)
Here is a pretty detailed blog post in checking if that is the problem and how to deal with it on intel systems
https://01.org/blogs/qwang59/2018/how-achieve-s0ix-states-li...