plesner

Electronic voting has been discussed in Denmark and both experts and most politicians are against it. I suspect there's some correlation between how eager countries are to introduce electronic voting and how likely it is to be abused.

It is homegrown. The Dankort was a government initiative originally built and paid for by a consortium of banks back in the 80s. The theory was that the savings for the banks from having a more efficient alternative to cash would pay for the development costs, which is exactly how it turned out. But then the banks forgot that what they spent on payment processing they made back elsewhere and wanted it to pay for itself, and started cutting costs. Finally last year they sold the whole thing off to the US.

In addition, the dankort is strictly regulated to the benefit of consumers which the banks dislike because it limits how much they can charge when you use it. They have an interest in pushing people to visa or mastercard or their own mobile payment solutions which don't have the same restrictions. The payment processor itself is developing their own alternative to compete with the dankort which they are mandated to also implement. I don't think they provide bad dankort service on purpose but it's a concern that good service is actually against their own economic interest.

I'm Danish and I find this thoroughly distressing.

The payment processor, Nets, is a monopoly, owned by US investment firms. They have frequent outages and are unapologetic when they do. There is no transparency. They have a terrible privacy record (see https://en.wikipedia.org/wiki/2014_Se_og_H%C3%B8r_media_scan...). Until last year everyone down to their phone support staff had open access to everyone's payment records (see http://www.computerworld.dk/art/230818/alle-kundeservice-fol... -- in Danish). Despite all these issues they just laid off a bunch of people. Their only priority, it appears, it making money for the owners.

Money is a critical piece of infrastructure and these guys absolutely cannot be trusted to implement it. With more payment processors and a regulatory framework that forced them to provide decent service maybe cashless is not a bad idea. With the current implementation though there's a good chance it will be a disaster. It will certainly be a gaping vulnerability for anyone who should feel like targeting us; I wouldn't be surprised if all it would take to bring the whole thing down is one lone hacker.

What I said didn't really make sense -- f.test(f) is a concrete example so how am I generalizing? What I meant was: in the general case of expressions that contain multiple references to the same variable it might, for instance

f.testTwo(f = newF, f)

The point I don't agree with is that it's really about the compiler. Had it been an optimization that doesn't affect which warnings or errors you get then yes, that's all the compiler. But what you need here is for the types of variables to incorporate flow analysis such that f gets compatible types on both reads if it doesn't change, and incompatible if it does. That would be an incredibly complex type system and people already struggle with how generics in java work.

Actually, it's not in general decidable whether f.test(f) is safe because f gets read twice and the value might change in the meantime. In the example a simple flow analysis will tell you it doesn't but the general case is equivalent to the halting problem. The generic method solves the problem because now there is only one read in boom() and the concrete type in testFoo ensures that f can't change in an incompatible way between reads.

A more sophisticated type system could allow access if it can be proven safe with simple flow analysis but wildcards are already complicated, that would make them much more so for not much benefit.

To what end though? It's a small thing sure but it's busywork. Why am I being asked to do busywork?

Making python 3 more attractive is not the solution, it's part of the problem.

I can't use just python 3 because python 2 is still widely used. I can write code that works on both but now I'm using the worst of both worlds, and even worse I now have to test on both. And that'll last until python 2 goes away completely which, - when has a language ever gone away quickly?

These aren't fun problems. Improving python 3, making it more attractive, that's fun. But that's problem 2. Making migration less painful for me should be problem 1. Who's working actively on that?

What particularly grinds my gears is the apparent disregard for migration in the design. Take the changes to the print statement. Often this is the only thing that prevents my existing code from working in python 3. And it's in my muscle memory so I always get snagged when debugging on python 3. For what? Take a read through the rationale: https://www.python.org/dev/peps/pep-3105/#rationale. Most of the benefits you could have had if you'd named the new print function something else. I can understand that you regret adding it in the first place. What's even worse though? Adding it and then removing it in an incompatible way.

If you want to make python 3 more attractive maybe make migration easier before going on to the fun improvements? There are low-hanging fruits for migration too. How about adding back the print statement?

Is there any evidence that MS's recent OSS efforts are a reflection of anything other than the fact that Ballmer, who was ideologically against OSS, has left and so now MS can act rationally and use the OSS community the same way many other large companies do?

If working with the OSS community is in their own immediate self interest -- and I'm curious whether someone can point out something they've done that isn't -- I don't know how much light it sheds on an area such as OEMs where their self interest is best served by locking linux out.

Not necessarily disagreeing with your broader point but I just want to point out that the examples are only obscure and antiquared in English. æ is common in modern Danish and unambiguously a separate letter, as is þ in Icelandic.

While balanced ternary is nice in all sorts of ways, there's an argument against it being the most efficient representation. You might consider 2 better in practice in the sense that it makes it easier to pick the optimal amount of state space for a word when designing hardware.

On any practical architecture a word has some fixed length, N, and the vastly most efficient case will be when your number fits within that space. That is, it is more efficient if the number can be represented in r^N bits of state. The amount of state an architecture gives you is dictated by many different considerations but the radix that offers you most control (that is, most different possible values for r^N) is 2. For instance, say you want a word length that can store numbers up to 500, you have the options of

2^N: 2, 4, 8, 16, 32, 64, 128, 256

3^N: 3, 9, 27, 81, 243

So 2 gives you 8 choices for N whereas 3 gives you 5. So 2 gives you more design space to choose the most efficient representation in practice.

If you like the idea of e as a base I wrote a post about how you can do that, at least asymptotically, which might be of interest.

http://hummusandmagnets.tumblr.com/post/48829755849/how-to-u...

The fact that it's legal to say something, that it's uncensored, doesn't mean that it's right. Those are two different things.

I use scsh every day, not interactively but the scripts that implement my workflow are written in scsh. I don't change them all that often but when have to tweak something or add a command it's an absolute delight. Imagine -- a shell language with decent power of abstraction.

Here's the main script I use, as an example of practial scsh (I don't know if it would be considered idiomatic): https://github.com/plesner/scsh/blob/master/ash

