u/kragensitaker

I print things on paper using a printer... what's wrong with my approach? Isn't that on paper?

If you're printing things on paper using a printer, you can just type your program in JS and then print it. There's no need to use this handwriting-optimized notation which, despite my best efforts, is still not as readable as more verbose notations.

As for your another problem, yep, it sounds like you've got problems I can't help you with.

As I said on the orange website, I've been intrigued by APL ever since I picked up a couple of discarded APL books in 1995 and read through them repeatedly, taking profuse notes. I keep hoping that someday I will learn APL well enough to be able to just jot down program fragments and be sure that they'll work, rather than giving me a rank error; the same is true of APL descendants like Numpy, although I have a lot more experience with them. I watched Roger Hui's "Tour de Force of APL in 16 Expressions", and although I understood the expressions, I don't understand how to design them. There are a bunch of notes in Dercuano about variants of APL. I've downloaded Aaron Hsu's dissertation, but I haven't read it yet.

For now, though, I can write out algorithms in what seems to me to be a straightforward fashion in paperalgo.

Some APLish things I've done include recoding T$'s 64-byte demo Klappquadrat in Numpy and this keyboard-driven structure-editing calculator with broadcasting over one-dimensional vectors

Thanks!

Or they just didn't bother about compatibility on some small niche operating system, and only worried about the worlds most popular ones.

Fuck you, you gravel-faced mudsucker.

The notation used in this article doesn't even render (missing glyphs) on a typical Linux desktop

I've been using Linux pretty much exclusively for my desktops since 2001, and whenever I had a choice since 1996. I guess my desktop must not be very "typical" ☺

while the parts the do render form some unreadable clusterfuck (letters crossed by the lines that are supposed to underline the previous line, square root sign is discontinuous, and so on).

Yeah, I do have some layout problems. Do you want to share screenshots of the parts that don't work for you? I don't know how to solve the discontinuous-square-root-symbol within the constraints of HTML, although TeX would make it feasible.

Also, the idea of having to look up the Unicode codes for the math symbols this is trying to use is beyond ridiculous.

…perhaps you missed that the title says "a paper algorithm notation". The idea is that you're supposed to use this on paper, or possibly on a whiteboard, not in Unicode. If you have a keyboard, you can just type your program in Python or JS or whatever. It says so at the very top of the document; maybe this is one of the parts that didn't render for you for some reason:

Pseudocode on paper is an important thinking tool for a lot of programmers, and on the whiteboard for programming teams. But our programming languages are very poorly suited for handwriting: they waste the spatial arrangement, ideographic symbols, text size variation, and long lines (e.g. horizontal and vertical rules, boxes, and arrows) that we can easily draw by hand, instead using textual identifiers and nested grammatical structure

However, if you want to be able to type math in Unicode, I recommend my guide on setting up your keyboard in GNU/Linux and/or my compose-key map, although Mark Shoulson has written most of it by now.

Hi! What this incantation means is the following:

1. Open Emacs.
2. Press and hold down the Alt key.
3. Press and release the "x" key.
4. Release the Alt key.
5. Type "linum-mode".
6. Press Enter.

The Emacs tutorial somewhat explains the weird "M-" notation on line 17. If you take half an hour to go through the first few pages of it, you'll be a lot more comfortable! You can get to it in Emacs by pressing F1 t or C-h t.

I just installed w3 to see. After some work I found a page it doesn't crash on, but I can't figure out how to click any of the links. I think we can treat w3-mode as dead, viable only on earlier versions of Emacs and earlier versions of the Web.

Wikipedia screenshot

vi is Just An Editor. Emacs is an extensible, customizable, self-documenting display editor; all of these except "display editor" are things that distinguish it from vi. Vim is also an extensible, customizable, self-documenting display editor, like Emacs and unlike vi. It has some differences from Emacs — a larger fraction of it is written in C, it uses vi's command set, it uses more domain-specific languages while Emacs tends to use Lisp for everything, and it starts up and shuts down more rapidly — but essentially Vim and Emacs are indistinguishable from vi's point of view.

