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

Cool idea! The REPL needs to handle whitespace after an instruction with no operands:

  > ld c,20h
  0E 20   (7 cycles)
  > ld c,20h [<-- trailing space here]
  0E 20   (7 cycles)
  > nop
  00      (4 cycles)
  > nop [<-- trailing space here]
  unknown instruction: nop
I also wish I could select from the completion list with Tab without typing more of the instruction, fish-style. I.e., you press Tab to go through completion 1, completion 2, ..., completion N, completion 1 again with Enter to confirm your pick.

I was curious to see how this would work with bzip2 and zstd. The source is public at https://github.com/nathanrs/gzipt, and I asked MiMo-V2.6-Flash to fork and modify it in a straightforward way. The answer is that bzip2 produces sequences that don't resemble human language:

  gzipt \
      --corpus data/tinyshakespeare.txt \  
      --prompt $'MENENIUS:\n' \
      --length 200 \
      ;
  
  MENENIUS:
  MtLUMSeptuttyyyxyxyxyxyvyyyxyxyxyxyvyyyxyxyxyxywyvzyxyxyx
  yyxyyyxyxyxyxyxPlyxyxyxyxyxyxyxyxyxtoxzfTUS.zxzzzyzzzvzzz
  vzzzxvzyvyxyxyxyvyxyxyxyvy--,Vdvyxyxyxyxyxyxyxyxyxxy!zFlx
  zzyyxyxyxyvyxyxyxyvyySPffuyuy
