What big gap are you referring to that you believe exists between the theory of any quantum computing platform (which is device physics) and the experiment?
You seem to be conflating the theory with pitches to investors?
The number of qubits is increasing exponentially, and the error rates are getting lower.
People have factored numbers larger than 21 (not that Shor's algorithm is commonly used benchmarks by experimentalists at this point but people with little knowledge about quantum computers and device physics love it, https://link.springer.com/chapter/10.1007/978-3-032-12983-3_... did 221 and and in fact, you can do it yourself using Qiskit on IBM's publicly available devices [or on a local simulator for few qubits] following their tutorial https://qiskit.qotlabs.org/docs/tutorials/shors-algorithm if memory serves the largest instance for public is ibm_kingston with 156 qubits https://quantum.cloud.ibm.com/computers?limit=25&system=ibm_...) but it will take more time until we have millions of good qubits to harvest your Satoshis.
For the programmer folks here, as a physicists working on the device side of things for many years now, the best analogy I have is: we didn't get from a few hand-made vacuum tubes to billions of transistors with 18A manufacturing process overnight, and we won't get from hundreds to millions of better qubits overnight either. A realistic expectation would be thousands within this decade, but keep in mind that the growth has so far been exponential in various types of qubits, much like Moore's law, so reaching to millions of qubits shouldn't take us 10 millenia.
If what determines the value of a language libraries (which makes no sense to me at all, but let's play your game), then it is one more argument against Python.
You don't need FFI to use a Fortran library from Fortran, and I (and many physicists) have found Fortran better suited to HPC than Python since... the day Python came to existence. And no, many other scripting languages have wrappers, and no, scientific computing is not restricted to ML which the only area Python can be argued to have most wrapper libraries to external code.
Language matters, and two-language problem is a real problem, and you can't make it go away by closing your ears and chanting "doesn't matter! doesn't matter!"
Julia is a real step toward solving this problem, and allows you to interact with libraries/packages in ways that is not possible in Python + Fortran + C/C++ + others. You are free to keep pretending that problem doesn't exist.
You are making disparaging and hyperbolic claims about hyperbolic claims without proper attribution, and when asked for source, you cry foul and sadly try to appear smart by saying "you're acting dumb". You should take on your advice and instead of "acting dumb", explicitly cite what "promises" or "bombastic claims" you are referring to. This is what I asked you to do, but instead of doing it, you are doing what you are doing, which is interesting.
Since you have a rosy picture of Python, I assume you're young. Python has been mostly a fringe/toy language for 2 decades, until around ~2010, when a Python fad started not too different from the Rust fad of today, and at some point Google started using it seriously and thought they can fix Python but gave up eventually. The fad lived on and kept evolving and somehow found some popularity with SciPy and then ML. I used it in 90s a little, and I found the language bad for anything other than replacing simple bash scripts or simple desktop applications or a desktop calculator, and I still think it is (but sure, there are people who disagree and think it is a good language). It was slow and didn't have type system, you didn't know whether your code would crash or not until you run that line of code, and the correctness of your program depended on invisible characters.
"Ecosystem" is not a part of the language, and in any case, the Python ecosystem is not written in Python, because Python is not a suitable language for scientific computing, which is unsurprising because that's not what it was designed for.
It is ironic you bring up hype to criticize Julia while praising Python which found popularity thanks to hype rather than technical merit.
What promise are you referring to? Who promised you what? It's a programming language.
Telling what? Did you actually listen to the talk that you linked to, or read the top comment there by Chris Rackauckas?
> Given all that, outside of depending heavily on DifferentialEquations.jl, I don't know why someone would pick Julia over Python + Rust.
See his last slide. And no, they didn't replace their Julia use in its entirety with Rust, despite his organization being a Rust shop. Considering Rust as a replacement for Julia makes as much sense to me as to considering C as a replacement for Mathematica; Julia and Mathematica are domain specific (scientific computation) languages, not general systems programming languages.
Neither Julia nor Mathematica is a good fit for embedded device programming.
I also find it amusing how you criticize Julia while praising Python (which was originally a "toy" scripting language succeeding ABC, but found some accidental "gaps" to fit in historically) within the narrative that you built.
> In any non-toy Julia program that's not going to be the case.
1. "any representation of 3D rotations using only three values"
That is not representation, that is parametrization. Euler-angle parametrization sometimes fails because it is not a correct parameterization of SO(3) in general by construction, this is why it sometimes fails (essentially, the three consecutive rotations can sometimes effectively collapse into two for certain set of angles, regardless of how you choose your 3 axes, in which case you can't relate 2 independent parameters back to the 3 independent axis-angle parameters). The correct parametrization of SO(3) is the axis-angle parametrization, which can be represented using quaternions or 3D reals matrices.
The "representation", on the other hand, would typically be unit quaternions or 3D orthogonal matrices.
2."it can be proven that any representation of 3D rotations using only three values must contain discontinuities." where is that proof and what discontinuity are you talking about? It sound like he misunderstood what "SO(3) is not simply connected" means. Lie groups are differentiable.
3 parameters are sufficient to represent any 3D rotation. The natural parametrization of all Lie groups, including SO(3), is the axis-angle parametrization, and their elements have the form exp(i θ n.J) where n is a unit vector defining the axis of rotation, θ determines the amount of rotation, and J is a vector of the generators of the corresponding Lie algebra. The "regular" 3D matrix representation in the axis-angle parameterization is obtained with so(3) generators L_x, L_y, L_z in their fundamental representation.
Basis quaternions i, j, k (which can be represented by Pauli matrices) obey the same Lie algebra as L_x, L_y, L_z, but the group that it corresponds to (which is SU(2)) is a double cover of SO(3) (up to a sign), so they can still be used for implementing 3D rotations once you pick a sign.
Also physicist here. I've worked on conventional superconductors, but never on unconventional ones. Last I heard, it was believed to be mediated by magnons (rather than phonons). Who claims it is due to Coulomb interaction?
You offer condolences, and you say you understand. Thank you, but what do you think you understand?
Your analogy that somehow equates car accidents to nuclear disasters is not even wrong, and the fact that in your mind these can somehow be put into the same analogy is a testament that you don't understand.
1. With a car, you make a decision to use it or not given the risk factors. In contrast, the actual risks of a nuclear reactor built by a corporation in a remote area are not born by the company but rather by the town folks who have been living there and their descendants (an entire population) who have no choice in operating a nuclear power plant in their neighborhood.
And as we also see here, for few who dare to raise their voice, they are shut down by the corporation and local politicians with promises of a bright future or blamed with ignorance by some of their peers. Those same people who are not going to take responsibility when the nuclear disaster happens.
2. A car accident can kill a few people and financial damages are small and can be covered by an ordinary insurance company. A nuclear disaster can kill and make sick an entire population, destroy their livelihoods and poison the environment for generations, and caused damages are so great, well beyond the capabilities of any insurance or electrical company. In practice, the burden of the material damages fell upon the citizens of the entire nation.
As I already said, ever-improving nuclear reactors can result in a nuclear disaster, however "modern" they are. You can guarantee otherwise only in the imaginary world of spherical cows. As long as nuclear power plans are run, Fukushima disaster is not going to be last nuclear disaster the humanity has seen.
And again, the question is not "will another nuclear disaster happen". This is Murphy's law. The question is "when it happens, what will its effect be?"
If a corporation wants to operate a nuclear reactor, they should build it hundreds of kilometers away from any human settlement, with proper containment and cleaning mechanism in place that can be deployed right after the failure.
I looked at Wolf Creek Generating Station on Wikipedia, what of it? I don't see a nuclear disaster happened there. I hope the day won't ever come, but I would be interested in hearing your opinion on the matter after Wolf Creek melts down like in Fukushima ---at which point you will actually understand.
I'm a physicist. What education are you referring to?
Downplaying the risks of nuclear power plants, which are real, is easy to do, as long as it is far from your home. Most people can't grasp the reality of a nuclear disaster or its aftermath, because they haven't seen it. I have.
Yes, engineering has progressed, yes, there are ever improving safe-guards.
As you're probably aware, in Japan, we had a major disaster 14 years ago. Such disasters are very rare, but they will keep happening in future, and no electrical company that build nuclear reactors can guarantee that the probability is 0%. It is a matter of time (maybe in 50 years, maybe in 500 years), and when it happens, who is going to take responsibility for all the lives and damage? Toden couldn't, and certainly not the armchair (nor actual) nuclear engineers who like to lecture people about how they are uneducated.
To the parent and its sibling comments: There is no atomic or subatomic current that can explain ferromagnetism in any approximation.
You read some Wikipedia pages and Feynman lectures of physics. I'm a physicist who has done well over a decade of research in magnetic materials.
In understanding of ferromagnetism, many incorrect theories have been proposed. By connecting ferromagnetism to circulating currents (i.e, paramagnetism and diamagnetism), you just repeated the same mistake.
You're trying to bend the words to avoid being wrong. Physics is not philosophy or debate club. There is no approximation in physics in which electron is a ball with some radius, or its spin is due to a circulating current in physics. Any such explanation attempt fails spectacularly if you actually try to do the math (which gives an electron surface that is moving faster than speed of light, as Uhlenbeck/Goudsmit who proposed this incorrect idea quickly found out), so it doesn't even work as an approximation of any kind.
> Yet the concept of spin in quantum mechanics was originally developed using macroscopic rotations as an analogy,
Who developed this theory in quantum mechanics, where and when? Pauli, who first introduced it into quantum mechanics and the namesake of spin 1/2 matrices, insisted that it is purely quantum mechanical with no classical analogue. And regardless of who said what over 100 years ago, today, it is well understood that spin has nothing to with electric charges that move or rotate in space.
More importantly, the reason ferromagnetism develops in the first place is due to exchange interaction (as I wrote above) between magnetic moments, which is due to Pauli exclusion principle and also has nothing to do with movement of charges.
Furthermore, such magnetic moments (called magnetic impurities in that context) ruin the superconducting order by breaking the time-reversal symmetry, so trying to make a connection to ferromagnetism in the context of superconductivity is even worse.
Ferromagnetism has nothing to do with currents, it is due to aligned spins of partially filled shells. Below a certain temperature (Curie temperature of the material), exchange interaction (which penalizes any misalignment, in the case of ferromagnetic exchange interaction) between electrons leads to this alignment.
Spin is a type of intrinsic angular momentum that is not associated with any spatial motion.
The Feynman lecture you linked to is an explanation why currents fail to explain ferromagnetism. You need to read the next chapter, but being a lecture for undergrads, it doesn't go deep into the subject anyway. If you're really interested, any modern book on magnetism would be much helpful.
> You did say that, but it's not the part of your post they were responding to.
So if someone criticizes a portion of your statement which is already countered by your original full statement, you're not allowed to remind your full statement. What kind of logic is that?
My original post says the point of Vulkan Video is it will be cross-platform and cross-vendor. And gives one example of cross-vendor side of things on Linux.
Someone criticizes me by essentially saying "you are incorrect, that's only on Linux. Windows, Android and iOS have their own video APIs...". This "correction" is incorrect because I already said on Linux, and it goes on to actually reinforce the post that he is responding to by highlighting cross-platform side, which also is in the post he is responding to.
So, if you look at the full conversation, the criticism is self-contradictory. This is what I'm pointing out, but you are implying I'm not allowed to do that.
I disagree. When you fragment a statement in a way that changes its meaning and make a straw man out of it, people are justified in responding to it.
What is "incorrect"? The full sentence that you conveniently chose to cut in the middle before quoting (apparently to fit into some pessimistic forecast about the significance of Linux desktop) reads
> Firefox currently supports hardware video decoding with Intel's vendor specific VA-API only on Linux, which is not supported by NVIDIA.
(emphasis added)
You further wrote:
> Firefox uses Windows Media Foundation, which is cross-vendor, on Windows. It uses MediaCodec on Android which is again cross-vendor.
And? None of those APIs are cross-platform. Vulkan Video will eventually allow developers (including Firefox developers) to write a single code path for video to cover a wide range of platforms and vendors (likely with the exception of walled gardens like Apple-land, although someone might find a way to support like via a wrapper like MoltenVk for Vulkan).
What of it? So does nvidia-vaapi-driver. They're third party projects, that's very different from "supported by the vendor", and doesn't change the fact that NVIDIA as a vendor offers no support for VA-API.
You can make the same argument for VDPAU. AMD officially supports it, and there is an unofficial translation layer with limited capabilities for some Intel GPUs. Is VDPAU not a vendor specific API anymore then?
Intel, AMD and NVIDIA have their own vendor-specific video APIs, and even when they provide official support for the API of another vendor, it tends to expose a limited subset of the full functionality (like the list of available codecs and encoding features).
You are free to call these vendor specific APIs for what they are or something else, but the reality has been that there is no single video API officially supported by Intel, AMD and NVIDIA. This changed with Vulkan Video.
But Vulkan Video isn't just about desktop: mobile devices, Raspberry Pi, etc. are expected to get on board with it eventually, just like they did with Vulkan.
> It's supported by the open source drivers for GPUs from all 3 vendors.
Which 3 vendors are you referring to? Intel, AMD, and who?
> It's just that the open source drivers for Nvidia cards are not very practical and the proprietary drivers only support vdpau and nvdec/nvenc
Why are you bringing up open source drivers, and what is not practical? Both official open source drivers (open-gpu-kernel-module) and unofficial open source drivers (nouveau, through binary firmware) support VDPAU. However, NVIDIA's drivers (open source or binary) does not support VA-API.
> They have perfectly great existing hardware decoder offloading APIs via the various OS' native APIs for videos
One vendor specific API, not "various OS' native APIs".
Firefox currently supports hardware video decoding with Intel's vendor specific VA-API only on Linux, which is not supported by NVIDIA. (A third-party VA-API to NVDEC translation layer for Linux does exist on GitHub, nvidia-vaapi-driver, but it's not yet reliable as the officially supported VDPAU or NVDEC, and is not included in official linux package repositories.)
Intel has VA-API, AMD has AMF, and NVIDIA has VDPAU which is being replaced by NVDEC/NVENC.
The idea behind Vulkan Video Extensions is to have a vendor independent and cross-platform video API.
This is a meta-study, touching on that "contrast" already: there is a subsection in the paper dedicated to this, where they claim that
"The major factor in cerebral bleeding however is hypertension, and in an RCT of aspirin based on more than 18,000 hypertensive patients—all of whom were receiving ‘optimal’ antihypertensive treatment—there were no additional cerebral bleeds in patients randomised to aspirin" (Refs 46 and 47).
which seems to be in contradiction with the article corresponding to the news you linked to: https://jamanetwork.com/journals/jamanetworkopen/fullarticle... and strangely doesn't cite or comment on Refs 46 and 47 from the paper of the main thread, possibly because they don't seem to be focusing on older adults.
There is also a subsection on gastrointestinal bleeding.
Intracranial bleeding isn't necessary something that cause permanent damage, or lethal by the way.
Depends on the encoder, this website provides easy-to-visualize data sets for various encoders at various settings
https://arewecompressedyet.com/
AV1 encoders tend to have better VMAF score at a given bits-per-pixel.
You seem to be conflating the theory with pitches to investors?
The number of qubits is increasing exponentially, and the error rates are getting lower. People have factored numbers larger than 21 (not that Shor's algorithm is commonly used benchmarks by experimentalists at this point but people with little knowledge about quantum computers and device physics love it, https://link.springer.com/chapter/10.1007/978-3-032-12983-3_... did 221 and and in fact, you can do it yourself using Qiskit on IBM's publicly available devices [or on a local simulator for few qubits] following their tutorial https://qiskit.qotlabs.org/docs/tutorials/shors-algorithm if memory serves the largest instance for public is ibm_kingston with 156 qubits https://quantum.cloud.ibm.com/computers?limit=25&system=ibm_...) but it will take more time until we have millions of good qubits to harvest your Satoshis.
For the programmer folks here, as a physicists working on the device side of things for many years now, the best analogy I have is: we didn't get from a few hand-made vacuum tubes to billions of transistors with 18A manufacturing process overnight, and we won't get from hundreds to millions of better qubits overnight either. A realistic expectation would be thousands within this decade, but keep in mind that the growth has so far been exponential in various types of qubits, much like Moore's law, so reaching to millions of qubits shouldn't take us 10 millenia.