Speaking of which are the greatest generals, according to Livy Hannibal and Scipio Africanus met at a dinner 10 years after Scipio definitively beat Hannibal and that's what their conversation was about. Scipio asked Hannibal, who are the greatest generals of all time? Hannibal said, Alexander, Pyrrhus and myself. Annoyed that he wasn't on the list Scipio said okay, what then if I hadn't beat you at Zama? Hannibal said, I'd have put myself ahead of both Alexander and Pyrrhus.

Unlikely to actually be true but a cute story.

IANAL but I don't see how using a BSD license automatically makes code FOSS. According to Lawrence Rosen[1] (who IS a lawyer),

"Since courts are likely to construe implied grants of license narrowly, a licensee should consider obtaining separately from the licensor an explicit grant of patent rights that might be needed for modified versions of BSD-licensed software."

This seems to go against the FOSS[2] freedom 2, the right to distribute modified copies without asking anyone for permission. Now, whether that can be applied in this particular case I don't know, I guess that depends on whether there are patents involved. But in general, BSD does not imply FOSS.

[1]: http://www.rosenlaw.com/oslbook.htm, chapter 5, p. 79

[2]: https://www.gnu.org/philosophy/free-sw.html

> So it wouldn't be worth defending at all, if it weren't being attacked on grounds I strongly disagree with, by people who I believe shouldn't gain any more influence over our culture than they already have.

I'm having trouble understanding what this means, concretely. Do you think it would be a bad thing if computer science became less of a boys club? Or do you not believe that is why people dislike the picture? Who is it exactly that has too much power over "our" culture -- women? Politically correct killjoys?

I just stopped reading after I got to that image. Why, with all the photos you could possibly choose, use a sexually suggestive one? And one whose context is the kind of boys-club software engineering we should be doing everything to get away from. Sigh.

Also, looking at the other comments, the fact that you happen to be fine with that image is neither here nor there. It certainly doesn't cancel out the fact that I'm not.

A little rusty on my QM but I believe the key to demonstrating when the collapse happens is that while doing a measurement will collapse the wave function, applying a transformation won't necessarily.

An experiment can work something like this. Produce 1000 state that you think are undecided. Apply a transformation that you know will turn the uncollapsed 50/50 state to 1 and the collapsed 0 and 1 states to the uncollapsed 50/50 state. Then measure all 1000 states. If they all yield 1, with high probability they were were indeed undecided to begin with. If they yield random results, with high probability they were collapsed 0 or 1 to begin with.

Thanks for the link, I hadn't seen that. I have two reactions.

Firstly, I find his example contrived. He wants to determine the accuracy of a black box by subtly tweaking how floating-point operations spread throughout that black box behave? It seems like an okay hook for ad-hoc debugging -- if those flags are around anyway -- but as the primary rationale for the entire rounding mode mechanism? That's not a lot of bang for a whole lot of complexity.

Secondly, this is exactly the kind of discussion around rationales and use cases I'm looking for. Even if I don't buy his solution the problem still stands and might be solvable some other way, for instance through better control over external dependencies. Maybe something like newspeak's modules-as-objects and hierarchy inheritance mechanisms could be applied here.

The way I hear this is: you have two options.

- Either use interval arithmetic which is tricky and may give you useless large bounds, but those bounds are guaranteed to hold.

- Or just try all the rounding modes which is less likely to give you large bounds, but now you have no guarantee that those bounds say something meaningful about your computation.

Or does the second case give meaningful guarantees?

I'm not claiming authority. What I'm saying is: there are two camps, the FP guys and the language guys, and there's not a huge amount of overlap. I belong to the language camp.

You're right. To be absolutely sure I tried writing a little program that does the thing I describe in the post, https://gist.github.com/plesner/7a13b5c8d269315df645, and sure enough it breaks down completely,

round default: 0.072817 round up: 0.072703 round down: 0.072931

Now I don't understand how you get a reliable result using rounding modes at all.

I don't know, that seems bad just in a different way. Maybe if IEEE hosted those documents themselves it would make sense to link to them but even then the copyright notice on the draft looks pretty onerous.

> Instead, the motivation he suggested was that you could run a computation in all the rounding modes, and if the results in all of them were reasonably close, you could be fairly certain that the result was accurate.

I actually thought that was the use case I was describing, though I would expect round-positive and round-negative to be enough. Don't the other rounding modes yield results within those bounds?

> nothing in IEEE-754 requires that this state be global. In the C language bindings, for example, dynamic rounding mode and status flags have thread scope.

My example, RegExp captures in JavaScript, also have thread scope. Thread local global state is still not good. What makes the flags global is that access to them is provided implicitly and ubiquitously, independent of scope. All the operations as well as the flag functions like saveAllFlags are given read and/or write access and none of them take arguments that control the scope of the flags they're manipulating. They get pulled from thin air. This is problematic.

I deliberately never say that the rounding flags are global, my strawmen are that they're either lexically or dynamically scoped, both of which are problematic.

> You can take "block" to mean whatever makes sense for your language: it could be a single arithmetic operation[1] or it could be the whole program (though it's more useful if it isn't).

What I'm arguing is that there is no interpretation of "block" that yields a satisfying result. I didn't consider applying it to individual operations because the whole motivation for the rounding mode mechanism is to keep the same mode is in effect across multiple operations. The lack of hardware support suggests the same thing.

Maybe you can give an example of how you see this working where the attributes are more tightly scoped than per-thread?

> Finally, the concern about "exceptions" is entirely misplaced. "Exception" in IEEE-754 simply means "an event that occurs when an operation on some particular operands has no outcome suitable for every reasonable application," which is a rather different meaning than the way "exception" is understood in colloquial PL usage.

Fair enough, though that introduces a new problem: how do you implement fp-exceptions if the're not language level exceptions? But maybe if a reasonable solution can be found for the rounding flags something like that would work for the exceptions too.

> I would encourage you to direct questions like these about the spec to committee members. If you work for a big company, a few members probably work with you. If you don't, most committee members are happy to answer questions, even from people they don't know.

I did, I raised some of these issues, including the licensing issue, with David Bindel a year ago.

Getting a good sense of a person is really difficult, especially through something as contrived as these technical interviews. And any company that sees enough applicants that they can afford it will err on the side of rejecting candidates even if they know they're probably good, if for whatever reason they're not quite sure. I've interviewed people that blew me away and then seen them rejected. I don't intend that as a criticism really because I can't imagine a hiring process, however well meaning, that doesn't have this issue to some extent. It's just how these things work.

When you don't get hired though, almost always you will err on the side of blaming yourself. I've heard about people blaming the process but I've never met someone in person who did that. And actually I suspect there's a Dunning–Kruger effect working where the more qualified you are the more likely you are to turn a rejection inwards and blame yourself.

I'm not saying that's what happened here, I don't know. Just keep in mind that hiring anywhere, including at amazon and google, can't be a fair process to the candidate. And you're the least objective observer of your own performance.

Nice work. I really like the simplicity of it.

The best strategy I've been able to come up with grows the exponent roughly every 50s: 47s to get to 100, 51s to 1415, and so on. I wonder if there's a way to do it faster.

"Google competitors say: google is bad"

What's the algorithm for mapping between locations and names? If I wanted to integrate this into my own code how would I do that -- is there a library?

Coincidentally I published a post about almost exactly the same thing only a few hours ago, http://h14s.p5r.org/2014/09/z-quads-strings.html. But it focuses more on the algorithmic side which is why I'm curious about the mechanics of UBIs.