hoytech
Get a nylon string guitar. It doesn't have to be a flamenco guitar per-se, any classical will do. But steel string acoustic guitars will absolutely not work for this style. The sound is wrong and the strings are too close together.
Learn the Andalusian cadence. It's the chords A minor, G, F, and E, in that order. This is the characteristic "Spanish" sound recognisable by everyone, and is in fact a fundamental building block of Flamenco style (por arriba). The chords can be played barred or open, your choice. You can instead start in D minor (por medio) if you like.
Practice a basic rumba strumming pattern until it is drilled into your muscle memory. The easiest is to just strum, counting from 1 to 8, and on beat 5 slap the strings instead of strumming.
Do not use a pick. There are several right-hand techniques you'll want to learn. The most important is probably rasgueado ("gypsy strumming"). You essentially flick your fingers so that each one strums the strings in rapid succession. It's challenging at first, but try to make the timing in between fingers roughly even. Next is tremolo: rapidly plucking the same string with alternating fingers, while playing bass notes with your thumb. This is a common classical guitar technique too, but Flamenco takes it further, often using 4 plucks instead of 3. Actually flamenco technique breaks many classical guitar "rules".
Once you want to start mastering more specific styles ("palos"), just get some tabs and work through them. You'll probably want to start with soleares, alegrias, farruca, fandango. Unlike classical guitar, nobody will look down at you for using tabs (or learning by ear) instead of notation. Paco de Lucia famously does not read notation.
Hope this helps. Have fun!
These guys went through quite some hardships to define the length of a meter. Good read!
I'm working on a nostr-based discussion site heavily inspired by HN/reddit: https://oddbean.com/
No login required, and you can switch to a different client any time you want. We try to keep the bitcoin/politics stuff to a minimum on the homepage. There's a lot of that on nostr, but also a lot of kind and thoughtful discussion about diverse subjects.
This is not true. Hops were widespread in North America before European contact. There are broadly speaking 4 major land races of hops: European, Asian, and 2 from North America.
The history of hops breeding is pretty fascinating (at least to a nerd like me). Almost all of the trendy modern varieties that you would recognise from IPAs and NEIPAs (such as the "C" strains: your Cascades, Citras, etc) are the result of cross breeding a North American variety (probably Cluster) with a European variety (probably Fuggle), and can be traced back to a breeder who imported an "unknown strain from Manitoba" back to England, and bred and categorised hundreds of hybrids. I believe the goal was to breed a strain that was disease resistant but with less of the (now desirable) intense flavours characteristic of the North American strains.
I grow hops in Canada (Cascade, Centennial, Chinook, and Perle varieties). They are a really cool plant: I've never seen anything grow as quickly as they do (Benjamin Franklin once wrote about how impressive it was to watch hops grow), and their smell is really wonderful at harvest time. I dry, vacuum seal, and freeze them, and produce more whole leaf hops than I need for a year of brewing (which would otherwise cost several hundred dollars).
Surprisingly (to me), tablature is apparently older than sheet music. Tabs are also pretty nice when you're dealing with non-standard tunings.
Lastly, even with standard notation, guitar music is often "unnecessarily" annotated with numbers for left hand fingering, roman numerals for barres, "pima" for the right hand, diamonds for harmonics, etc.
The digital commitment scheme as described has a subtle vulnerability. Suppose there are two participants, A and B. B decides to wait until A's hash is shared. Once A shares it, B shares that same hash as their commitment. Then, after A reveals their number, B also "reveals" that same number.
Since the described protocol is to XOR these revealed numbers together, the resulting output will be 0 and B will have known that in advance, meaning it was not fair. With N honest participants and 2N (or more) dishonest colluding participants it gets worse. Consider participants A (honest) and B and C (dishonest/colluding). B "cancels out" A's result as described above, and then C's result is XORed in, allowing the dishonest participants to chose whatever arbitrary output bits they like.
There are several solutions, of course. You could specifically check for and disallow duplicated commitments, or use something other than XOR to combine. Note that addition is not a great choice here: since N+N is even, the least-significant bit is certain to be 0. Better would be to sort the numbers and then hash their concatenation.
Another serious problem with commitment schemes in practice is last-revealer bias. After everyone has committed, and everyone has revealed except for the last participant, that last participant knows the final outcome and nobody else does. If the resulting random number is disadvantageous to the last revealer for any reason, they may simply choose to not reveal it. Then what does the protocol do? After a timeout period, use all the values except for the unrevealed one? If so, the last-revealer gets "another chance", and has managed to bias the result in their favour. This also gets worse with colluding participants. After everyone has revealed except the dishonest cartel of N participants, they have 2^N possible outcomes they can choose from, by choosing which combination of their N numbers to reveal.
The only general solution to this is to have some sort of punishment for failure to reveal (slashing your stake, in blockchain lingo).
> A random stream's fairness can also be compromised if it continues to be used beyond the point of a player's decision. For example, if you decide to play a game of Monopoly over the internet then you will probably have to re-seed the RNG on each player's turn.
An interesting solution to this is a "progressive reveal scheme". Each participant generates a random number and hashes it. And then they hash that hash, and keep doing this N times. Then each commits to the Nth hash with the usual commit-reveal scheme. Afterwards, at every turn in the game, each player reveals their previous pre-image, which they're locked in to (assuming a collision-resistant hash function).
> the rejection sampling method described earlier will sometimes require that you "re-roll" a die
The average number of attempts you'll have to make is 1/P, where P is the probability of any one being accepted. The wikipedia article shows this using calculus, but I wrote up a much simpler derivation here: https://metacpan.org/pod/Session::Token#EFFICIENCY-OF-RE-ROL...
> The Fisher-Yates shuffle [...] guarantees equal probability of all possible orderings.
A somewhat counter-intuitive observation is that the number of possible orderings often exceeds the number of possible seeds for your PRNG. For example, even if you're using 256 bits of seed, lists of size 58 or greater cannot possibly have all possible orderings equally probable, simply because 58! > 2^256.
> If you're comfortable with the idea that physical or analog finger dice can simulate a coin flip by holding up either one or two fingers
I found it strange the author feels the need to introduce and describe "finger dice" in such an elementary way. This game is universally known as odds and evens, and has been played continuously at least since the days of ancient Greece: https://en.wikipedia.org/wiki/Odds_and_evens_(hand_game)
$ perl -MO=Deparse tp.pl
'division'->Illegal('zero'->by('at' / 'tmp' / 'quine' . 'line'->pl(1)));
tp.pl syntax OK
$ perl -e 'at / tmp'
Illegal division by zero at -e line 1.If you have a moment can you please elaborate a little more on your second paragraph? Are you describing applying a similar method inside the compression function of the hash function? Any hash function? Where does the parallelism come in? Thank you!
That makes sense about newer functions being immune. However, note that both of the cascaded hashes must be immune to prevent this attack (as described in the paper).
See Joux's "Multicollisions in Iterated Hash Functions. Application to Cascaded Constructions"
https://link.springer.com/content/pdf/10.1007/978-3-540-2862...
https://github.com/LMDB/lmdb/blob/30288c72573ceac719627183f1...
Which meta-page used is determined by the transaction ID (even IDs use first, odd IDs second).
This is the earliest description I can find of the "shadow paging" concept: https://dl.acm.org/doi/10.1145/320521.320540
And I believe its first implementation was in IBM's System R.
[0] http://www.lmdb.tech/doc/ [1] https://github.com/LMDB/lmdb/blob/30288c72573ceac719627183f1...
I'd be interested in reading about how Matcheroni compares with PEGTL and Lexy.
https://metacpan.org/pod/Regexp::Exhaustive#Finding-all-divi...
And if you're in Toronto in 3 weeks time, come see Abigail (the original inventor of the prime number regexp) solve the N-Queens problem with regexp:
https://tprc2023.sched.com/event/1LhoB/the-n-queens-problem-...
But probably some of the GPIO pins on the ESP32 are usable (unless they're reserved for the touch pad buttons on the front, I can't remember).
When you went to his classes you really had no idea what it was going to be about. I got the sense that sometimes he would just teach whatever was on his mind that day, nevermind the syllabus. It was sometimes bizarre, often challenging, and always interesting. I learned a lot from him.
I'm sad that he has passed and sorry to see his website is no longer online, but also pleased that his legacy is living on and people other than me still think of him -- thank you!
When the previous leap second was applied, a bunch of our Linux servers had kernel panics for some reason, so needless to say everyone was really concerned about a leap second happening during trading hours.
So I was assigned to make sure nothing bad would happen. I spent a month in the lab, simulating the leap second by fast forwarding clocks for all our different applications, testing different NTP implementations (I like chrony, for what it's worth). I had heaps of meetings with our partners trying to figure out what their plans were (they had none), and test what would happen if their clocks went backwards. I had to learn about how to install the leap seconds file into a bunch of software I never even knew existed, write various recovery scripts, and at one point was knee-deep in ntpd and Solaris kernel code.
After all that, the day before it was scheduled, the whole trading world agreed to halt the markets for 15 minutes before/after the leap second, so all my work was for nothing. I'm not sure what the moral is here, if there is one.
I don't know for sure, but I believe the JavaScript feature was inspired by Perl, which has had them since at least the v4 releases (1989-1993):
Instead, I've been working on my own library which also uses LMDB and flatbuffers. It's C++ only and still a WIP, but in case anyone else is interested, it's here: https://github.com/hoytech/rasgueadb
* '(1 #+nil 2 3)
(1 3)Section 2.5 of this paper has a good discussion on this: https://cr.yp.to/qmail/qmailsec-20071101.pdf
Just kidding, that's some nice propagation. One of my favourite websites is: https://www.pskreporter.info/pskmap.html
When I want to test an antenna or anything I just call CQ a few times on FT8 and within seconds I get dozens/hundreds of reports and can see how far/what direction my signal is going.