I folllowed him on YouTube for a while until he presented one of those new meta analysis on cholesterol (half a year ago maybe?) studies in a way that was highly uncritical. He forgot to mention that the meta analysis mentioned the Minnesota coronary experiment, which is a pretty blatant omission.
Quite the contrary. Shor's algorithm actually works better for the shorter keys of ECC. The rule of thumb is 2n qbits for RSA keys and 6n qbits for ecc. I believe it has something to do with hownit applies to the hidden subgroup problem of finite abelian groups rather than factorisation, but I am really not a cryptographer not especially mathsy. I just asked the same question you did, and someone in the know pointed me to that.
I think most people misunderstood syntax rules. It was not meant as the macro system for scheme. It was meant as the template macro system everyone could agree on, while leaving the more powerful low level macro systems to the implementations. Syntax case, or explicit/implicit renaming or syntactic closures or what have you.
They compose. And can be passed around and be completely oblivious to how they will be reduced. With conj or sum or whatever they want. And you can extend them at any point at any end.
They are like map, filter and friends, but they compose. I think of iterators as an iterator protocol and transducers as a streaming protocol. An iterator just describes how to iterate over a collection. Transducers are transformations that can be plugged into any point where data goes in one direction.
As I said, it is a protocol for iteration or data access. You cant take an iterator and hand it as a filter to a file reader. If I make a rot13 transducer I can hand it to a transduce function that transforms a collection. I can give it to a file reader as a transformer on any char.
I made srfi-171 [0], transducers for scheme. If you have any questions about them in general I can probably answer them. My version is pretty similar to the clojure version judging by the talks Rich Hickey gave on them.
Hah! I wrote a unit converter for Android recently and that is one of the criticism I get. "Why does my conversion end up in becquerel?" It is usually because people forgot to divide by time, where they write something like "(31l/m2)/1min in mm" when they should have have written something like "(31l/m2)/1min in mm/h". Anyway, check it out here:
I am about 6 days away from publishing and open beta (currently in mandatory closed testing). If you want to join the closed test, you can do so by mailing me at the email at the top of the readme.
I think your interface is a bit inconsistent, this is why people ask that question.
If you have
65mi in 12mi/h -> 19500s
then instead of
12h in s -> 43200s
you should have
12h in s -> 43200
Then a unit at the end should mean that not all dimensions have been reduced.
In the same vein, in the README, the "weird results" section should come after the "dimension removal" section. The way it is now, the apparent "bug" comes before the feature.
You are right about this being confusing. I have thought about whether to adopt in as strict division or whether to be strict about in UNIT to have to produce UNIT. The first one will not resolve the issue of Umits selecting becquerel or Hz to represent N/s, but the second is not as much fun.
Yes. But treating in a strict division isn't really what people expect. Then 12mi/h in km/h becomes "19.3xyz" not "19.3xyz km/h".
The least surprising thing would be to enforce unit output. If I say I want "in km/h" the output should be in km/h or show an error. It is however less fun. Getting becquerel when you forget a unit along the way is the kind of spice that makes life fun.
Treating "in" as strict division also doesnt solve the surprise of getting Bq or Hz when you accidentally end up with something that is N/s
reply