Bug with Powershell Get-Date

5 years ago today, I sent the following bug report to the Powershell team.

From: Lincoln Atkinson
Sent: Thursday, April 01, 2010 10:33 PM
To: PowerShell Discussions
Subject: Problem with get-date

Hey experts, maybe you can help me with this issue.

Get-Date seems totally broken for me.  I've tried it multiple times with all different parameters, but it's just not working in my environment.  I'm still single and I haven't gotten a date in months :-(

Get-Help really wasn't useful this time.  Funny, since many of the ladies I wanted to Get-Date with specifically suggested I “get-help.”  A few told me to try “get-life” and “get-bent,” as well, but I couldn't find those cmdlets.  They must be running some V3 beta.

I've debugged this a bit, and have eliminated some possibilities:

Localization – I live in Seattle, seems there should be a pretty good social scene there.
Build – I'm average height/weight, don't see this as holding me back.
Concurrency – In our modern era of tolerance I'd like to think this isn't a race condition.
Hardware – Not the issue.
Low Resources – Get-Job worked ok for me so I have at least a little money saved.

Any thoughts?  I just want to allocate some memories with someone and maybe attend a few advanced functions.

-Lincoln

The report was forwarded to the Powershell MVPs, who weighed in with reasoned opinions and sage advice.

Tibor Soós -- And if there is a parent object, he should also use the –confirm switch.

Hal Rottenberg -- I do NOT recommend concurrent job scenarios with this cmdlet. I have heard of it being done, but it never ends well.

Hal Rottenberg -- I just hope he didn't try the Force parameter. That one has some illegal page fault regression bugs in v2.

Susan Bradley -- Not to mention you really want to run with antivirus or have some protection in this scenario.

Oisín Grehan -- His deduction on localization might be flawed: Get-Date typically only works at places where Get-Culture returns a non-null value. [ouch!]

Tobias Weltner -- You also want to make sure not to use the undocumented –recurse switch which leads to unexpected results.

Non-transitive Grime Dice, via Mathematica

[All code from this post available as a GitHub gist here]

For Christmas this year, I got myself a fun mathematical gift: a set of 10 non-transitive dice, namely Grime Dice! You can get your own set here. Behold their dicey splendor:

Grime Dice

These dice possess the fascinating property that their winning relationships (in the sense of "winning" = "rolls a higher number > 50% of the time") are non-transitive. i.e. if die A wins against die B, and die B wins against die C, it actually does *not* hold, in general, that die A wins against die C.  In fact, die C might win against die A! Continue reading Non-transitive Grime Dice, via Mathematica

Today is Phi Day -- at least, it ought to be

By now, most everyone is aware of Pi Day, celebrating the famous mathematical constant \pi \approx 3.14159 on 3/14. On this day each year, students and math enthusiasts eat pie and engage in light-hearted \pi-related activities. Then there is e Day, a day for commemorating the equally-important-if-somewhat-less-famous constant e \approx 2.71828 on 2/7. The activities are similar, though it's less clear-cut what food one should eat (a high school teacher of mine insisted that the proper e Day food is waffles, evocative of the Cartesian coordinate system).  Even events like Pi Approximation Day (22/7 in day/month format), and Mole Day (6:02 10/23) have gained enough momentum to warrant dedicated results from both Google and Bing.

So when is Phi Day? Continue reading Today is Phi Day -- at least, it ought to be

Nested looping to programmatic depth in F#

This post is the December 26th entry in the 2014 English F# Blog Advent Calendar. Check out the other great posts from earlier in the month, or head over to the Japanese-language edition!

Ho ho ho! It's the day after Christmas, and hopefully everyone has some snazzy new toys to play with.  But just in case Santa left you a lump of coal ("... little Billy used mutable state this year ..."), don't pout, don't cry, I've got you covered.  My gift for all the naughty F# developers out there: a mini-framework for imperative-style looping in F#, adding the functionality of "break," "continue," and "return," along with the ability to nest loops down to programmatic depth. Continue reading Nested looping to programmatic depth in F#

Extending a 3rd-party API with F# units of measure

Continuing the recent theme of awesome .NET development news, a blog post from Thursday by the .NET team provided more details on the platform's future, ".NET Core."

The ensuing comment thread on Hacker News had some nice F# discussion.  One commenter, though, was not a huge fan, and in particular lamented perceived limitations in the F# units of measure feature: Continue reading Extending a 3rd-party API with F# units of measure

Muller's Recurrence - roundoff gone wrong

A while back I came upon a seemingly not-too-difficult programming exercise:

Define a recurrence x_n by

f(y, z) = 108 - \frac{815 - 1500/z}{y}
x_0 = 4
x_1 = 4.25
x_i = f(x_{i-1}, x_{i-2})

Compute x_{30}.

This isn't too hard to code up, using perhaps a recursive function to represent x_i. With normal double-precision floats, as i increases, the result converges neatly toward 100. Super!

Unfortunately, 100 is not even close to the right answer. This recurrence actually converges to 5. Continue reading Muller's Recurrence - roundoff gone wrong

Response to "Little Performance Explorations: F#"

I recently saw a tweet from Ryan Riley linking to an article exploring F# performance and floating point processing:

I poked around the code and tested it a bit myself, and figured I would take up the author's  call for feedback. Comments on the original blog are locked down, so I've written up my results here, instead. Continue reading Response to "Little Performance Explorations: F#"

F# extension methods in Roslyn

If you scan the source code for the Roslyn project, the platform on which the next-gen C# and VB compilers are based, you might stumble across an interesting special behavior that was added in for the sole purpose of preserving backward-compatibility with F#.

From [roslyn]\Src\Compilers\CSharp\Source\Symbols\Metadata\PE\PEAssemblySymbol.cs (as of commit dc3171c8a878):

public override bool MightContainExtensionMethods
{
    get
    {
        if (!this.lazyContainsExtensionMethods.HasValue())
        {
            var moduleSymbol = this.PrimaryModule;
            var module = moduleSymbol.Module;
            // The F# compiler may not emit an assembly-level ExtensionAttribute, and previous versions of C# never checked for it.
            // In order to avoid a breaking change (while preserving the perceived performance benefits of not looking for extension
            // methods in assemblies that don't contain them), we'll also look for FSharpInterfaceDataVersionAttribute.
            var mightContainExtensionMethods = module.HasExtensionAttribute(this.assembly.Handle, ignoreCase: false) ||
                                               module.HasFSharpInterfaceDataVersionAttribute(this.assembly.Handle);

            this.lazyContainsExtensionMethods = mightContainExtensionMethods.ToThreeState();
        }

        return this.lazyContainsExtensionMethods.Value();
    }
}

The comment does a nice job of summing up the issue, but allow me to provide some additional context. Continue reading F# extension methods in Roslyn