Wouldn't it make more sense to run/emulate JVM bytecode on WASM instead of compiling Java to WASM? It seems like that'd be a much easier task.
From a high level WASM and JVM byte code seems incredibly similar (though I'm sure the containerizing and IO are radically different). I never really understood why WASM wasn't some JVM subset/extension.
Not an expert at all in this, so genuinely curious to hear from someone who understands this space well
From my understanding, this works for C# but is an ill-fit for Java. Java has simple bytecode with a powerful runtime to ensure all kinds of guarantees. C# focuses on compile-time checks with a more complex bytecode representation.
So instead you got TeaVM which is essentially a whole JVM in WASM.
On thing that is often overlooked but should be emphasized is that the considered frequencies are fixed values while the phase shifts are continuous values. This creates tons of downstream problems
If your underlying signal is at frequency that is not a harmonic of the sampling length, then you get "ringing" and it's completely unclear how to deal with it (something something Bessel functions)
Actually using DFTs is a nightmare ..
- If I have several dominant frequencies (not multiples of the sampling rate) and I want to know them precisely, it's unclear how I can do that with an FFT
- If I know the frequency a priori and just want to know the phase shift.. also unclear
- If I have missing values.. how do i fill the gaps to distort the resulting spectrum as little as possible?
- If I have samples that are not equally spaced, how am I supposed to deal with that?
- If my measurements have errors, how do I propagate errors through the FFT to my results?
So outside of audio where you control the fixed sample rate and the frequencies are all much lower than the sample rate... it's really hard to use. I tried to use it for a research project and while the results looked cool.. I just wasn't able to backup my math in a convincing way (though it's been a few years so I should try again with ChatGPT's hand-holding)
I recommend people poke around this webpage to get a taste of what a complicated scary monster you're dealing with
FFT/DFT is not precise if you do not have the exact harmonic in you signal. If you are also (or only) interested in phases you might use a maximum likelihood estimator (which brings other problems though).
And as the previous answer said: compressed sensing (or compressive sensing) can help as well for some non-standard cases.
A while back I looked at matching pursuit. At first it seemed very complicated, but after staring at it a bit realized it's simple.
- Start with a list of basis functions and your signal.
- Go through the list and find the basis function that best correlates with the signal. This gives you a basis function and a coefficient.
- Subtract out the basis function (scaled by the coefficient) from your signal, and then repeat with this new residual signal.
The Fourier transform is similar using sine wave basis functions.
The key that makes this work in situations where the Nyquist theorem says we don't have a high enough sampling rate is ensuring our sampling (possibly random) is un-correlated with the basis functions and our basis functions are good approximations for the signal. That lowers the likelihood that our basis functions correlating well with our samples is by chance and raises likelihood it correlates well with the actual signal.
You can use single bin DFTs and not FFTs? Basically use precomputed twiddles for a specific frequency. FFT is only fast because it reuses operation across multiple frequencies, but if you need a specific frequency instead of the whole spectrum, then a single-bin DFT makese sense, right?
Somewhat related field, compressive sensing, attempts to answer some of those questions (particularly missing data, uneven sampling and errors) using a L1 minimisation technique.
I never understood why they do not track the OpenJDK versions. I don't work on Android apps.. but it seems mildly insane to basically have a weird almost-Java where you aren't even sure if you can use a given Java lib.
> I never understood why they do not track the OpenJDK versions. I don't work on Android apps.. but it seems mildly insane to basically have a weird almost-Java where you aren't even sure if you can use a given Java lib.
NIH syndrome
> (and not a Dart chat app.. but something actually performant that uses the hardware to the full extent)
I used to work on Android, quit two years ago and have used Flutter since, it's a breath of fresh air. It does use the hardware to the full extent, imo it's significantly more performant: it does an end-around all the ossified Android nonsense.
Hmm, so if you wanted to make an AR app, or some audio processing app, would you do that in Flutter? All the projects I have in mind involve using the camera/microphone/gps etc. Looking at Dart sample projects it just seemed to be quite different from what they're aiming at
My caffeinated instinct is to say basically "yes I'd do anything in Flutter", I honestly would rather stop coding than go back to anything I've done before (ObjC/Swift/Java/Kotlin with side journeys in C++). It boggles my mind how much of a different job dev is with true hot reload.
More carefully, and dealing with what you're indicating more directly:
There's stuff that we just need every millisecond of performance from.
Generally, Dart's great, I don't notice any difference between iOS / Android standard UI platforms.
But...for example, Flutter's image decoding is actually using "native" code behind the scenes, i.e. calling into C or OS-level APIs or browser APIs as needed on each platform. And there's a Flutter package called "image" that's Dart-native but I abhor because I know it's going to be higher latency than going thru lower-level code. (now I'm wondering how Java does this...I wonder if its JNI...)
Let's do a scenario: I've been contracted to build a bus route app for the local gov't. They want an AR feature. What happens if I choose to build on Flutter, build out the basic features, then get to the AR, and I'm getting 5 fps?"
This might feel convoluted at first, it did to me, but really, all that's going on is: when things are slow, we write a Dart interface, then for each platform where we want to use native code, provide impls of that interface in native.
Yeah, I'm currently developing a Flutter app and also using flutter_rust_bridge to separate the business logic and I can hardly believe how enjoyable it is.
Other than the initial project setup which is a me and Nix flakes problem it all comes together pretty smoothly.
I went down a rabbit hole a few weeks back to discover this. I was so upset with so many wrong explanations including Neil de Grasse Tyson saying we're moving into the bulges.
it's very magical though discovering the beauty of it.
What really gets me is the "Map of the strength of the 12-hr lunar tide" in the Layer 4 section of the article posted, which I haven't seen discussed.
All the rest is swept away, and you have stretches of coastline with tides over one meter, and others with nearly zero, just because of landmass distribution ...
If you moved Miami Beach to the French Atlantic coast, things would get interesting.
You can do that and that's one of the big appeals. You can serve bost JXL and JPEG from the same source and you8 can actually serve downscaled versions of the JXL image from the original bytestream.
Also OP did say "transcode on the fly" to serve JPEG, not actually storing as JPEG.
I think GP only wants to convert images back for users with legacy browsers, not for everyone. So converting 100% of the images needs more compute money than the amount of storage money it saves, but only converting ~1% of the images on-the-fly would be worth it financially.
i feel hiccup indexed based magic is a common design pattern you see in early Clojure and its less common now (id say hiccup is the exception that lives on)
What's worth emphasizing is that you're not marrying in to an ecosystem of libs. There are a lot of separate pieces that you can typically use separately. I do climate data work without most of Scicloj's tools, but I do use tech.ml.dataset extensively
It doesn't require any Java but the docs do at times sort of assume you understand the JVM to some extent - which was a bit frustrating when first learning the language. It'll use terms like "classpath" without explaining what that is. However nowadays with LLMs these are insignificant speedbumps.
If you want to use Java you also don't really need to know Java beyond "you create instances of classes and call methods on them". I really don't want to learn a dinosaur like Java, but having access to the universe of Java libs has saved me many times. It's super fun and nice to use and poke around mature Java libs interactively with a REPL :)
All that said I'd have no idea how to write even a helloworld in Java
PS: Agreed on Emacs. I love Emacs.. but it's for turbo nerds. Having to learn Emacs and Clojure in parallel was a crazy barrier. (and no, Emacs is not as easy people make it out to be)
the most basic solution that will work for every filesystem and every type of block device without even mounting anything, but won't actually check much except device-level checksums:
sudo pv -X /dev/sda
or even just:
sudo cat /dev/sda >/dev/null
and it's pretty inefficient if the device doesn't actually have much data, because it also reads (and discards) empty space.
for copy-on-write filesystems that store checksums along with the data, you can request proper integrity checks and also get the nicely formatted report about how well that went.
for btrfs:
sudo btrfs scrub start -B /
or zfs:
sudo zpool scrub -a -w
for classic (non-copy-on-write) filesystems that mostly consist of empty space I sometimes do this:
sudo tar -cf - / | cat >/dev/null
the `cat` and redirection to /dev/null is necessary because GNU tar contains an optimization that doesn't actually read anything when it detects /dev/null as the target.
Just as a note, and I checked that it's not the case with the GNU coreutils: on some systems, cp (and maybe cat) would mmap() the source file. When the output is the devnull driver, no read occurs because of course its write function does nothing... So, using a pipe (or dd) maybe a good idea in all cases (I did not check the current BSDs).
If you have a program that looks at CCTV footage and IDs animals that go by.. is a human supposed to validate every single output? How about if it's thousands of hours of footage?
I think parent comment is right. It's just a platitude for administrators to cover their backs and it doesn't hold to actual usecases
I don't see it so bleakly. Using your analogy, it would simply mean that if the program underperforms compared to humans and starts making a large amount of errors, the human who set up the pipeline will be held accountable. If the program is responsible for a critical task (ie the animal will be shot depending on the classification) then yes, a human should validate every output or be held accountable in case of a mistake.
I take an interest in plane crashes and human factors in digital systems. We understand that there's a very human aspect of complacency that is often read about in reports of true disasters, well after that complacency has crept deep into an organization.
When you put something on autopilot, you also massively accelerate your process of becoming complacent about it -- which is normal, it is the process of building trust.
When that trust is earned but not deserved, problems develop. Often the system affected by complacency drifts. Nobody is looking closely enough to notice the problems until they become proto-disasters. When the human finally is put back in control, it may be to discover that the equilibrium of the system is approaching catastrophe too rapidly for humans to catch up on the situation and intercede appropriately. It is for this reason that many aircraft accidents occur in the seconds and minutes following an autopilot cutoff. Similarly, every Tesla that ever slammed into the back of an ambulance on the back of the road was a) driven by an AI, b) that the driver had learned to trust, and c) the driver - though theoretically responsible - had become complacent.
Theoretical? I don't see any reason that complacency is fine in science. If it's a high school science project and you don't actually care at all about the results, sure.
The problem is that the original statement is too black and white. We make tradeoffs based on costs and feasibility
"if the program underperforms compared to humans and starts making a large amount of errors, the human who set up the pipeline will be held accountable"
Like.. compared to one human? Or an army of a thousand humans tracking animals? There is no nuance at all. It's just unreasonable to make a blanket statement that humans always have to be accountable.
"If the program is responsible for a critical task .."
See how your statement has some nuance? and recognizes that some situations require more accountability and validation that others?
If some dogs chew up an important component, the CERN dog-catcher won't avoid responsibility just by saying "Well, the computer said there weren't any dogs inside the fence, so I believed it."
Instead, they should be taking proactive steps: testing and evaluating the AI, adding manual patrols, etc.
From a high level WASM and JVM byte code seems incredibly similar (though I'm sure the containerizing and IO are radically different). I never really understood why WASM wasn't some JVM subset/extension.
Not an expert at all in this, so genuinely curious to hear from someone who understands this space well
reply