Add WASM compile target about inari HOT 14 CLOSED

@KloudKoder, you are of course welcome to point them to this library in order to motivate the introduction of rounding mode operations. And let us know if they adopt them! 😁

from inari.

I've been reading the comments in the mentioned discussion. As I understand it, they are not interested solely in someone eventually using the directed rounding modes but, understandably, they want to collaborate with people who will use the feature to assert its correctness and efficiency, @unageek Are you willing to implement the port to WASM while they develop the feature? If so, I can help testing it on code I wrote. Note that there is also already a (not so efficient and stripped down) port of Inari to WASM. Maybe we should involve its author?

from inari.

Are you willing to implement the port to WASM while they develop the feature?

Once instructions are available in core::arch::wasm32, yes!

Note that there is also already a (not so efficient and stripped down) port of Inari to WASM.

Well, I'm concerned about the crate since it is not a valid implementation of IA.

from inari.

@Chris00 @unageek Guys, you really ought to be paying attention to

WebAssembly/design#1456

Decisions are being made which will affect the implementation of Inari on WASM. Please chime in if you don't like something about it.

from inari.

I am not sure what you are suggesting. It is not possible to port the crate to WASM, since, as you said, non-default rounding modes are not supported at the moment.

from inari.

@unageek @Chris00 Thanks both of you for replying. Let me see if I can offer a better explanation of what's at stake here.

First of all, it's correct that under Rust, even unsafe Rust, you can't compile interval code to WASM because you need all 4 basic rounding modes (not just nearest-or-even). The WASM proposal is to add instructions like "multiply 32-bit floats and round toward negative infinity" or "subtract 64-bit floats and chop toward zero". The only way to do this in WASM at the moment is via incredibly slow and complicated floating-point emulation.

If this proposal happens, we'll suddenly have cross-platform analog security for the Web. Right now, we have cross-platform code for the Web that's not analog-secure (that being normal WASM floating-point). We also have analog-secure code that's not cross-platform (that being hardware-customized interval libraries).

By all reasonable standards of engineering safety, using intervals in 2022 should be as easy as using floating-point in 1982. But it's not because there's this chicken-and-egg between the compiler writers (who don't want to add interval support because it's hardly ever used) and the app programmers (who can't use interval support unless they're willing to go hardware-specific, which is usually a nonstarter). Fingers point in both directions, and nothing gets done. After so many wasted years, it's time to actually solve the problem.

And so, a year ago, I proposed all this to the WASM community. The compressed version of what happened is this: They said "OK, we can see that intervals are useful. And we're also convinced that emulation is nonperformant. But we don't want to add these instructions unless you can summon somebody who can show that they have an actual interest in running interval arithmetic on the Web, or creating some sort of library for that purpose."

If you would like to see your library running in WASM, and be the very first to do so and start claiming market share, then you should care about this. But if it really doesn't matter to you, then OK, it doesn't, and I'll move on.

So what if you actually care? I can't just point at your project and say "Look at them! They said they care!" I would need one of you to go over to the WASM proposal page here on Github and briefly explain why you have an interest in seeing this happen. They'd probably ask you a few questions about what your library does and why someone might want to use it on the Web. I have no business speaking for either them, or you. My business is to make cross-platform analog security happen ASAP because the world would be a lot better if it existed.

I'm listening if you have questions.

from inari.

This shouldn't be a difficult decision. Let's drive this to a close one way or the other. There's no reason to keep this issue open in the hopes that someone else will fix the problem. If I can clear up some confusion or point you to more information, let me know.

from inari.

Personally, I'm a bit torn out between “it would be nice to have WASM support” as it would allow to make interactive computer assisted proofs available on the web (interesting for colleagues and students) and the fact that I'm unlikely to write such an app in the near future (due to time constraints).

from inari.

@Chris00 I understand your point, but the main task at hand doesn't necessitate you actually writing WASM code anytime soon. (Now that I think about it, the title of this issue should probably be more about preparation for a WASM port than the actual port itself. Sorry if that was confusing.) Under the current circumstances, you can't even contemplate doing a port, performantly. If the instructions become available, you will be able to tweak your existing unsafe Rust code (unsafe because it's necessarily hardware dependent) with the new WASM instructions in order to make it compile for the Web. Then you can start attracting developers (for example for the proof application you mentioned). But you don't need to do that right now. This is just about making it possible.

Eventually, one would hope that Rust would just create a native interval type (which they can't presently do for exactly this same reason), but you don't need to care about that because you could offer interval support to Rust developers as soon as your tweaked library gets done.

I'd probably use it myself. It's always amazed me how one could create a brand new language (like Rust or Julia) in the 21st century and still not consider analog security important enough to nativize. Using intervals should be trivial. Probably they just didn't think of it. Oops.

from inari.

Let me close the issue. I am willing to port the crate to WASM once relevant instructions are available.

from inari.

Great. @KloudKoder I can then chime in to assert there are people with interest in having directed rounding in WASM.

from inari.

@KloudKoder I suppose you do not mind that I'm saying I come to the issue because you contacted us?

from inari.

@Chris00 @unageek Of course, all honest discussion is legitimate. There's nothing wrong with explaining how you learned of the WASM proposal.

I also think your idea about enabling automated proof checking is just brilliant. As it stands today, you literally cannot verify that f(x) is equivalent to g(x) in WASM, short of full-blown symbolic proof capabilities that aren't really mature yet. With intervals, you can at least show via many sample points that they appear to be equivalent. You can't do even that much with floating-point, however, because it's impossible to show that all the higher-order terms are at least consistent to within some tolerance. Anyways, this is worth bringing up as well.

And now, without further ado, I would like to invite both of you to comment with complete freedom at the relevant issue below. If you have ideas on how best to implement the proposal, that would be welcome discussion as well.

WebAssembly/design#1456

from inari.

@Chris00 @unageek You still there? If so, where are we with this? Perhaps you're not getting notifications because this is a closed issue.

from inari.