> Wouldn't putting "everyone in a numbered sequence unknown to them" require a random number, which we don't have?
Yes. The above answer just obfuscates the issue. Consider ten people overwhelmingly biased towards 7. The suggested approach in all likelihood gets you 1, 2, 3, 4, 5, 6, 7, 8, 9, 10. Then what? You're clearly not much closer to getting a single random number without a random way of picking one of them.
>You're clearly not much closer to getting a single random number without a random way of picking one of them.
That’s a characteristic of the original formulation of the question, not specifically in my solution. It’s implicit in the article that you can choose an arbitrary person in the room without bias.
It's a shortcoming specifically introduced by your proposal. If you've got a random way of picking one of ten people, then you've already got a random number between one and ten. Your answer essentially reduces to: ask one person to think of a number then add an actual random number and mod 10.
>The easy thing to do is to ask someone “Hey, pick a random number from 1 to 10!”. The person replies “7!”. Great! Now you have a number. However, you start to wonder, is the number uniformly random?
So the problem reduces to transforming one form of randomness (picking a person) to another form (a uniform numeric distribution. That's implicit in the whole rest of the article.
>If you've got a random way of picking one of ten people, then you've already got a random number between one and ten.
You've got a source of randomness, but you still need to turn that into a number. The article gives one method and I've given another. You could also assign the people numbers from a stack of shuffled numbered tiles, then pick a person although that requires you have the tiles which is not really part of the setup. The conceit is that you have to use people's ability to pick numbers pseudo-randomly. There are probably numerous ways.
The question assumes we have the normal faculties of humans. You can choose whatever non random criteria for ordering them you like as long as it doesn’t affect their number choice.
For example height, or age, or distance from the door to the room, or how much I like them, or where in the sequence I arbitrarily decide to put them in. As long as that does not a priori influence their number choice we’re good.
The method (at least here in my country) is really simple (and not really a secret):
The voicemail can be reached from a special number. This number is easy to derive from the actual phone number (usually inserting one or two digits, depending on the provider). When the "owner" calls the mailbox, he gets the "admin" functionality. Anyone else calling it can only add messages. The rest is just simple call forwarding.
So all that is needed is finding out the number of the mail box.
Not sure if it still works, but in Israel it is as simple as prepending the voice mail prefix to the phone number. Some voice mail boxes can receive faxes, so there is some legitimate use for it.
Having done a lot of python recently, this looks great (and familiar).
But some things feel a little bit rushed:
- In the example "(o is int i || (o is string s && int.TryParse(s, out i))": When reading this statement as a human, o is obviously not an int when it comes down to the TryParse function. But if the 1st part was removed, the 2nd part wouldn't be valid either. I know this is technically how declarations work and I don't have an idea, if there is a better solution for this, but it feels weird.
- The new features of the case statement are nice but the old syntax with the mandatory break is probably worth getting rid of. Especially since all cases share a scope, adding/removing cases is prone to errors. I'd love to see a solution similar to "catch".
- The Deconstruct method is introduced as a "magic name". No interface, no override, nothing... Even the return type is "void". Why not use something like "public out Point(...)" to keep it similar in fashion to the constructor. Other options may be something with "this" (like indexing) or "operator".
I was thrown by the first one you pointed out too, I'm still not sure I understand it.
The page said for type patterns it will "test that the input has type T, and if so, extracts the value of the input into a fresh variable x of type T", so if o is an int it'll be extracted to a fresh int i with that value
But the out syntax in TryParse isn't the new one they mentioned, it's the current one that requires predeclared variables - to be new it'd be out int i or out var i. So i is already declared as an int before this code example? In that case how can the first bit work? Does it not create a "fresh variable" if there's already one in scope with the desired name and type? That could be quite confusing, usual behavior is to compile error if an inner scoped variable conflicts with an outer one, I'm not sure I understand why this should be different.
int i; // in the nearest enclosing scope
(o is int && (i = (int)o)) // in place of an expression
The "fresh" variable `i` is available for use elsewhere. If an `i` already exists in that scope (the block the `if` statement is in), that is a redeclaration of a variable which is a compile-time error.
If the "is" expression evaluates to `false`, the variable `i` will not be assigned, however, it will still be declared. Attempting to use `i` if it is not definitely assigned is a compile-time error. However, you have the opportunity to re-assign it.
Some examples:
{
if (!o is int i) throw Exception();
use(i); // works: i is declared and always assigned
}
{
if (o is int i) { do_something(i); }
use(i); // compile-error: i declared but might not be assigned
}
{
if (o is int i) { do_something(i); }
else { i = 0; }
use(i); // works -- definitely assigned
}
Thus the example pointed out in the post boils down to this in C# 6:
int i;
if (o is int) {
i = (int)o;
} else {
string s = o as string;
if (s != null && !int.TryParse(s, out i)) {
throw Exception();
}
}
// i is definitely assigned here.
> The Deconstruct method is introduced as a "magic name".
Collection initializers already rely on “magic names” (the `Add` method + `IEnumerable`), so I’d say that’s okay. It’s simply a compiler feature, after all.
Deconstruct will be an operator and this is how C# handles other operator overrides, e.g. equality, implicit/explicit type conversions, so this is in line with what developers would expect.
This ugly hack is not useful in general and only looks interesting here because the original example query is in bad taste. Simplifying it removes the tedium motivating the use of window functions.
For example, this is equivalent to the original query:
SELECT sku, sum(price)
FROM invoice_items
WHERE date_part('month',created_at) = 9
GROUP BY sku
See how the tedium disappears? In the original, the HAVING clause doesn't use any aggregate functions, which means it can instead be a WHERE. Removing the HAVING means we can further simplify the GROUP BY.
Of course, that only works because this example needs only a single month group. If you want multiple months and per-month price totals, then my rewritten query is no longer equivalent. It would need the more complicated GROUP BY. However, the window function version would also get more complicated in just the same way. The complication is inherent to the problem, not due to standards conformance.
Actually, what's really tedious is the verbose expression required to get the month and the fact that the author is repeating it. The standard provides "WITH" to avoid that duplication, and Postgres implements it.
Here's a reasonable version for multiple months:
WITH items AS (
SELECT *, date_part('month',created_at) AS month
FROM invoice_items
)
SELECT sku, month, sum(price)
FROM items
WHERE month in (7,8,9)
GROUP BY sku, month
But suppose we make the example even more complicated. Suppose you want sums over different time periods, like per-month and per-quarter. Then you can't use a GROUP BY and must use window functions and DISTINCT.
WITH items AS (
SELECT
*
,date_part('year',created_at) AS year
,date_part('month',created_at) AS month
,date_part('quarter',created_at) AS quarter
FROM invoice_items
)
SELECT DISTINCT
sku
,year
,month
,quarter
,sum(price) OVER (PARTITION BY year) AS yearly_total
,sum(price) OVER (PARTITION BY year, month) AS monthly_total
,sum(price) OVER (PARTITION BY year, quarter) AS quarterly_total
,sum(price) OVER (PARTITION BY month) AS month_number_total
,sum(price) OVER (PARTITION BY quarter) AS quarter_number_total
FROM items
ORDER BY 1,2,3,4
I think it's a shame that many database courses don't even mention advanced features like CTEs or Window functions.
It makes me cringe anytime I see a statement with complicated nested self joins to solve a problem that should not exist because most current database systems implemented the relevant standards years ago.
I don't get it. What's the point in keeping the key secret from cloudflare whilst providing a key server signing everything it is asked to sign? Isn't this like "Sorry I don't trust you enough to provide you a key to my apartment. But if you need something, just ask the janitor, he'll open the door any time you want"?
If you no longer trust the person, it's easier to tell the janitor not to admit him than to rely on his returning the key (and any copies) or to change the lock on the apartment.
The CA can revoke the certificate, but since revocation checking in browsers is neither universal nor reliable under attack, revocation isn't a completely effective way to recover from a compromised private key.
