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

S-expression is a standard representation for syntax-free semantics. For example, PLT Redex [1] is a DSL for programming language semantics and built on top of Racket which uses S-expressions.

[1] https://redex.racket-lang.org/


Do you know if Redex could be a tool that would be useful in my situation?

Claude suggests it, but I need to learn a lot of Redex to understand how to apply it.

I have a general understanding of what operational semantics is. Or maybe, are there any Redex implementations for common programming languages? \lambda_v is a bit too abstract.


Even Ruby `parser` gem uses S-expressions in their documentation: https://github.com/whitequark/parser/blob/master/doc/AST_FOR...

A common misunderstanding AFAIK. It is true that Claude, not being a person, can't be assigned a copyright by itself, but a person that interacts with Claude generally can. The famous monkey selfie case [1] was different mainly because the human "photographer" had absolutely no role in the creation of work. Most LLM uses don't fall into such ambiguity.

[1] https://en.wikipedia.org/wiki/Monkey_selfie_copyright_disput...


I've heard and read it from various sources already that output isn't copyrightable, and hinted as such recently in a comment. Now I've went to look up some sources.

> Copyright does not extend to purely AI-generated material, or material where there is insufficient human control over the expressive elements.

> Whether human contributions to AI-generated outputs are sufficient to constitute authorship must be analyzed on a case-by-case basis.

PDF https://www.copyright.gov/ai/Copyright-and-Artificial-Intell...


That does make sense, because a half of all available fp numbers are less than 1 in their magnitude. In particular there should be a plenty of numbers x such that |x| << 1 so x + 1 ~= 1; in fact, the proportion should be just shy of 50%.

That is indeed one of the problems with IEEE floats. There are only 10^80 atoms in the universe, and a Planck length is 1^-60th of the radius of the universe. But 64-bit floats have an absurd range of over 10^±300! Worse than that, notice that there are as many bit patterns in the never-used range between 10^300 and 10^301 as there are in the super-important range between 1 and 10! Super wasteful. Not to mention the quadrillions of values reserved to represent "NaN"...

This is one of the problems that alternative formats such as the Posit aim to solve. It's quite interesting: I've got an implementation in rust here if you want to play with it https://github.com/andrepd/posit-rust


Note that the logarithmic distribution of float density is also key to certain kinds of efficient hardware float implementations, because it means you can use the fixed mantissa bits alone as table indices. Unums have proven difficult to build efficient HW implementations for.

IEEE floats have a few warts like any other 1980s standard, but they're a fantastic design.


> Unums have proven difficult to build efficient HW implementations for

Valid point, but not quite true anymore. It comes down basically to the latency of count_leading_ones/zeros for decoding the regime, on which everything else depends. But work has been done in the past ~2ish years and we can have posit units with lower latency than FP units of the same width! https://arxiv.org/abs/2603.01615

> IEEE floats have a few warts like any other 1980s standard, but they're a fantastic design.

Hmm I don't know if I would call it a fantastic design x) The "standard" is less a standard than a rough formalisation of a specific FPU design from back in the 1980s, and that design was in turn not really the product of a forward thinking visionary but something to fit the technical and business constraints of that specific piece of hardware.

It has more than a few warts and we can probably do much better nowadays. That's not really a diss on IEEE floats or their designers, it's just a matter of fact (which honestly applies to very many things which are 40 years old, let alone those designed under the constraints of IEEE754).


I'm sure you're much more knowledgeable about this than I am, but that's kind of my point. A month old preprint is the first thing to compare to implementations of a mildly evolved, warty old standard from 40 years ago. I consider that fantastic.

Thanks for the paper though. Looking forward to reading it more closely when I have time.


Absolutely! IEEE floats are ubiquitous in software and hardware. I bet good money they will still be around 40 more years into the future :) and any alternative has to fight their ubiquity.

Better alternatives have been proposed for a long time though. Posits are very nice, and even they are almost 10 years old now :p


But I guess using the density distribution of floating points is rarely useful in a problem. Your actual distribution will almost surely be way different. Imo, the tool presented here should provide a way to manually provide a custom density function (with some common presets like uniform and normal distributions).

Author here! Yes, the float distribution isn't what you want in practice, but distribution selector isn't really the right thing either, because a low probability bad result can still be pretty bad! Hence the range selector; the float distribution is good at picking extreme values that trigger FP error.

We usually recommend looking for 90%+ accuracy or carefully examining the accuracy plot