I prefer Emacs for programming and Vim for everything else. For whatever reason, w3-mode isn't installed in my Emacs (maybe it's obsolete?), and the Emacs Sokoban, Tetris, text adventure, and Eliza aren't sufficiently captivating for me to run them basically ever.

So I don't think there's a huge difference between the two editors from that point of view. However, in Emacs right now I have 31 buffers open, and I can switch between them in a couple of seconds with ido-mode. This can potentially be a distraction if you have Emacs open long enough; Vim I tend to start and stop often enough that it rarely has more than two or three files open. But in Vim I often have to navigate between the files I'm looking at by using the shell; I find this substantially more distracting than switching buffers in Emacs.

As explained in my comment above, Vultr doesn't accept Bitcoin for setting up new accounts.

There's no such thing as a free checking account anywhere in the country, but in any case I can't open a checking account. That's why I'm using Bitcoin in the first place.

I want to solve their problems, not give them new ones.

I found https://cryptorials.io/bitcoin-cloud-hosting-comparison/, which suggests Vultr (as a couple of people here have suggested; ETA: but which doesn't accept Bitcoin for setting up new accounts), and also Cloudways (ETA: which no longer accepts Bitcoin), Bithost (ETA: which seems to be working, minimum payment US$10, via coinpayments.net, successfully launched a server after awaiting two confirmations), and NETdepot, although that one seems to be US-only. (It also mentions another service that doesn't list per-hour prices.)

They don't seem to list prices on their website; why is that?

I don't have an AWS account or a credit card.

Thank you!

Edit: looks like they don't accept Bitcoin for setting up new accounts; their page says, "Account must be funded by credit card or PayPal before making a Bitcoin deposit."

This provider doesn't seem to offer a per-hour option, just a per-month option, so it isn't what I was asking for. Unless there's a page I'm missing?

You can do anything in Forth, but it's going to take a lot of work to reproduce Pandas or even numpy or even the Python standard library module csv in Forth. The advantages of Forth other than metaprogramming (determinism, comprehensibility, lack of dynamic allocation, ease of porting to weird platforms, minimal memory usage) do not help you here, and its disadvantages (wonky floating-point, extra bug-proneness, no garbage collector, lack of libraries) are enormous. And Python supports metaprogramming about as easily as Forth.

I recommend you fire up Jupyter and learn to use Pandas and matplotlib.

Maybe you could just snap your pages of equations with your phone camera? It won't take you anywhere close to 22 hours.

This is indeed a troubling problem. I hope you figure out how to solve it.

The people who don't want to read tables and charts and equations are dilettantes. You should ignore what they want. I'm very interested in reading tables, charts, and equations, because I'm pretty sure that my calculations came out very wrong when I tried to calculate about it, and I'd like to understand why.

I made some very rough calculations about your railgun and came to the conclusion that the vast majority of the capacitor energy ends up dissipated by resistance, basically on the theory that the back-EMF from accelerating the projectile can't get up to more than a few dozen volts until it's going several kilometers per second, assuming a 20mm path length through the projectile and a 500mT field, so a 22-gram projectile is about 100 times too heavy to be very efficient. Did I screw up my calculations? Have you shared yours anywhere? You commented, "Gotta get people interested before I throw tons of science around," but I can't find the science!

One thing I do see that I got wrong was thinking yours was arc-coupled: you say your projectile is actually coupled to the rails with molten aluminum. But I think that only makes a little bit of difference?

If you're black, you might get shot before anyone thinks to check the list. This guy survived, but not everyone does.

Those are tungsten carbide, which is only a little less dense than tungsten, but brittle, impossible to forge, and very difficult to machine.

I'm not really up on my supersonic aerodynamics, but I have the impression that you can still end up with instability with that kind of geometry, if the fins don't cut the bow shock, because the drag from the nose creating the bow shock is pretty high, while the drag from the fins cutting the behind-bow-shock air (subsonic relative to the projectile) is much lower. Is there simulation software out there for this? Because I think that's likely to be a lot more informative than trying to figure out what happened without even a high-speed camera.

I suspect that your transitional ballistics will be a lot less messy than those from a firearm, though, because you don't have a giant gas puff blowing on the slug from behind.