WSJ article (paywalled): https://www.wsj.com/tech/ai/anthropic-halts-access-to-top-ai... . The accessible portion mentions a letter from Howard Lutnick.
734 karma · joined September 23, 2011
It seems like this gets easier as the kids get older; I've seen parents of teenagers make it work. For some folks it's a family affair---several kids & one or both parents learning to fly. These families have been uniformly super fun to have at the field! For others I think it's a matter of the kids being old enough to have some independence, + I'm sure a very supportive partner.
So don't give up on gliders forever! I'm expecting times in my life when I can't get out to the field enough to stay proficient & safe, and I'll have to quit flying for a little---but a dearly hope not forever. It's just that, likewise, now's maybe not the right time for you.
Very much the case! (Well, idk quite what gp imagined, but it's not as expensive as many things.)
When I was learning, around 2020, I budgeted ~$300 / month for glider flying, + ~$600 (I think: they've gone up!) for annual club dues. These days the monthly would be a bit higher, and the dues more like $700-800, I think. Flying as a club member is a lot cheaper than rides; you pay for the tow and for time on the aircraft, but aircraft time is way, way cheaper than power (no fuel to burn, no engine to maintain) and the instructors are volunteers.
NB this is in a club environment. The upside is that it's cheap and the club environment is a really good place to learn by osmosis / watching everybody else / listening to stories / seeing all kinds of different situations. The downside is that it's a huge time commitment. You'll drive 1.5 hrs and hang around all day to get twoish flights, sometimes < 10 min. each. And you have to be willing to commit all of every Saturday (or Sunday) for a year plus: you need to be flying just about every week, and given that some weekends'll be weathered out you have to be ready to take advantage of every flyable weekend. Folks that aren't committed just don't make progress: hang around, season after season, still flying with instructors, until they finally give up or just occasionally grind it out.
(I did the bulk of my training in 2020 and spring/early summer 2021. This was perfect: I was single and newish to the area I was living in, and thanks to Covid I had nothing else going on in my life. Even as things started to reopen in 2021 it was easy to maintain that "saturday? of course I'm at the field" habit.)
This is all harder to do as a Real Adult with responsibilities. Some folks manage to do it, but it's harder. Commercial operations, where you go and get a whole bunch of flying in relatively quickly, are also an option---but I hear there's a wide range of quality, and even the best won't get you the seasoning / airmanship you get from hanging around at the field every weekend for a year, flying in all sorts of conditions and taking advantage of the unofficial ground school from all the other instructor/student pairs there at the same time.
The economics change first once you've got your rating, when you're no longer doing short training flights and the bulk of your flying is (one hopes!) longer soaring flights; and then again when (if) you buy your own glider---but it's still that few thousand bucks / year order of magnitude. Expensive, but doable, especially compared to power.
Gliders themselves range from "surprisingly inexpensive" to "less expensive than a new powered aircraft", more or less. I'd expect to hear something like $5,000 for a Schweizer 1-26 (https://en.wikipedia.org/wiki/Schweizer_SGS_1-26: classic glider, still widely flown by a devoted community, but appreciably lower performance than gliders built after the massive jump that came with the switch to fiberglass); I have a part-share in a Jantar (https://en.wikipedia.org/wiki/SZD-41_Jantar_Standard, early fiberglass) that totals $25,000 or a little less, with reasonably nice avionics.
So, all told, yes, flying gliders costs a meaningful amount of money, but isn't terribly terribly expensive. The question to ask yourself is really not whether you've got the money, but whether you've got the time.
As for multiple choice and q&a---my practice is to make both Cloze and basic cards for, well, most things---Cloze are good for the early steps and for seeing how different pieces fit together, but basic cards are more demanding, and without them I don't quite feel like I've learned a thing.
(FWIW my primary use is physics & the mathematics behind it, not language learning.)
From his perspective, of course, using Runge-Kutta makes perfect sense. This is "Huh: I have this tool, and applying it to this problem wouldn't be too hard; would the tool work?", not "I should create a new tool."
ETA: couple of forgotten words.
"a magistrate judge [...] has authority to issue a warrant to use remote access to search electronic storage media [...]" (emphasis mine)
IANAL, though; could someone who knows more explain what's going on? How will the procedure and requirements for obtaining a warrant for such "remote access" differ from those for searching, say, a house?
Edit: as I typed, slapshot posted some helpful explanation.
(I couldn't get to the original; I suppose the site is attracting an entirely deserved flood of attention.)
This is even more true when I'm working on my own: it requires a substantial amount of effort to make it through one 25 min. pomodoro period.
(I also want an open-source implementation, but it would seem that isn't on the table.)
Oh, man, that bit me so many times, especially when it had to interact with some kind of scoping trick. I read that tutorial (or the equivalent from before the WL), and never really got good intuition for how immediate & delayed evaluation worked and when to use which.
> There might have been higher level ways to do this using functions like Array and Table, but perhaps not.
I was actually using Table, but I was thinking of it as "iterate over these variables". Table's nice, although every once in a while it would break the picture I had in my head of it as "map-over-cartesian-products".
> Plus, I think we have a chance in the next year or two to really leapfrog other languages with some amazing static analysis tools.
Great! Another beef I have with Mathematica (and Scheme, for that matter) is that it doesn't have types: since I learned bits and pieces of Haskell and started using Julia seriously, I've come to love the way a type system can save me from my own stupidity. This is definitely a matter of taste, though.
Maybe :-)---this was a year and a half ago, or more. I do remember spending a fair amount of time trying to wrap my head around the implications of the difference between `f[x] = x^2` and `f[x_] = x^2`, and the differences between "Module", "Block", and "With". I also had a hard time with closures & symbols---I was trying use something not unlike the bank-account example from SICP (https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-20.htm...) to cache some intermediate computations, and it got very messy very quickly.
Now I recognize that this is in no way idiomatic Mathematica code, and I'm sure there is a nice Mathematica-y way to achieve this, but that's sort of my point. I have a problem, think "Aha! I know exactly how to deal with this in Scheme!", try to translate the Scheme solution into Mathematica, and either fail miserably or spend way too much time trying to figure out how to persuade Mathematica to do what I want. (I should perhaps admit that when I hear "Lisp" I think Scheme and to a certain extent CL, with lexical scoping, as opposed to elisp, with dynamic scoping. This is a flaw in my thinking I've never really gotten around to rectifying.)
> The functional parts of Mathematica/WL (by which I mean the equivalents of fold, filter, map, etc) are pretty straightforward and should be quite easy for a Lisp programmer to pick up. See [0].
Yeah, those were pretty natural.
> Note to self: clearly we aren't making it easy enough to understand what WL can do, especially for people who pick it up for one specific thing.
This is important, I think, but I also think the problem's less in your documentation than in how I "learned" Mathematica. I got started using Mathematica for things like messy integrals, or differentiating and then simplifying some huge expression. Something comes up in a problem set, I try three or four times to do it by hand and always lose signs/factors/whatever, and then farm it out to Mathematica; as I gradually started doing more and more, I kept just porting Lisp experience, and this always worked just barely well enough that I wasn't forced to learn Mathematica on its own terms.
I suspect if I had thought about it as "basically m4 with a crazy-awesome standard library", rather than "basically Scheme with a crazy-awesome standard library", I might have been happier, but ultimately I needed (need) to recognize that Mathematica is its own thing, with its own strengths, weaknesses, and fundamental metaphors.
> Btw, its called a "term rewriting system", not a "rule rewriting engine".
Ack. Thanks; I'll try to bear that in mind.
> Did you really want to write diagonalization from scratch? Why not use the superfunction Eigensystem [2], which has been honed by many experts over many years?
No! You're right, that would be a terrible idea. I was using Eigensystem; in Julia I farmed it out to LAPACK via eigs(). My problem was in setting up the matrix to be diagonalized. The state space had something like seven degrees of freedom (four two-dimensional and three with arbitrary dimensions), so I was calculating matrix elements for up to something like N = 10^5 basis states. (There were some tricks to pull so I was iterating through O(N) states, not O(N^2).)
Ultimately, for sufficiently large N, the diagonalization is going to take much longer than the setup, just because the scaling's worse. For small-ish N, though, the setup was interminable, and those small-N test cases are precisely where I need to be able to move quickly when I'm trying to figure out which stupidity I perpetrated this time.
> It's a bit odd to criticize a functional programming language for not having super-fast 'for' loops.
Yeah, no kidding. This was a classic Fortran-style problem, which is why I feel kind of stupid for having even tried to do it in Mathematica.
>> The lesson I learned, though, was to never use Mathematica for anything beyond basic symbolic calculations---integrals, that sort of thing.
>That's basically nonsense. Wolfram|Alpha is a multi-million line Mathematica/WL system that goes far beyond symbolic manipulation. As a totally random example, take Facebook social network analysis [3].
Fair enough. And I have a very smart friend who has sworn by Mathematica for years (and just spent some time working for you guys)---maybe it really is a combination of how I approach Mathematica, the types of problems I've tried to solve in it, and the fact that de gustibus non disputandum. I can't shake the feeling, though, that I'd want to run away very quickly from a large Mathematica/WL project like Wolfram|Alpha.
Edit: missing newline, missing )
The jungle of function-definition-like expressions and the scoping constructs were particularly bad, but I also found that the language & the culture made it far too difficult to write readable code. (I find my eyes glazing over almost immediately when I try to read the Wolfram blog: it's so very hard for me to see the structure of the code.) Perhaps once you become happy with the core principles of the language all of this gets better, but I spent quite a lot of time thinking it and never really got there.
Moreover, I never figured out how to do iterations quickly; even once I got the thing working, it was prohibitively slow.
Ultimately I re-wrote it in Julia, which was a much better fit for the problem (exact diagonalization of a one-particle tight-binding Hamiltonian). That was a rather more pleasant experience.
Now, this is in part about the problem domain: I wasn't doing any symbolic manipulation, though (IIRC) I was comparing my results with those from some symbolic calculations. (Honestly, I feel pretty stupid for having even tried to do it in Mathematica in the first place.)
The lesson I learned, though, was to never use Mathematica for anything beyond basic symbolic calculations---integrals, that sort of thing.
My experience with Mathematica is sort of like my experience with Fortran: if you stick to the sorts of problems for which it was developed (hard-core numerics for Fortran, symbolic manipulations for Mathematica), it's great, but if you want to do something more general you're in for a rough time.
(I understand Fortran's gotten progressively better, but I don't have any experience with anything after 95, and even that was a codebase heavily inflected with 77.)
This was a pain, and it was compounded by the fact that the HP-48 didn't have the same features as the TI-89, so I was frequently out of luck. The teacher wrote his homeworks and tests with an eye towards what was doable without too much effort on a TI-89, and I imagine that the TI people chose the featureset for the 89 with an eye towards what people would want to do in high school classes, so using anything else was an uphill battle.
(We also had occasional homeworks in Excel, and I ran into the same trouble trying to do them in Perl. It didn't help that I was very far from an expert in either Perl or the HP-48g.)
Philip Guo (pgbovine) addressed many of these problems in his thesis work, on Burrito (http://www.pgbovine.net/burrito.html ) and CDE (http://www.pgbovine.net/cde.html ). Both of these look very cool, but I've never managed to get over the hump and actually start playing with them.
At this point I should note that I'm actually in favor of fixing a bad standard-library PRNG---I just think it's important to understand (a) what could break, and (b) why users might be unhappy about the breakage. This isn't quite a Chesterton's Fence sort of situation, but it's similar in spirit.
(Now, why one would be using Java for Monte Carlo simulations I haven't the foggiest idea.)
The OED doesn't comment on the act (ritual) of breaking ground, but Wikipedia does, and it uses the un-hyphenated form. https://en.wikipedia.org/wiki/Groundbreaking . (Wikipedia is not, of course, the most reliable possible source, but it does indicate that the un-hyphenated form is in wide use for the literal act).
My strong suspicion is that the colloquialism arose as a metaphorical back-formation of a participle from the gerund + object compound used for, you know, ritually inaugurating (inaugerating?) a building project.
Edit: removed ill-considered emoticon.
Edit: missing verb, missing particle in infinitive
1. Frequently (in physics) you can find a core skeleton of fundamental definitions & results. If you know these, you can solve a whole bunch of problems very easily; also, in reviewing those results, you inevitably remind yourself of why they're true (I'm starting to make a re-derivation a criterion for listing a "fact" as memorized), and of the broader logical structure of the discipline.
2. Certain problems exercise a wide variety of important techniques very quickly; I use Mnemosyne to prompt myself to re-work certain problems every so often. I try to be aggressive enough about rating "how well I know this" that I'm actually re-working the problems, not just memorizing. This is sort of like the "code kata" I've seen people suggest every now and then.
Now, this is for physics, which is probably not exactly what you mean by "technical knowledge" :-). I expect this approach would generalize very nicely to mathematics and theoretical CS (and in fact I'm using it for bits and pieces in those fields); code & software engineering would be harder, but probably doable.
Edit: removed pointer to (link to) Gwern's article: it's in the gp. Also assorted stylistic matters.