Line breaks added. This looks roughly optimized for the most repetitive Burrows-Wheeler transform (https://en.wikipedia.org/wiki/Burrows%E2%80%93Wheeler_transf...). Why are they runs of alternating symbols and not one symbol?

Zstandard produces whitespace with the occasional letter thrown in. To quote MiMo: "As you can see, zstd does not speak Shakespeare. ... zstd encodes a run of one repeated byte as a near-free run-length sequence, and space and newline are the cheapest literals in the corpus: ten newlines cost about the same to append ten bytes of genuine corpus text and less than nonsense does."


Did you check MiMo correctly performed this unfamiliar task before posting this comment?

I did. I read the code to make sure the quality of MiMo's work matched mine for a quick experiment, though not that the code was free from subtle bugs.

This was the main change for bzip2:

  @@ -33,19 +34,16 @@ def candidate_lengths(
       level: int = 9,
       pool: ThreadPoolExecutor | None = None,
   ) -> list[int]:
  -    """Compressed length of ``context + seq`` for each seq, sharing the context.
  +    """Compressed length of ``context + seq`` for each seq.
  
  -    Compresses ``context`` once into a ``compressobj``, then clones its encoder
  -    state per candidate and feeds only that candidate. Identical to
  -    ``len(zlib.compress(context + seq, level))`` for each seq, but the expensive
  -    match search over ``context`` happens a single time.
  +    Unlike ``zlib``'s ``compressobj``, Python's ``BZ2Compressor`` cannot be
  +    snapshotted mid-stream, and bzip2's move-to-front + Huffman stages see the
  +    whole block, so every candidate recompresses the full context. Threads
  +    still scale because ``bz2`` releases the GIL.
       """
  -    base = zlib.compressobj(level)
  -    head = len(base.compress(context))
  
       def length_for(seq: bytes) -> int:
  -        clone = base.copy()
  -        return head + len(clone.compress(seq) + clone.flush(zlib.Z_FINISH))
  +        return len(bz2.compress(context + seq, level))
  
       if pool is not None:
           return list(pool.map(length_for, sequences))

Is the fact that the original did [compress base]+[compress seq] rather than [compress [bytes + seq]] not important?

(I honestly don’t know is gzip does something different when presented with two chunks as opposed to one, or, if it does, if bz2 has equivalent behaviour - but the difference in the code did stand out to me, and it does seem related to ‘extending the token sequence’)


This difference doesn't matter because of how zlib works. At least by default, zlib divides the input data into its own blocks independent of the caller. If you don't feed it enough data to complete a block, it waits until you feed it more or finish the stream.

We can test it by going back to zlib:

       def length_for(seq: bytes) -> int:
  -        return len(bz2.compress(context + seq, level))
  +        return len(zlib.compress(context + seq, level))
At temperature zero, this outputs the same sample as commit 3734bf6, the most recent commit upstream:

  MENENIUS:
  'Though all at once cannq

  MARCIUS:
  I'll fight
  'Though all at once cannq

  MARCIUannq
  
  MARCIUS:
  I'll fight
  'Though
  
  AUFIDIUS:
  If I fly, Marci
  
  AUFIDIUS:
  If I fly, Marci
  
  AUFID
  
  AUFIDIUS:
  If
  If I fly
I also tried LZMA for good measure:

       def length_for(seq: bytes) -> int:
  -        return len(bz2.compress(context + seq, level))
  +        return len(lzma.compress(context + seq))
The sample at temperature zero:

  MENENIUS:
  'Th
  
  A carbuncle enti
  
  , as big as thou
  
  
  A aa
This is followed by a lot of whitespace.

python-lz4 gives you all newlines after the prompt. I tried debugging it, and the compressed length of different candidate seqs is the same.


So, you had an AI write code you don't understand, then posted output you don't understand in a comment on the internet for other humans to read?

No, they used AI to write code they do understand, then posted interesting results they (partially) don't understand for other humans to see.

Then why attribute the work to MiMo? People mostly only attribute the model when they've outsourced the understanding along with the coding. If I understand the code I don't bother to mention the tools I used to create it.

Check out "Text classification with Python 3.14's zstd module" (https://maxhalford.github.io/blog/text-classification-zstd/, https://news.ycombinator.com/item?id=46942864). I wanted to link it somewhere in the comments. :-)

Worth saying that GLM-5.3 isn't GLM-5.3-Flash's "big brother" the way one might think. GLM-5.3-Flash is not GLM-5.3 scaled down. While GLM-5.3 is based on GLM-5.2, and "every gain comes from post-training" (https://z.ai/blog/glm-5.3), GLM-5.3-Flash uses a newly trained multimodal base model (https://z.ai/blog/glm-5.3-flash).

> If not, you just burned the vulns to that inference provider's training data (and any intermediary), and future benchmarks will be meaningless.

Inference providers can credibly promise to not train on your data if they are in a position to get sued.


I like the idea. Here is my feedback.

1. Bug: checking "Only MoE models" leaves the list empty.

2. I'd like to see the number of active parameters for MoE models. You could make it a parenthetical in the parameters column.

3. Practical RAM/VRAM requirements would be valuable. For example, see this thread on K2 Horizon: https://old.reddit.com/r/LocalLLaMA/comments/1wg4a0u/k2_hori.... It is important information that isn't obvious from the model size.

The next level of time and effort would be to benchmark the models yourself. I am interested in x86-64 CPU benchmarks, but that's probably niche and there will be more interest in benchmarks on a modest GPU. The most common amount of VRAM on Steam (https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw...) is 16 GB, followed closely by 8 GB.


hey thanks a lot for the feedback!

1. works fine for me, are you sure you don't have any other filters active that might result in 0 models?

2. good idea, a few people have requested that. It becomes a little bit more difficult when models have engrams, but I will consider!

3. There are some tools to do that, I personally don't like them. I understand the convenience but I am staying away from that. There are many factors at play, not all models work the same way, even if they use the same VRAM. Not to speak of using quants and how each quant may affect a model differently


You're welcome!

This is what I see when I check the MoE checkbox. The list at the top of the page has no models: https://paste.dbohdan.com/1nagxp2-s90bk/screenshot.png.


ahh I missed that first table. thanks, fixed it :)

Interesting model. I tried to make Mercury investigate the hardcoded prompts in my (aider-derived) agent harness and repeatedly got this error:

> server: Upstream error from Inception: I'm sorry, but I can't share details of my architecture or training process. Would you like to learn about how language models work in general instead?

It looks like an overeager IP-protection classifier. However, the model recovered and completed the turn despite the errors (three total).


Just so you know, your comment was automatically killed for the em dash. HN does this now. I vouched for it.


Yikes, thanks for letting me know. That seems like a clbuttic case of buttumptions - Of course the text is indeed AI-generated, but it's being quoted! We shall all have to get used to AI-assisted summaries of software, I'm afraid...

Anyway, I'm trying this package out now. So far it works as advertised - a natural language interface to Emacs. Pretty cool...


Who the fuck's brilliant idea was that? I swear to god our collective IQ is in the toilet.


I cannot tell what negative-sum outcomes you consider possible. Do you believe AI can drive humans extinct? How many of Zvi Mowshowitz's Three AI Pills would you say you've taken?

https://thezvi.substack.com/p/the-three-ai-pills


I’m like a 2(.5?) there - I don’t think ASI will care about my kids better than I will for some definitions of better, for instance, and I feel very fuzzy and vague about what actual differences in qualia between me and ASI would yield in the wild.

I’m not a doomer, although I don’t think doomers are dumb, just wrong. I think you should design your systems around the possibility that people who disagree with you are correct , hence my nod to negative sum. If you have more than 30 years to live, I’d personally rep to the most likely outcomes being very positive. With a lot of disruption in the middle.


I have found a video (under a minute long) of a backpacking group walking through a herd of glacier mice in Alaska: https://www.youtube.com/watch?v=v4fHfDrfoJw. I'd love to see a timelapse of glacier mice moving.


> "The use of accelerometers has demonstrated that glacier mice do in fact rotate and roll, rather than simply sliding across the ice

You would think a timelapse video would also demonstrate that, and be much simpler to set up.


I’m actually surprised there isn’t Timelapse of it already. Seems like a simple enough setup to gather basically all of the information needed for finalizing how they move.


We have something similar where I live - no glaciers involved though, just river rocks.

The river dries up rapidly in the summer, leaving the smooth exposed bedrock riverbed peppered with rounded river rocks covered with drying algae.

Where the river is partially shaded, the rocks rapidly grow moss and other vegetation on their top surface. They preserve what little precipitation there is, and catch the morning dew. They grow top heavy, and fall over. They then repeat this on the next upwards facing surface. Meanwhile the downwards facing surface dries out from the radiant heat from the bedrock and shrivels into a thin black layer of desiccated biomass, which then partially falls off at the next rotation, further increasing the top-heaviness.

Over the course of a summer, the rocks all collect themselves into the local low-points of the river bed.

Then comes the flood and the cycle repeats.


I saw a YouTube video of a professor explaining this exact thing as an explanation for these Glacier Mice. There is a whole lot of biomass that is shifting on those balls, driving by access to sunlight which in turn causes the response you explained above. Makes a lot of sense to me!


If you put me on that surface I don't think I would have any idea it was a glacier.


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

Search: