I need to calculate the probability that the pips on x D6 will add up to y. Anyone got any ideas?
It always annoys me when websites force links to defaulty open in a new window/tab (from now on referred to as window). It strikes me as an arrogant assumption of how you want to browse - you want to keep their websites open when in fact the truth is sometimes - a lot of the time - I don't. It is also a major distraction to browsing continuity as most browsers will defautly focus the newly opened window.
It is trivial to open something in a new window yourself - in most browsers a middle click will do it, and a Ctrl+Click if not (though almost all mice now have middle mouse buttons and touchpads some combination that makes it possible). There are arguments that some find precise click difficult, and so will often accidentally activate the mouse scroll feature instead. In my personal experience I have found people have little problem with this, but I have seen no actual evidence for either. If it does happen to be a problem for a small section of users it can be turned into an accessibility feature.
With this in mind, surely it makes much more sense to give the power over to the user? Let them decide whether they want something to open in a new window or not. This would create a consistency - they know what to expect when they click on a link. Without some visual indication as to whether the link will open in a new window or not it can get confusing, and the visual indications would become a clutter.
It's not just through laziness that web designers don't make offsite links open in a new window, it's arguably a good design practice.
As I move more and more towards a functional style of programming I often find myself using referentially transparent functions in amongst the rest of my C# code. A referentially transparent function is basically one that guarantees that it has no side-effects (modifies anything outside of the function) such that every time you call it with a particular argument it will give you the same result.
In these cases it is trivial to optimise it using momoization - that is caching the results for given inputs. However, it is a lot of redundant code to repeat the same caching mechanism again and again, and actually quite difficult when you start to try and get the correct balance between time and space with sophisticated caching algorithms. The ideal place for this would be in the CLR which has much better knowledge about the current demands on memory (think garbage collection).
To this end, I tentatively propose const methods. These are basically methods that are guaranteed to be referentially transparent by denying access to variables and non-const methods outside of the function (of course reference to constants are allowed). These could then be optimised using several different techniques. A const method is implied to be static (an instance method would allow access to the mutable state of the instance object - this.MutableProperty).
Below is an example syntax:
public const int Factorial(int x)
{
return x*(x+1)/2;
}
The lack of reference to variables outside of the function doesn't restrict the use of variables inside the function:
private const int Factorial(int x)
{
int tally = 0;
for (int i = 1; i <= x; i++)
{
tally += i;
}
return tally;
}
Note that this is slightly different to a const method in C++ which, afaik (though I may be wrong), is an assurance that it won't modify any state, but it can still read from it (which leads to the confusing situation that a const method is not referentially transparent - that is a const method isn't constant for a given input).
A lot of the library functions would have to be modified - though only to add the "const" keyword in most cases (some could be trivially re-written to be const).
A friend of mine (they all seem to be Guardian readers) pointed me towards a recent Guardian article relating to Facebook. It's an intriguing insight into, as the title describes, "The politics of the people behind Facebook" and for that it is interesting. But it also bleeds a large critique of Facebook into it, some of which is valid, but others of it seem to just be journalism.
For instance, a much cited criticism is that it breaks down communication and reduces them to mere "pokes" with no-one talking to each other in real life. "I know them in real life, why would I want to talk to anyone else?" when in fact a lot of people use it to keep in touch/informed about people they would normally lose contact with because personal contact is far too expensive a draw on one's time to devote to everyone you might like. And then for people they do keep in touch with normally it provides an extra level and richness of communication. You can be thoughtful, funny or rude in a more immediate time frame.
The article mentions a friend of the author who spent a night in drinking and on Facebook. Oh the horror! Because had he not done that he would have...what? Watched a movie instead? He almost certainly wouldn't have gone out on the town or met up with a friend - he probably just wasn't in that sort of mood.*
As much as people like to push the idea, I seriously doubt Facebook reduces the amount of contact people spend with each other, though I do not have any evidence with which to back up such a claim.
"Facebook is profoundly uncreative. It makes nothing at all. It simply mediates in relationships that were happening anyway."
While this is true, it makes Facebook sound far less important and effort than it is. It's not new, it's not creative, but it is a tool that for whatever reason people have chosen to use. And that reason is largely design and marketing. Not to mention all the work in maintaining and developing the site.
I would also like to ask the author how they would resolve some of the problems he highlights in Facebook's "Privacy Policy", as it would help out...well...nearly every website out there.
"You can't delete anything"
Data needs to be backed up - that's just a fact of life with a service like Facebook. You can't then very easily go editing these backups, it would make it unstable and the whole concept of a backup pointless.
"Anyone can glance at your intimate confessions...You understand and acknowledge that, even after removal, copies of user content may remain viewable in cached and archived pages or if other users have copied or stored your user content."
You simply can't stop this. This is the Internet. As for not being responsible for circumvention, it's basically saying "We've done our best. If someone is better, then there's not a lot we can do". Typical covering your ass stuff you will see most places.
"Opting out doesn't mean opting out"
Basically they are reserving the right to contact you in important cases. e.g. violation of Terms and Agreements. Makes perfect sense.
"The CIA may look at the stuff when they feel like it"
"We are obeying the law".
Nothing there is unique to Facebook. I'm not saying it's ideal, and there are perhaps issues that could be resolved to a limited extent, but they are by no means a problem induced by the nature of Facebook (other than, perhaps, the sheer volume of information). The only real gripe is the personalised advertisement, which I personaly don't mind/am in favour of but I can understand people not liking it.
* Note: I have taken the specific situation described by the author and generalised it to a very imaginable situation.
Over the past few weeks I've been building a steadily growing collection of helper functions. I've gotten to the stage where I've had to write enough reduce functions, manually fill enough arrays and rewritten enough foreach as for loops to get sick of it and begin writing my own helper library.
Below is what I would say is the most useful to others that I would like to share. The purpose of it is to allow one to utilise a foreach loop over an enumerable collection whilst still being able to get at the index. In the past I have often found myself needing to use a for loop instead of a foreach loop simply because I needed the index of the item in the collection. I didn't need to do anything fancy with it, I didn't need to increment it by more than 1, I just needed to be able to refer to it.
A method is written that extends anything that implements IEnumerable, returning a custom enumerator. All this enumerator does is itself enumerate over the collection, yielding the current item along with it's index. Below is a sample usage.using System;
using System.Collections.Generic;
using System.Collections;namespace ICR
{
public static class Collections
{
public static IEnumerable<IndexValuePair<T>> GetIndexValuePairs<T>(this IEnumerable<T> collection)
{
return new IndexValuePairsCollection<T>(collection);
}public sealed class IndexValuePair<T>
{
public int Index { get; private set; }
public T Value { get; private set; }public IndexValuePair(int index, T value)
{
Index = index;
Value = value;
}
}private class IndexValuePairsCollection<T> : IEnumerable<IndexValuePair<T>>
{
private IEnumerable<T> Collection { get; set; }public IndexValuePairsCollection(IEnumerable<T> collection)
{
Collection = collection;
}public IEnumerator<IndexValuePair<T>> GetEnumerator()
{
int index = 0;
foreach (T item in Collection)
{
yield return new IndexValuePair<T>(index++, item);
}
}IEnumerator IEnumerable.GetEnumerator()
{
return ((IndexValuePairsCollection<T>)this).GetEnumerator();
}
}}
}
Sequence.Range is another helper function I have written that returns an object that enumerates over ints/floats/doubles/characters in a given range.foreach (var character in Sequence.Range('a', 'z').GetIndexValuePairs())
{
Console.WriteLine("{0}: {1}", character.Index, character.Value);
}
This code is concise with a clear intent. Compare with the alternative.
This also highlights another advantage - in the second example the sequence had to be stored in a local variable to allow for the multiple references to it (characters.Count and characters[index]). We did not have to do this in the first, allowing for a tighter and cleaner scope control.List<char> characters = (List<char>)Sequence.Range('a', 'z');
for (int index = 0; index < characters.Count; index++)
{
Console.WriteLine("{0}: {1}", index, characters[index]);
}
Our solution also allows one to get the index of any IEnumerable, something which is even more untidy to do with a for loop. (N.B. This is not always appropriate, but depends on the context of the IEnumerable)
Feel free to use the code yourself if you think it would help. Any suggestions and feedback would be welcome,
