Hacker Newsnew | past | comments | ask | show | jobs | submit | xmmrm's commentslogin

Surprisingly [sincosf fusion] only happened with -Ofast and not with -O3.

As noted, -Ofast turns on -ffast-math which turns on -funsafe-math-optimizations which "enables optimizations that allow arbitrary reassociations and transformations with no accuracy guarantees."[0] In this case, sincosf by itself is probably more accurate.

[0] https://gcc.gnu.org/wiki/FloatingPointMath


>Why is this being posted now?

https://news.ycombinator.com/item?id=23220544


>completely removing the need for tests

That would be formal verification.


Not really. You still need tests to check whether your application is actually achieving its targets in real-world usage, including feature completeness, usability, performance; and how all of these are impacted by the environment (e.g. network issues in a distributed application).

Formal verification only tells you that the application matches its spec, given a set of assumptions. Only testing can tell you whether the spec matches the business case, and whether the spec assumptions hold.

Paraphrasing Knuth, code that has only been proven correct but not actually tested should always be approached with caution.

Edit: Knuth, not Dijkstra


Theoretically, formal verification can only tell you as much as can be encoded in a formal spec@.The problem is that no such kind of specs are known to exist (yet, if ever). As a thought experiment, if the informal specs written in English/Chinese or trapped in our head were as incomplete as a formal spec, we wouldn’t even be able to reason about what to test in the first place.

@ Then there is the limitation of verification tech of course.


When I was working with CompCert, I had no problems producing a formally verified compiler that miscompiled its (meager) test suite. Tests are necessary for "formally verified" systems! You might mess up parts of the specs or the model you are verifying against. You can only catch these problems through testing.


Which from what I’ve seen is way harder and way less accessible than testing.

And one of the things I say to anxious coworkers who are struggling with testing is that it’s a lot harder than you think.



For the time being, Firefox and Webkit are the only serious options for MathML.


Have you seen Curve9767 [0] ? Short-Weierstrass, prime-order, but the implementation does not use the complete formulas. Competitive performance, on the ARM Cortex-M0+ at least.

[0] https://github.com/pornin/curve9767


By the way, what’s the status of ristretto255? The latest version of the internet-draft [0] expired a while ago.

[0] https://datatracker.ietf.org/doc/draft-hdevalence-cfrg-ristr...


From what I can tell, they were trying to get it adopted as RFC, but then a couple more things popped up on the CFRG, so they're planning a new version[1]. It's been adopted by the CFRG officially[2]. I haven't seen any sign of when the next version may be out (which will be draft-irtf-cfrg-ristretto-00[3]), however.

I kind of hope they'll also add ristretto448 since RFC 7748 and 8032 include X448/Ed448, so that the draft has feature parity (and covers the h = 4 case properly).

[1] https://mailarchive.ietf.org/arch/msg/cfrg/3RRpX9hME5ErtAzCo...

[2] https://mailarchive.ietf.org/arch/msg/cfrg/wd8pprUfJoNhvEQE0...

[3] https://mailarchive.ietf.org/arch/msg/cfrg/pT2ML68BapPAcUiSk...


We've just finished our own updates to the draft, and are currently getting some feedback on it off-list before we publish the next version.


Yeah, they should drop bleach from that list. It degrades the shield and it might just do more harm than good.


The markup of the page has the following:

<meta name="robots" content="NOINDEX, FOLLOW" />

So the page was made available for the intended customers only, healthcare workers who likely know how to properly use bleach to clean it. This page won't be indexed by search engines.

Ironically, because it was posted on HN, it will appear, but as a link inside of an HN story.


There’s good news on that front: https://mathml-refresh.github.io/mathml-core/


For comparison, here‘s a sane interface: https://fuchsia.dev/fuchsia-src/reference/syscalls/cprng_dra...


How is this different from read(open("/dev/random", O_RDONLY), buffer, sizeof(buffer))?


- It won't fail if there's no /dev/random device mounted (e.g. in chroot)

- It won't fail if there are no file descriptors available

- No error handling needed: the call always succeeds and random bytes are always returned


So like the standard arc4random_buf(3) which everybody has except for Linux.

Don't worry the name is historic it does not us the arc4 cipher any longer, at least on OpenBSD. They switched to chacha20 as stream cipher.


The interface is the same, but arc4random_buf is a user-space CSPRNG.

The analog of zx_cprng_draw is getentropy(2): http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/... except zx_cprng_draw kills the process, while getentropy returns an error.


Linux has had getrandom(2) for quite a few years, and there are glibc wrappers which use it.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: