Programming

The Cooley-Tukey fast Fourier transform can compute discrete Fourier transforms efficiently for signals of highly-composite length, such as powers of 2. However, to compute signal lengths with large prime factors, an algorithm such as Bluestein's is needed to prevent the algorithm from degenerating to quadratic complexity.

Thanks to Bluestein's algorithm, FFTs of prime-length input sequences are "only" ~4-6x slower than nearby powers of 2. The clunkiness of Bluestein's makes fast Fourier transforms interesting: the steps to complete the algorithm is not a monotonic function of the problem size, shooting up and down depending on the factors of the input length.

Interestingly, I found that almost no signal processing knowledge is required to understand and derive Bluestein's algorithm; anyone with general computing knowledge can follow along and should be able to implement Bluestein's algorithm after reading this post.

Original Reddit discussion: https://www.reddit.com/r/programming/comments/1t20rdz/unsigned_sizes_a_five_year_mistake/

Original Reddit discussion: https://www.reddit.com/r/programming/comments/1t3712i/the_peril_of_laziness_lost/

Hey there,

A few months ago we open sourced Voiden, an offline API client we originally built to replace Postman internally.

Voiden now has around 11k installs and growing every day. ❤️

Core principles we built it on:

• free and local-first
• file-based, all plain executable markdown
• composable through blocks
• collaboration in Git, where devs are working already

The main thing is that in Voiden, API requests are not (static) forms. They are built from blocks (endpoint, auth, params, body) that can be used, reused, replaced and version in Git, just like code. And all that in plain executable text.

Our inspiration:

Our inspiration was curl, and how simple it is, and obsidian, because of how powerful it can be.

Who this is for:

Developers, QA, Technical Writers working and collaborating on APIs.

Progress:

Since open sourcing, almost everything that we shipped came from actual users, feedback and contributions that pushed the tool in a few interesting directions. You can check our change-log here: https://voiden.md/changelog

A few highlights:

• Composable API workflows: Voiden lets you build reusable .void files that can be combined into flows, run multiple requests in sequence, and use real scripting (JS/Python/Shell) before and after requests.
• Added a “skills” layer so tools like Claude/Codex can operate directly on .void files and request blocks.
• We added an SDK for community plugins.
• & more...

Feedback:

This project is now mostly shaped and driven by community ideas and contributions. Welcome to join and help us make this even more awesome.

There is no account setup, its free and totally offline.

GitHub: https://github.com/VoidenHQ/voiden

Download: https://voiden.md/download

The maker of Ghostty and Hashicorp is finally leaving Github.

If this isn't the right community for this post, let me know and I'll move it somewhere else.

I'm working my way through nandgame, and I'm stuck on the "call" macro in the function calls section of the stack machine unit. These are the instructions:

I was stuck on it for a while, so I looked up the solution and am going off the one given here (it's the only one I could find).

So far, I haven't gotten it to work. At first, it was giving me syntax errors because the labels weren't defined, so I replaced A = [LABEL] with label [LABEL] followed by A = [CONST], according to the specified calling convention. It also gave me a similar syntax error for TEMP_ADDR, which is never specified in the instructions, so I assigned it 0x7f00. So here is what I end up with (all in Assembly):

(note: the stack pointer, SP, is defined by a shared constant SP = 0)

Test code:

init.stack
call functionName 0
stop

function FunctionName 0
push.value x42
return

Macro: call

# Assembler code
## Push the current ARGS and LOCALS on the stack
push.static ARGS
push.static LOCALS

## Push the return address.
push.value after

## Set ARGS to point to the start of the arguments
A = SP
D = *A
A = argumentCount
D = D - A
A = 3
D = D - A
label ARGS
A = 1
*A = D

## Jump to functionName.
goto functionName

## Set return address:
label after

## Restore ARGS and LOCALS from the stack
A = ARGS
D = *A
label TEMP_ADDR
A = 0x7f00
*A = D
pop.D
label LOCALS
A = 2
*A = D
pop.D
A = ARGS
*A = D

## Push RETVAL.
label RETVAL
A = 6
D = *A
push.D

Macro: function

# Assembler code
## Define a label functionName
label functionName

## Set LOCALS to the current SP
A = SP
D = *A
label LOCALS
A = 2
*A = D

## Advance SP by localsCount
A = localsCount
D = A
A = SP
D = D + *A
*A = D

Macro: return

# Assembler Code
## Pop the top value into RETVAL
pop.D
label RETVAL
A = 6
*A = D

## Set SP to LOCALS
label LOCALS
A = 2
D = *A
A = SP
*A = D

# Pop the return address and jump to it
pop.D
A = D
JMP

Note: functionName, argumentsCount, and localsCount are all listed as placeholders above the relevant macro, but it doesn't describe how to define these. I'm guessing that comes in a later unit. The code block for the call macro gives me a red bar for each line with a placeholder, but this doesn't happen for the function macro which also includes placeholders. In any case, this doesn't seem to get in the way of the program as it still runs smoothly.

So as it is, when I run it, everything seems to work as intended. This is the result when it reaches the stop macro (infinite loop):

Which looks like it's doing everything it's supposed to do. But when I click "Check solution", this is what it says:

("Expected SP (RAM address 0) to be hex 101. (Was 104)")

Which is strange, because in the computer section you can clearly see that the SP content is hex 0101. So I don't know what's going wrong.

I stepped through the program tick by tick, and the only place SP ever reaches 104 is after the function macro, when it runs push.value x42, after which it runs the return macro which begins with pop.D, reducing SP back to 103.

Could it be the evaluator is assessing the value of SP at the end of the code block, instead of where it runs the stop macro? So perhaps I could try replacing stop with a jump to the end, followed by stop... Now that I think of that, I think it might work. I'm still going to post this though, because I already went through all the trouble. And in case it doesn't work, if anyone else has any ideas please share them!

I can expand the rest of the macros if need be, but they already passed the evaluation so they're all working according to specs.

Thanks in advance!

Edit:

I thought for sure that would work. I changed the test code block to this:

init.stack
call functionName 0
A = end
JMP

function FunctionName 0
push.value x42
return
label end
stop

The program runs exactly as it's supposed to, except now the stop loop is at the end of the code. The computer output still looks the same, except now the program counter loops between 60 and 61 at the end (as expected). But the evaluator is still giving me the same error! I'm stumped...

Edit 2: added annotations to code blocks to make it easier to read

I have been applying via linkedin, company portal which show up on google search but somehow nothing is working out, cold dm, emails almost all eventually ending in radio silence. Not asking for some shortcut just that it all isn't making sense.