Not really. 1+x/2, however, would be a good approximation to sqrt(1+x) for small (in absolute value) x.

How about:

(* Mathematica Notation, Assume x>0 ) If[ x < 10^(-10), 1+ x/2, ( order x^2 error ) If[ x> 10^10, Sqrt[x], ( order 1/Sqrt[x] error ) (else) Sqrt[x +1] ] ] ( I guess the If statements take too much time. *)


Or so one says. (Not necessarily saying that it was a bad decision.)

What evidence of malice supports your claims here?

(Evidence-free conspiracy theories are generally unwelcome at HN.)


It is not that trivial, because there are tons of existing JPEG files and lossy recompression costs quality. (PNG does get replaced primarily because lossless WebP is kinda a superset of what PNG internally does.)


On your last point: I find it super annoying when both lossy and lossless codecs have the same name, and, more importantly, file extension. I get it that internally they are "almost the same thing", just with one extra step of discarding low-impact values, but when I see a PNG/FLAC file I know, that if the file was handled properly and wasn't produced by Windows clipboard or something, it is supposed to represent exactly the original data. When I see JPEG/MP3, I know that whatever it went through, it is not the original data for sure. When I see WEBP, I assume it's lossy, because it's just how it's used, and I cannot just convert all my PNG files to a newer format, because after that I won't be able to tell (easily) which is the original and which is not.


Ah, in that case you would be more annoyed to learn that lossy WebP and lossless WebP are completely distinct. They only share the container format and their type codes are different.


Awesome. It would be interesting to learn why they even thought it is a good idea. Content-agnostic containers may make sense for video, but for the vast majority of use-cases a "video" is in fact a complex bundle of (several) video, audio, metadata tracks, so the "container" does much heavier lifting than specifying codec details and some metadata.


Why would they want different container formats? No point in having multiple different metadata specs.


The PNG and FLAC format doesn't doesn't tell you that. While both specify lossless encoring algorithms (assuming data is already quantized to a supported bit depth), that doesn't prevent encoders from adding additional lossy preprocessing steps that improve compression - and there are several such encoders for PNG.


Just re-encode it to Jpeg XL without loss of quality, and use less space.


This is probably the neatest feature of JPEG XL. Although, creating a thumbnail by literally truncating the image bytestream is a close second in 'neat' factor.


They could buy a dedicated IPv4 address, but that address still has to be tunneled through [EDIT:] IPv6 networks if that dev has no access to [EDIT:] IPv4 networks. Thus DX still suffers. [ADDENDUM: I mistakenly swapped "IPv4" and "IPv6" there. See comments.]


I'm not sure I understand your point; if exe.dev operates a dedicated IP solely so a specific mythical IPv6-less developer can connect to a specific server, then there's no tunnelling involved at all.


Oops, I think I mixed up two sentences in the middle. A fixed comment is available. But I also probably misinterpreted what you were saying:

> they could pay a small extra for a dedicated IPv4 address.

Did you mean that the dedicated IPv4 address to connect via SSH? Then my objection doesn't apply.


(1991). This article is also available in HTML: https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.h...


> We've had machine translation for a while and I don't think anybody particularly thinks of it as a bad thing?

Not all, but some machine translators can be comically (if not horrifically) bad sometimes. Search Twitter-become-X for examples. Native writers can't pick a working machine translator unless they are explicitly allowed to do so themselves.


> So was mine when I started arguing with strangers on the internet. It's better now.

That takes (much) time, though. I took about a decade to be comfortable about that.


Others will understand, but won't regard that as worthy. That's a difference.


I don't get where this class/status/worthiness ties into HN comments ?

I get decent feedback most of the time, and I read interesting stuff, it's the easiest way I found to stay in the loop in our industry. What are you guys commenting for ?


Worthy to continue the discourse. Everyone claims that one doesn't discriminate a badly written English text from a good one, but only because they haven't actually encountered such text after all. There surely exists a threshold for "badness" and an outright ban of LLMs means that you are not even given a chance to lower that badness. That is a discrimination, you like or not.


Nobody will notice if you use LLMs as long as it doesn’t sound like an LLM. But sounding like an LLM is as “bad” as badly written English, so you’ll get looked down upon either way in that case.

It’s not without reason that bad English is taken as a signifier, and for similar reasons LLM-speak is taken as a signifier as well.


And that’s their problem.


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

Search: