tagrun

Even when targeting 8-bit displays, recording 10-bit is still beneficial. Besides obvious benefits in editing and encoding, simply playing a 10-bit video file straight from the camera on an 8-bit screen is useful when applying any common "effects" (brightness, contrast, LUT, colorspace transformation, gamma correction, tonemapping, etc etc).

> Btw, over 10 years old Canon 5DMIII can shoot RAW video with MagicLantern

Not sure why that is relevant in this context, but any digital camera would be capable of shooting RAW video with hacks: they all have photo-sensors and RAW simply means dumping the digitized signal data in a suitable format. It's a matter of hacking the device. But it doesn't mean you should do it, especially when that's not what they're designed for. Unsurprisingly, in the case of Canon 5D Mark III (which is a photo-oriented camera lacking a stabilizer, you can read about further limitations such as the under-utilized sensor in video mode [which typically happens due to hardware limitations] here https://www.dpreview.com/reviews/canon-eos-5d-mark-iii/25), a lot of potential problems await apparently: https://www.cined.com/consider-this-before-you-shoot-raw-on-... For RAW video, at the very least, you need a more reliable storage hardware hooked to your device with sufficient capacity for recording (meaning CFExpress or NVMe via USB, not SDXC), and possibly active cooling, both missing from that camera so it would require some hardware modding.

That being said, modern video cameras can also do more than the trivial task of recording RAW: they can handle processing and encoding of higher quality videos (resolution, bpp, frame rate) in real time, which requires specialized silicon missing from Canon 5D Mark III.

> Manufacturers should open/update code to their old cameras that are capable do this. Its really disappointing when marketing ruin whole product. No wonder that camera market dying.

1. The camera hardware isn't actually designed for it (by the way, even with new video cameras, there are usually trade offs, you turn one feature on and another becomes inaccessible) 2. that's not the reason why the consumer camera market is shrinking, and 3. doing that would shrink the market volume even further.

If you read the last sentence of the post that you're replying to, I already said that it won't matter to most people.

That being said, "is only for editing in post" (which is not really true, banding is an issue in scenes with high dynamic range with 8-bit, not limited to sky but also with strong lights or deep shadows) doesn't mean people won't want it. Around 10-15 years ago, in the age of single-digit-GB slow SD cards and weaker camera/phone processors, that's what people used to say about RAW photos repeatedly. Now it is mainstream in even in phones, with built-in editing apps and easy to use desktop programs with few knobs. This means editing itself in post isn't a barrier for mainstream adoption, the issue is video editing currently has a high barrier as it is essentially impossible on portable devices, the programs have their learning curves, and the whole stack requires some financial investment.

I'm guessing you don't record videos then.

In terms of video capabilities, Canon 5D Mk II is limited to 8-bit 4:2:0 1080p H.264 recording at 30fps, maxing out at 12 minutes of recording. That is a far cry from 10-bit (or 12-bit) 4:2:2 4K, 6K or even 8K RAW or ProRes at 120fps or higher with unlimited recording from a similarly priced camera in today's money.

(It's also limited in terms of RAW photo as well though: the best recording option is 8-bit 10MP RAW)

No phone comes anywhere near that either, not to mention the lenses for phones can't compete with the real interchangeable lenses. The difference probably doesn't matter to someone who is just going to record his baby walking around and watch it on a 7 inch screen, but of course that's not the target audience for those cameras.

If you look at the plots in the 2nd link you are referring to, they show the gains of AVIF over WebP are also similar, so the case of AVIF "isn't a sufficient incremental benefit" as well by your criteria.

Not to mention JPEG XL can do lossless and progressive on top, and that avifenc is much slower than cjxl.

That's incorrect, you can defrag with

    btrfs filesystem defragment /path

There is also the mount option autodefrag

Physicist here. Why is this crackpot paper on the front page of HN? (I'm guessing posted by the crackpot author himself)

No, you can't reconstruct physics from those 9 half-wrong statements that were pull out of thin air: entropy can very well be 0 (example: any microscopic system with 1 possible configuration, or any pure quantum state has 0 entropy), the minimum of action can be any number since the Lagrangian can be shifted by an arbitrary constant without changing the physics (and no you can't derive quantum mechanics or restrict possible Lagrangians just from the existence of \hbar), it is not possible to obtain the standard model Lagrangian just from the group structure U(1), SU(2), SU(3) and the number of particles and various constants, and the whole thing about maximum force (of which 1/3 of references are devoted) is a classical statement and is likely to be wrong in a quantum version of gravity.

The rest appears to be random ramblings based on these 9 statements using middle school math.

For non-physicists, this is not how physics papers look like (ie, mishmash of random statements pulled out of thin air with a sprinkle of real physics, followed by middle school math, and then wilder claims with additional assumptions out of thin air). Please try reading an actual physics paper from an open-access journal, for example PRX Quantum https://journals.aps.org/prxquantum/ might be somewhat relevant to HN audience since there are a lot of papers connected to quantum computing

You can call in convention as many times as you want, but unfortunately, it just is not a convention. It is called theory of electrodynamics which is a well established, experimentally verified branch of physics.

What exactly is more subtle and complicated in the context of Maxwell equations? If speed of light has the anisotropy that you are describing, Maxwell equations must be incorrect. In what electromagnetic experiment has such anistropy of magnetic or electric constants have been ever observed?

You're basically saying "you haven't measured the one-way speed of light directly, so you haven't ruled it out the possibility of my exotic theory", but it is actually been ruled out by Maxwell equations a long time ago. Unless you have some experimental proof that Maxwell equations need to be modified to accommodate that elusive version of your aether, you can't claim the existence of such an anisotropy.

Physics is well connected in that you can't change one part of it (in your case, c in the context of special relatively) just because you found something that wasn't experimentally ruled out, and hope the rest of the physics (basically all massless field theories and relevant experimental results in this case) won't break.

What is not true? You can't have reference frame independent (which is a term that also includes orientations) Maxwell equations and anisotropic speed of light at the same time.

If Maxwell equations are correct (which was already well-tested by then), speed is already the same for forward and backward propagating electromagnetic waves (=light), and there is no other spatial anisotropy either.

Differing one-way speed of light is an amusing "loophole" in the experiments measuring the speed of light (which requires one particular magical angular distribution of c to slip through a Michelson-Morley interferometer) but never existed in the theory that directly predicted it to begin with, so if you insist on it, one needs to ask how would that even work with the rest of physics? c doesn't have a spatial/direction preference in electrodynamics or quantum electrodynamics, vacuum permeability and permittivity (\mu_0 and \epsilon_0) don't have any observed spatial dependence. (Such a thing happens in condensed matter systems, effective mass, vacuum permittivity, g-factor, etc etc are in general anistroptic due to the medium, and is easily detectable, and their spatial derivatives do show up and need to be taken into account to match the observations as in the case of the kinetic term -\hbar^2(d/dx)(1/2m(x))(d/dx). Coulomb force doesn't get stronger or weaker when you rotate the table you perform your experiments on, current carrying wires don't produce stronger magnetic fields as you change their orientation (at least not within any observed precision). Similar goes for any field theory in the standard model.

I should add that in terms of experimental precision, quantum electrodynamics is the most accurate theory that we have, and can put very strong limits on possible anisotropic deviations if any.

Physicist here. It's not an axiom, historically, it follows from Michelson-Morley experiments, which precede special relativity, and whose purpose was to detect such an isotropy.

They repeated the experiment during different times of the day and different seasons, since the velocity of the Earth (and the lab) relative to the hypothetical aether would be different. The working assumption was that Galilean relativity was correct, and the Maxwell equations (which also define the speed of light) were only valid in the special reference frame of the aether.

Special relativity assumes Maxwell equations are always correct in all reference frames and orientations, which was already an experimentally observed fact (albeit puzzling, back then), rather than an axiom, which implied that it is Galilean relativity that is broken and needs to be refined.

You are not answering the (rhetorical) question that you quoted, and the answer to your response is already in the paragraph that followed it:

As I said, the necessary keywords for Googling it, along with a brief description is already present in the documentation.

The quibble here is about the necessity of reproducing the all the necessary keywords for an accurate Google search during every single function call.

> Mathematical notation is notorious for being an absolute mess of inconsistencies.

According to whom? What exactly is inconsistent?

So you think there's a cabal of "gatekeeper" scientists who are trying to hold the hordes of capable (yet somehow unfamiliar with the corresponding mathematical literature) engineers from making useful contributions to their libraries, because they use the conventional notation from the scientific literature?

They should instead tread carefully and dispose of all Greek letters in their code to ensure you are not put off, because that's the real reason that stops you from making useful contributions?

In the context of neural networks with differential equations (which appears to be the original poster's field), the trade-off depends: https://diffeqflux.sciml.ai/dev/ControllingAdjoints/

You are saying most people don't know what η in that context means (=people who likely haven't read a book or a paper on stochastic gradient, and don't know how it actually works), but they would somehow magically figure out what it actually does if we call it "learning_rate" in ASCII letters. How does that work?

FYI, the documentation of the function https://fluxml.ai/Flux.jl/stable/training/optimisers/ explicitly says it is learning rate:

> Learning rate (η): Amount by which gradients are discounted before updating the weights.

so this is already explicit to anyone who reads the documentation. The quibble in the post is about the named parameter.

Unlike the example in the link you give, η isn't a generic random name like a,x that can mean anything. If you ever read a paper on stochastic gradient optimization, you'd know that η means learning rate in the context.

It is bikeshedding because it is analogous to insisting that using "angle" instead of "θ", or "radius" instead of "r" in a 2D geometry library is superior and takes your code from being a lackluster to something that shines (in the words of the original author), while not having anything useful to say anything about the mathematical/technical aspects of the code itself.

Here is the definition of bikeshedding:

> The term was coined as a metaphor to illuminate Parkinson’s Law of Triviality. Parkinson observed that a committee whose job is to approve plans for a nuclear power plant may spend the majority of its time on relatively unimportant but easy-to-grasp issues, such as what materials to use for the staff bikeshed, while neglecting the design of the power plant itself, which is far more important but also far more difficult to criticize constructively. It was popularized in the Berkeley Software Distribution community by Poul-Henning Kamp[1] and has spread from there to the software industry at large.

from https://en.wiktionary.org/wiki/bikeshedding

What exactly do you think I said about Julia's linters and auto-formatters?

Juno, Jupyter support it out-of-the-box. With plug-ins: VS Code (unicode-latex), Atom (latex-completions), Emacs (which has TeX input), Vim (latex-unicoder), ...

So you don't know the Greek alphabet, but write high-performance computing code involving non-trivial math? (Julia's main use case is HPC)

Difference is 1 keystroke: you type \xi. Why is that a "real challenge"?

In his item #1, he links to https://discourse.julialang.org/t/loaderror-when-using-inter... The issue is actually a Zygote bug, a Julia package for auto-differentiation, and is not directly related to Julia codebase (or Flux package) itself. Furthermore, the problematic code is working fine now, because DiffEqFlux has switched to Enzyme, which doesn't have that bug. He should first confirm whether the problem he is citing is actually a problem or not.

Item #2, again another Zygote bug.

Item #3, which package? That sounds like an hyperbole, an extrapolation from a small sample, and "I'll avoid naming names" is a lazy excuse that would hide this. It is similarly easy to point to poorly written (or poorly documented) JAX code or Python code as well, so that doesn't prove that "Julia is lacklustre and JAX shines". Also, as an academician, I strongly disagree that learning_rate=... is better than η=..., but that's a matter of convention & taste, with no bearing on the correctness or performance of the package/language. It's bikeshedding. I agree that errors are usually not "instructable" in Julia ML packages (which needs to be improved), so monkey typing is less likely to succeed.

Item #4 is such a nitpicker. Sure, Julia may not have a special syntax for that particular fringe array slicing like Numpy does and you'll instead need to make a function call, but matrix/tensor code in Numpy is usually filled with calls to zips and cats with explicit indices, whereas in Julia, no explicit indexing needs to be done usually. Also, one can nitpick similarly in the opposite direction: Julia has many language features lacking from JAX or Python, why not talk about those as well?

I'm not a huge fan of Julia either (mainly because of it's garbage collected nature), but this is such a low-effort criticism of it.

Sandboxing without any overhead is pretty accessible on any Linux distro, so I don't see why QubesOS should be the go-to choice. For example, I use firejail for all internet facing applications that I use (also for Wine and any proprietary software): https://wiki.archlinux.org/title/firejail#Using_Firejail_by_... The setup takes just a couple of minutes.

You can have matrices of anything including rings, quaternions, octonions, dual numbers, matrices, vectors, bras, kets, etc etc, as long as you can multiply and add those objects. If you prefer real numbers, use the corresponding wavelength of the light, or voltage values in a photosensor, it doesn't matter. It still is a matrix.

Why do you mention things like data structures, enums and labels? This is math, not C++.

Anyway, the point is, any arbitrary 2D arrangement of numbers can be a valid matrix, whatever those numbers may represent.

My favorite colors are 1, 2, 3 and 4 in some 8-bit grayscale color space. Here's a matrix

  [ 1 2 ]
  [ 3 4 ]

This represents some linear transformation, and is a matrix. Are you trying to argue otherwise?

FYI, matrices transform between vectors within a vector space.

Any 2D array of data is a valid matrix.

But not any multidimensional data is a valid tensor.

Which mathematician disagrees with what exactly?

Tensors are introduced by physicists to ensure various physical quantities (which involve coordinates and their derivatives) do not depend on the arbitrarily chosen coordinate system. This is ensured through the transformation properties of tensors.

The name tensor itself comes from the theory of elasticity, Cauchy stress tensor, which BTW is uniform in many practical cases, and obeys the following tensor transformation rule:

https://en.wikipedia.org/wiki/Cauchy_stress_tensor#Transform...

like any other (contravariant) tensor must.

Matrices are not examples of tensors. Matrices can be used for representation of tensors, in which case tensor product becomes Kronecker product, but matrices in general don't have to represent tensors. You can put anything, including your favorite colors or a list of random numbers, in a matrix, and it won't be a tensor in general, not unless it must transform like a tensor under coordinate system changes.

Similarly, TensorFlow "tensor" is just a multidimensional data array, with no transformation rules enforced on it, and therefore is not a tensor.

It has nothing to do with tensor fields, uniform/constant tensors still obey the proper coordinate transformations, that's the defining property of any tensor. (With non-uniform tensor fields, covariant derivatives also pick up a correction, but that's a separate thing.)

TensorFlow "tensor"(and most other use of "tensor" in programmer jargon) is not a tensor at all, it's just a multidimensional array.

What are those other free providers?

Gtk isn't tied to C++ or Java in any way. While Qt and wxWidgets are written in C++, they aren't heavily tied to C++ either. For all these toolkits, bindings for many languages exist.

No, Typora is an Electron application, occupying more than 200MBs on disk (and similar amount of RAM upon start with no documents opened). See this announcement for example: https://support.typora.io/What%27s-New-0.9.66/

That's quite a common feature in Markdown editors: retext, apostrophe, ghostwriter, zettlr, notable, etc all support latex for equations.

That's quite a common feature in Markdown editors: retext, apostrophe, ghostwriter, notable, etc all support latex for equations.