On a world that is not our Earth, two nations that share a continent have long been at odds, glaring across the separating river, and often breaking out into war. In a period akin to the inter-war years of Europe, these two nations have fallen into an uneasy armistice. Two young people, Wil and Allison, learn from an old man of a secret treasure that could end this seemingly eternal war.
That is a set-up that could last a whole series -- but that's just the first 4 episodes; and in the peace that follows there is skullduggery afoot seeking to reignite the flames of conflict. That provides for a series of escapades, including the involvement of our heroes with the royal family of the tiny statelet of Ixtova; then at the half-way mark, the torch passes to the next generation, Lillia, daughter of the original pair, and Trieze, incognito prince of Ixtova.
It's rather Tintin-esque in flavour; with firearms proving a threat but (except in one case of an old chap needing to exit the stage for plot reasons) never doing any harm. And there are magnificent old style train and aeroplanes.
There is a continual motif of the couples never realising each others' feelings, which one has come to expect from anime, but that never really gets in the way of a good Boys' Own style of adventure. The real weak point is the ending, which is, if you pardon the pun, a bit of a trainwreck -- the last episode is very poorly paced, and uneven in style.
Still, not bad in all -- the journey was fun, if a bit delayed.
To summarize -- if your Scala.Net project only uses .Net 1 features, then you can tweak the IL to use the .Net 2 libraries if you wish; but you can't build something that invokes full .Net 2 functionality as yet.
That means trying to build a Scala project against Silverlight assemblies is a non-starter (or at least not a trivial one) with the current build process. Using the out-of-the-box assemblies:
scalac-net.bat astroclock.scala -Xassem-path
System.Core.dll;system.dll;System.Windows.Browser.dll;System.Windows.dll
12@(06 15 12 80 ad 02 12 80 b1 12 88 c8)
error: error while loading Control, type 'System.Windows.Controls.Control' is broken
(15@2 in (06 15 12 80 ad 02 12 80 b1 12 88 c8))
9@(06 15 12 80 b9 01 12 86 80)
error: error while loading FrameworkElement, type 'System.Windows.FrameworkElement' is broken
(15@2 in (06 15 12 80 b9 01 12 86 80))
11@(20 01 15 12 25 01 12 78 11 85 b4)
error: error while loading UIElement, type 'System.Windows.UIElement' is broken
(15@3 in (20 01 15 12 25 01 12 78 11 85 b4))
11@(06 15 12 80 ad 02 12 86 38 11 5c)
error: error while loading DependencyObject, type 'System.Windows.DependencyObject' is broken
(15@2 in (06 15 12 80 ad 02 12 86 38 11 5c))
9@(06 15 12 80 b9 01 12 86 10)
error: error while loading Application, type 'System.Windows.Application' is bro
ken
(15@2 in (06 15 12 80 b9 01 12 86 10))
astroclock.scala:90: error: System.Windows.Application does not have a constructor
class MyApp extends Application {
^
…
scalac-net.bat astroclock.scala -Xassem-path
System.Core.dll;system.dll;System.Windows.Browser.dll;System.Windows.dll
error: error while loading String, type 'System.String' is broken
(PEModule.getTypeDefOrRef(): TypeSpec)
one error found
So, to do this would mean upgrading the scala-net compiler to understand .Net 2.0 constructs.
Later:--
In constructs like (15@2 in (06 15 12 80 ad 02 12 80 b1 12 88 c8)), the 0x15 (at position 2) is the code ELEMENT_TYPE_GENERICINST, which is then followed by <an mdTypeDef metadata token> <argument Count> <arg1> ... <argN>. The type metadata turns out to be a type-spec; but the rest of it I've not yet unpicked. And then there'd be reverse-engineering the Scala MSIL decompiler...
The first culprit is DependencyObject (#22 in the typedef table), for a private field; but there are dependency properties on UIElement which suffer the same.
I ordered a copy of Programming in Scala last Sunday -- and to my surprise, it arrived on my doorstep this morning. This, of course, deflected me from my F# and Silverlight activity today.
I think I shall have to try the experiment of putting Scala.Net into Silverlight, just as part of my usual "can I wedge this into that" play.
I would start with the recipe as before, in the library form; but to retro-fit a link against the Silverlight mscorlib which has the signature
Following up from yesterday, the rudiments of the clock, to show XAML integration in the F# plus Silverlight combination. This should be enough of a template for starting with and mutating to taste.
The code is unchanged in the Feb 2010 (v 1.9.9.9) CTP.
astroclock.xaml:
which we note has a UserControl as root, and astroclock.fs:
with the obvious AppManifest.xaml:
LATER: Data binding sort of works sometimes; I can get it to work when set at run-time to bind a string to a TextBlock via myTextBlock.DataContext <- this.StringProperty (but not yet through XAML), and Sliders are being totally recalcitrant...
I think there is some autogeneration magic just not happening for F# -- the best I can get seems to be to approximate a one-time binding -- so it's back to wiring up events by hand.
Feb 2010: This post is probably obsolete as we're coming up on Silverlight 4.0, so I've not retested. You might get away with changing the 1.9.6.2 version in the file path to 1.9.9.9 now.
Tinkering with my silverlight/IronPython planetarium clock, I find that the bulk of the errors I'm making are in units of measure -- is this angle in degrees, radians, hours or days? This is just the thing that F# CTP has built in features to cope with. So, proving the concept of Silverlight with F#...
Google turns up a bunch of references, some assuming a full Visual Studio while I'm developing on a laptop with just IronPython Studio and F# part of the time; others slightly out of date (still referring to System.Windows.Controls.dll from the beta).
The latter, John Liao's post, looked promising, though, so I duplicated it thus--
New F# library; paste the code in to the autogenerated Module1.fs
Remove all references supplied by default
Add a reference to System.Core and to System.Windows by navigating directly to the Silverlight SDK binaries in C:\Program Files\Microsoft SDKs\Silverlight\v2.0\Reference Assemblies -- at this point you can also add any others you're going to want
Use the suggested AppManifest.xaml without the System.Windows.Controls.dll line
create a folder in $(ProjectDir) called simplebutton and copy C:\Program Files\FSharp-1.9.6.2\bin\FSharp.Core.dll into it, along with the AppManifest.xaml above
create an empty file null.py in the folder to keep chiron quiet
Use the suggested TestPage.html, putting it in $(ProjectDir)
Build project
Load page in browser and enjoy
Note that the FSharp.Core.dll assembly is crucial in the manifest, even though it's not needed as an explicit reference in the project at build time -- everything links happily with it as an implicit component for building -- but without it there in the manifest and the XAP, the Silverlight content fails to load, silently, without putting up anything into the error reporting <div> as a cry for help!
"This rating (G) was determined based on the presence of the following words: stab (1x)"
But also
which probably rules out any pols.
Also, at the typealyzer
ISTP - The Mechanics
The independent and problem-solving type. They are especially attuned to the demands of the moment are masters of responding to challenges that arise spontaneously. They generally prefer to think things out for themselves and often avoid inter-personal conflicts.
The Mechanics enjoy working together with other independent and highly skilled people and often like seek fun and action both in their work and personal life. They enjoy adventure and risk such as in driving race cars or working as policemen and firefighters.
Saturday last, getting up early-ish to get hair cut, and attend to vanities before going out in the evening, so driving into town rather than taking advantage of the mild weather. Town was quiet, the only real activity a long queue in Borders; though Morrison's had been very busy Friday late morning.
Sunday, very mild, cycling to the garden centre with just an open denim jacket over my T-shirt, for sake of sleeves, and sandals on feet.
Two days at work, winding down, some self development, some tidying up of bugs, getting home with 29000 on the odometer as I parked. Wednesday, cooler, and dull, OK for cycling -- but had brightened to T-shirtable when I nipped out for lunch. Usual dinner with friends in the evening, even if being designated driver takes the edge off.
Thursday -- don't get up at all; drift downstairs for breakfast to eat in bed just before dark.
Friday -- drive to the in-laws, with the A12 being quite busy, and slow to the Blackwall Tunnel. Coming back being surprised on the M11 to often be cruising past traffic in the slow lane when only doing 60 myself.
Today -- hard, white frost again overnight. Drive in to town late morning for a few odds and ends to find the place seething. In all respects, the opposite of last week.
Set the data on the object to be "data:application/x-silverlight-2," to get it to work at all
to restore the effect of transparency remove the <param name="windowless" value="true" />
set an opaque value rather than <param name="background" value="#00000000" /> matching the page background colour
manually tile a matching background image and set background image brush with Stretch="None" to match any page background image
In particular, there seems to be no obvious way to get at the parameter set of the object from JavaScript via a DOM look-up on the <object> tag, otherwise I would have done some jQuery magic via browser sniffing instead.
Bug in my jQuery usage. BRB
You can do something like
but once you've tiled with an opaque image, there's no effect (even if this substitution were in fact in time to be useful).
I guess such customization would be possible via the silverlight.js file; however that needs tome work of its own to fix up to provise silverlight 2 data types.
The release notes give a view from 50,000 feet; the help file stubbornly refuses to play for me (the document window gives a 404 error); but there's already some stuff about the new material out on the 'net:
Windows PowerShell V2 CTP3 release is compatible with and replaces previous versions of Windows PowerShell. To install the Windows PowerShell V2 CTP3 release you must uninstall any previous version of Windows PowerShell.
Windows PowerShell V2 CTP3 uses the execution policy setting from
the previous installation, if present. The Windows PowerShell installer
does not remove or change the execution policy when you uninstall
Windows PowerShell.
On XP, I got bumped from a previous Unrestricted to AllSigned, as I found when starting up the new shell for the first time and getting my start-up script denied. Going Set-ExecutionPolicy unrestricted then resulted in
Set-ExecutionPolicy : Windows PowerShell updated your
execution policy successfully, but the setting is overridden by a
policy defined at a more specific scope. Due to the override, your
shell will retain its current effective execution policy of
"AllSigned". For more information, please see "Get-Help
Set-ExecutionPolicy." At line:1 char:20 + Set-ExecutionPolicy <<<< unrestricted + CategoryInfo : PermissionDenied: (:) [Set-ExecutionPolicy], SecurityException + FullyQualifiedErrorId : ExecutionPolicyOverride,Microsoft.PowerShell.Com mands.SetExecutionPolicyCommand
Running the C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe executable directly (not via shortcut) as the local Administrator (right-click, Run as...) lets that user change settings without spitting out a message stating that this is futile; but that is not propagated globally.
Other users (like my usual login) trying to run scripts still got the same
File ...\???.ps1 cannot be loaded. The file ...\???.ps1
is not digitally signed. The script will not execute on the system.
Please see "get-help about_signing" for more details.. At line:1 char:2 + . <<<< '...\???.ps1' + CategoryInfo : NotSpecified: (:) [], PSSecurityException + FullyQualifiedErrorId : RuntimeException
as before, and going Set-ExecutionPolicy unrestricted still results in the same message as above, too!
I've not yet found an official work around to this override through PoSh itself -- but you can directly frob the setting by going to the registry (OK, you can do this in PoSh as well, but it's still "cheating") and setting the value of HKEY_CURRENT_USER\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell\ExecutionPolicy from AllSigned to Unrestricted. Although running as Administrator has changed the key at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell\ExecutionPolicy to Unrestricted, any per-user setting that has already been struck from this pattern seems to remain to override this.
LATER : setting the HKCU value to RemoteSigned then leaves me at Unrestricted, until I similarly edit the HKLM key as well. LOL WUT?
Set-ExecutionPolicy still remains ineffective as a normal (local administrator) user.
Note: This issue was resolved by the May 2009 CTP. The cmdlet code is unchanged in the Feb 2010 (v 1.9.9.9) CTP.
There's a catch to this, as I discovered today. You can't -- or to be accurate, you can't inherit PSSnapIn in F# yet. As also noted here, the F# compiler gets its knickers in a twist about the internal abstract members higher up the inheritance chain, culminating in an error stating that PSInstaller.get_RegKey() and PSInstaller.get_RegValues() are not implemented.
You can't fix this with cunning reflection tricks (if you make an override method to call via reflection into the base class, you get told that there's nothing public to override; if you make it a member, you get back to the same error as before). And you can't fix it by delegating the install to a PSSnapIn subclass in a different assembly, because that just registers the delegated assembly (which probably contains no cmdlets at all).
But you can use a CustomPSSnapIn subclass in an assembly that references the F# code. For a very simple "Hello World", based on the code samples from the Wrox PowerShell Programming book we do something like
in the custom snap-in subclass, which is the only class needed in a C# project, which generates the assembly that you actually register via installutil. This project references your F# module for the cmdlet classes that do the real work, and just does the work of publishing them to the PoSh infrastructure. The essentials of the F# code are (in the .fsi file):
where the constructor declaration is essential for the cmdlet to work, and in the .fs file:
I have completed the reimplementation of what was about 20kloc of C/C++ (15kloc of which being an SDK of which I actually used only about half the capabilities of), in just over 1kloc. I could probably refactor/rewrite the C/C++ to reduce it in size by a factor of 3-4 -- I have an approximately 1kloc replacement for the parts of the SDK I actually use -- but there is a limit around that mark where the amount of code needed just to placate the Win32 gods applies a hard lower bound for the tout ensemble.
And not only is it shorter (a big win for keeping what's going on in your head in the first place), using the right language for the job means that the threading story is far clearer, too. And, as an unlooked for bonus, the whole thing (a protocol terminating data pump) performs far better under load, without being at all resource heavy.
Given the choice, I don't think there's another platform that I'd choose for doing such bits of network plumbing infrastructure.
A blanket of rain clouds hid the full moon that was both close to perigee and close to the winter solstice last night; but Thursday's clear night was very bright and steely grey, sparkling in hard frost under a cloudless sky with a near as makes no difference full moon.
app.py -- remove the line clr.AddReference('System.Windows.Controls.Extended, Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35')
Delete all earlier assemblies and use all the assemblies from C:\Program Files\IronPython 2.0\Silverlight\bin.
Or, from scratch, with the embedding paged base around C:\Program Files\IronPython 2.0\Silverlight\script\templates\python\index.html ...
app.py
app.xaml
AppManifest.xaml
The XAP file is now down to 935kb, which considerably closes the gap with Jython 2.2.1's 670k but is still noticeably larger than a minimal Jython 2.1 applet:
274467 Aug 13 21:48 applet.jar
956662 Dec 13 17:50 app.xap
2266 Dec 13 17:53 index.html
2071 Aug 13 22:02 jython.html
However, now both products are at a stable release, it starts to make sense to actually use the technology.
The weekend has been clear, sunny or moonlit by turns, and very cold; the days very agreeable in the level of sunshine. The cats agree, by going out to sit on the picnic table and bask.
The Tonks are showing that they have pedigrees, by coming in to use the litter tray at intervals -- Kami being an accomplished master of the one-way catflap now.
It was funny to watch them when going out to find something to tastier to drink than tapwater licking at the film of meltwater on the ice in the various containers on the patio.
And here's a first stab at an F# brush, which is in use for this post.
The symbolic class is not yet working; ocaml and reserved do work, and there's more to add, as noted in the introductory comment, if I can get past the symbolic hurdle.
Last night wheeling Karen to WI and back, the going was very slippery underfoot and everything was sparkling in the street lights.
This morning, I not only waited until well after sun-up to go to work, but decided to take main roads into work; but that still meant a mile or so on minor roads to get there.
And almost as soon as I got out of the village, traffic started piling up. The reason -- two recovery trucks pulling cars out of a ditch, the only length of ditch without hedges along the whole road.
Finally, belatedly, I have achieved my New Year's Resolution (of 1920x1200) -- for the last couple of years since my 1997 vintage 19" 1600x1200 VDU died, I have had to put up with having a smaller screen resolution at home than in the office (equivalent 19" 1600x1200 VDU, upgraded a few weeks ago to 24" 1920x1200 LCD), which has meant that when I GotoMyPC (the best acquisition Citrix has made during my time with them so far as end-user dog-fooding goes) to home-work, I've had to suffer blurred/shrunken text.
No longer. Now, for the same £200 price-tag as the 19" 1280x1024 screen I got as a replacement for the dead VDU at the time, I now have the same headline spec as at work; this being about 1/4 the price I would have had to pay had I gone straight to this spec. So now I see my office screen at 1:1; and playing video, especially wide-screen video, is just amazing.
This has not been for want of trying, though -- just that actually getting my hands on such an item for the instant gratification facto has taken 3 months : they seemed never to be in stock when I tried to buy.
The SEO benefits of clean web design emerged in thread on /a/ over the weekend. Apparently my NGE fan-site comes very high up Google search.
This emerged in the context that some who feel that my opinions are not so much heterodox as heretical were uncomfortable that my writings should be so easily stumbled across by newcomers.
Nothing stopping them writing their own sites with cleaner design, though.
RD Sennou Chosashitsu aka Real Drive aka Healthy Drive is this year's Shirow/Production IG title, a return to the more familiar territory of a near future (2061 CE) cyber-enhanced future. Masamichi Haru, a diver working on an artificial island (the precursor to Appleseed's Olympus, perhaps?) in the very near future falls into a coma for 50 years as the result of some strange phenomenon caused by the construction work. Awakening an old man, he is assigned a highschool girl, Minamo Aoi, as a go-fer. And for the first two episodes, it looks like the recurrence of this phenomenon will be the plot.
The next two-thirds of the series is then simple episodes as Haru returns to diving in the virtual world of the MetaReal, he and Minamo stop striking sparks off one another, and generally the series becomes more like Aria than a typical Shirow cyber-future.
And then in the last half-dozen or so episodes, the plot resumes, bursts into eco-wibble (admittedly not a surprise for Shirow, being there even from the days of Dominion Tank Police), and then resolves the story with not one but two happy couples.
Overall : mostly harmless, the girls are easy on the eyes (no anime noodles or overdone superstructure), and the setting is definitely one of the few anime settings where I'd like to go and live.
Shirow's Ghost in the Shell is one of the few cases where the animation is superior to the manga (along with Utena, Princess Tutu, Evangelion and Mushishi). And his Appleseed was not only my first real manga, but far better than the original GitS -- so why has there never been a decent animated adaptation?
Appleseed : Ex Machina gets the equipment right, but it stops there. The use of machinima tempts to the dark side of video-game action, and away from the philosophical underpinnings so well brought out in the GitS anime. And then they have to make the plot shallow and add some romantic rivalry out of thing air too…
Possibly not helped by the fact that the bargain DVD I got only had American and German dub tracks, so it meant listening to bored voice actors drawling their lines (not something I noticed at the time of purchase -- what lame-ass production leaves the Japanese audio track off an anime DVD, after all?), but this is the third fail in a row for Appleseed movies/OVAs.
There's an anime series in the works for next year. Dare I still hope for a GitS moment?
A kitten who gets separated from her mother and littermates while distracted by a bird; a young family in an apartment with a "No Pets" clause…
Told in three minute episodes, four times a week through the middle of this year, Chi's Sweet Home contains all those little incidents that anyone who has shared their lives with a cat will recognise, as well as other dramas inherent in the set-up.
Although the end resolves the last major arc within the series, the human level story is left hanging; this suggests that there'll be a season 2. Next year, perhaps?
Mainly to put down where I can find it again (Google not having turned up any reassuring examples, particularly for queue:split()) that they do act as you think they would:
So queue:in() puts new entries into the queue, queue:split() counts from the output end, breaking the output as {Old, New}, queue:head() peeks and queue:out() pops.
In particular {_, NewQ} = queue:split(Discard, Q). will drop the indicated number of expired entries from the queue.
Another hard-SF story in the vein of his earlier Schild's Ladder — which is to say, hard as in technically stretching.
Two strands of story interleave; one being a lightly disguised primer in general relativity being bootstrapped in the plot by a pre-industrial society exposed to extreme conditions, the other being a more conventional (for Egan) post-human polein-style setting, tracing an unexpected trace of DNA life deep into the core of the galaxy, while musing on the theme of what does intelligence do when it's been there (for all interesting values of there), done that (ditto) and got the T-shirt.
While it's the best SF book I've read all year, that's not setting a very high bar, and it's pretty run-of-the-mill Egan. Still, it occupied a wet autumn afternoon in a better way than chatting on 4chan…
And a week ago, the weather forecast was for snow -- which turned out to mainly being heavy rain, with a bit of slush on the road as I was driving home through Bourn.
The forecase for sub-zero nights and days of single digit temperatures to follow did come true though -- but thanks to the new cavity wall insulation, turning the central heating on (3 weeks later than usual) for just an hour or so morning and evening was sufficient.
And having changed from summer to winter duvet at the weekend, it's back to the summer one and heating off by default, now that temperatures are in high single figures outside.
All it can't fix is the shortening of the hours of daylight.
Our Home's Fox Deity was one of the surprises of the spring season. The first episode, which introduces the main characters -- two brothers (Tooru and Noboru Takagami), the fox spirit that their family had sealed away (Kuugen Tenko), and Kou, the guardian priestess of the clan -- is all SERIOUS BUSINESS, with plenty of archaic and technical (for the purposes of magic) Japanese, until it at the close, when it looks like it's going to become a magical girlfriend series.
Next episode changes the mood again -- we meet the local deity where the Takagamis, and their new guests, live, and he's the manager of the local 7-11 equivalent. And so it goes -- while the original motivation, that Tooru is at risk from spectres, powers a few fight scenes over the first third of the series, that quite soon fades into the background. What becomes important is that with such houseguests, all the local supernatural goings on start to leak, in a comedic fashion, into their lives -- a neighbouring kami has lost an item of power, the recovery of which intrudes into their lives, as do a homeless family of fox-spirits, the local church run by oni, a werewolf, and the celestial agents trying to keep life tidy for everyone.
Meanwhile Kou and Kuu, both unfamiliar with modern life, provide a constant source of broad comedy -- and the appearance of rivals for Noboru's affections in the eyes of the girl who really fancies him. And in this way, 24 episodes pass, with each little episode tidied up, but no conclusion yet in sight.
I had been prepared to drop the series after a couple of episodes, when it hadn't properly gelled, but Karen was attracted to the whimsical style, so we kept on watching -- and I'm glad to have gotten over that initial hump. So, not a classic of the ages -- just something fun that doesn't take itself too seriously, and makes effective use of the creatures of Japanese folklore dragged into the modern mundane world of tight household budgets.
All too often, anime series manage to lose the plot spending too much time setting up panty shots for reasons of fan-service, and not enough on the story. Strike Witches managed to avoid this common trap by leaving the girls half-dressed at best (though also including a number of steam obscured hot bath scenes for "uprating" in the DVD release).
By this ruse of continually running the fan-service in tandem with a setting that panders to the military otaku by including a wealth of period detail all over -- like making Sanya Litvyak's magical antennae (lower right) match those of the plane her prototype (Soviet ace Lydia Litvyak) flew; or naming Charlotte "Shirley" Yeager's plane after Chuck Yeager's Glamorous Glennis, to name but two -- Studio Gonzo have succeeded in making a series where the fan-service actually receded into the background. Once you've watched through the dogfighting in the first few minutes of the first episode, you get desensitised to the full screen pantsu.
The story is a fairly standard and slight one, but executed with style and humour, and just a little dash of "monster of the week" -- Yoshika Miyafuji is taken from the land of Fuso to Britannia partly in search of her father, but eventually to help protect against the scourge of the Neuroi, extradimensional invaders who have overrun much of mainland Europe. So there are friendships, rivalries, personal sorrows, and the inevitable brass who don't care for the unorthodox nature of the 501st Joint Fighter Wing, right up until the time in September 1944 when Gallia is liberated.
And then we end with a teaser for season two, which seems a given, the series having been an unexpected runaway hit (having apparently been pitched before last year's mecha musume title, Sky Girls, by the same designer, but left to later), an hit which may well have saved the studio financially.
One of Q2s series that I picked up as harmless watching, and to that low standard it delivered (when subs eventually arrived).
It's a sorta-contemporary, sorta-Left Coast private investigator story -- a conspiracy with weird science (turning abducted girls into short-lived walking glass statues), the disenchanted ex-cop and a bunch of associated dead-beats and weirdos who get involved. Once you see the pieces laid out for you, you know how it's going to unfold, modulo the level of minor character deaths; and in that it does not disappoint.
Wins a Black Lagoon award for anti-helicopter tactics.
Thursday morning just gone, stumbling downstairs in the dark at twenty to seven, to see the cats sitting at the patio doors, looking out, with the just-past-full moonlight streaming in.
A* in Scala -- would be a fairly mechanical translation of the F# version with probably more explicit type declarations. The F# inference of a numeric type for operator < and + fails, so those operations on generic type B have to be pulled into a Graph[A,B] trait.
A few apples still left on the Bramley, and a lot on the Charles Ross. And this lunchtime, a tortoiseshell butterfly and a fallen leaf lying side by side on the picnic table, looking almost the same at first glance.
A light refactoring of the previous. It pulls in the worst offenders where functions really ought to have been nested; and passes the problem-specific parts around as a bunch of functions in a record type Graph<'a,'b>.
This lets me disentangle the generic graph traversal bit from the specific problem, something I was complaining about yesterday.
Updated to F#1.9.9.9 11-Feb-10.
Since units of measure don't apply to int, I couldn't add a proper type discriminator between the metric for the graph and the node indices (let alone the set of swaps that are of type index XOR index in this representation) as integers. I could make the metric a float to distinguish it by type, so I did that instead.
The "no solution" cases that gave warnings have been provided for, and a few other minimal tweaks have gone into pattern matches. There are a few places where I'm still needlessly binding variables in patterns, but I think that is probably just a venal sin at worst :) -- I consider them to be little different from temporaries-for-clarity.
The real goal of the last couple of exercises, creeping crabwise up on doing something in F# that's not totally trivial.
Having started with the wikipedia pseudo-code, Python was an obvious first real language; then to make it pure functional, Erlang was the obvious choice, before going to F#. And boy was that last step painful at times.
Really Erlang:Python :: F#:C# -- the first two being dynamically typed and forgiving; the other requiring dodges like nullable/option types for the "it didn't work" return cases. Those required some wrestling with the type system in the middle of the conversion from Erlang, though in the end, all the explicit argument type specifications did eventually go away.
#light
// specialize for the torch-carrier problem
// bits 0-4 represent torch, 1m, 2m, 5m, 10m
// set bit = on the near side
//
// Updated to F# 1.9.9.9 11-Feb-10
// Every possible crossing of one or two
let swaps =
[3;5;9;17; 7; 11;13; 19;21;25];;
let crossing_time swap =
match swap with
| x when x > 16 -> 10
| x when x > 8 -> 5
| x when x > 4 -> 2
| _ -> 1;;
let h_score node =
crossing_time node;;
let equivalent_point x =
match x &&& 1 with
| 1 -> x
| _ -> 31^^^x;;
let rec compatible x y outlist inlist =
match inlist with
| [] -> outlist
| swap::tail when (y &&& swap) = swap ->
let newlist = (x^^^swap)::outlist
compatible x y newlist tail
| swap2::tail2 -> compatible x y outlist tail2;;
let neighbour_nodes x =
compatible x (equivalent_point x) [] swaps;;
let dist_between x y =
crossing_time (x^^^y);;
//------------ Generic A* starts here --------------
let rec reconstruct_path came_from node =
match Map.find node came_from with
| None ->
node :: []
| value ->
node :: reconstruct_path came_from value;;
let rec update x y old_f old_g old_from g_value =
let key_f = Map.containsKey y old_f
let key_g = Map.containsKey y old_g
let key_from = Map.containsKey (Some y) old_from
match (key_f, key_g, key_from) with
| (true,_,_) -> update x y (Map.remove y old_f) old_g old_from g_value
| (_,true,_) -> update x y old_f (Map.remove y old_g) old_from g_value
| (_,_,true) -> update x y old_f old_g (Map.remove (Some y) old_from) g_value
| _ ->
let new_from = Map.add (Some y) (Some x) old_from
let new_g = Map.add y g_value old_g
let new_f = Map.add y (g_value + (h_score y)) old_f // Estimated total distance from start to goal through y.
(new_f, new_g, new_from);;
let rec scan x neighbours openset closedset f g from =
match neighbours with
| [] -> (openset, f, g, from)
| y::n ->
if Set.contains y closedset then
scan x n openset closedset f g from
else
let g0 = Map.find x g
let trial_g = g0 + dist_between x y
if Set.contains y openset then
let old_g = Map.find y g
if trial_g < old_g then
let (new_f, new_g, new_from) = update x y f g from trial_g
scan x n openset closedset new_f new_g new_from
else
scan x n openset closedset f g from
else
let new_open = Set.add y openset
let (new_f, new_g, new_from) = update x y f g from trial_g
scan x n new_open closedset new_f new_g new_from;;
let best_step openlist score =
let choice score h best best_value =
let v = Map.find h score
match best with
| None -> ((Some h), v)
| x when Some v < Some best_value -> ((Some h), v)
| _ -> (best, best_value)
let rec best_step4 openlist score best best_value =
match openlist with
| [] -> best
| h::tail ->
let pair = choice score h best best_value
match pair with
| (next, next_value) -> best_step4 tail score next next_value
match openlist with
| [] -> None
| list ->
best_step4 list score None 0;;
let rec astar_step goal closedset openset f_score g_score came_from =
match Set.count openset with
| 0 ->
None;
|_ ->
let l = Set.toList openset
let pt = best_step l f_score
if (Some goal) = pt then
let path = reconstruct_path came_from (Some goal)
Some path
else
match pt with
| None -> None
| Some x ->
let next_open = Set.remove x openset
let next_closed = Set.add x closedset
let neighbours = neighbour_nodes x
let (new_open, new_f, new_g, new_from) = scan x neighbours next_open next_closed f_score g_score came_from
astar_step goal next_closed new_open new_f new_g new_from;;
let astar start goal =
let closedset = Set.empty // The set of nodes already evaluated.
let openset = Set.add start Set.empty // The set of tentative nodes to be evaluated
let f_score = Map.add start (h_score start) Map.empty
let g_score = Map.add start 0 Map.empty
let came_from = Map.add (Some start) None Map.empty
astar_step goal closedset openset f_score g_score came_from;;
//------------ Generic A* ends here ----------------
// presentation form
let rec display swap =
let decorate value =
match value with
| "" -> value
| _ -> sprintf "+%s" value
let rec compound swap bit =
sprintf "%d%s" (crossing_time swap) (decorate (display (swap^^^bit)))
match swap with
| x when x > 16 -> compound swap 16
| x when x > 8 -> compound swap 8
| x when x > 4 -> compound swap 4
| x when x > 2 -> compound swap 2
| _ -> "";;
let print_swap swap from =
let transition = display swap
match from &&& 1 with
| 1 -> printf " %s -->\n" transition
| _ -> printf "<-- %s\n" transition;;
let rec print_result path prev time =
match path with
| [] -> time
| (Some h)::trace ->
let swap = h^^^prev
print_swap swap h
let interval = time + crossing_time(swap)
print_result trace h interval;;
let main =
match astar 31 0 with
| Some((Some h)::trace) ->
let time = print_result trace h 0
printf "Time taken = %d minutes\n" time;;
printf "----";;
The ability to nest functions is where the big changes is structure from the Erlang version show up. I could do a bit more of this -- pulling astar_step into astar, for example, or pulling compatible and equivalent_point into neighbour_nodes -- but I wouldn't want to pull too many long functions inside other ones, simply for clarity.
Also the generic engine could in all three cases be given function arguments to replace the coupling by name in these examples.
It's also annoying that calls always have to go up the source file -- smells a bit of 'C' in comparison with the customary freedom to refer back and forth as in the other implementations (or even in C# or Java) -- so that the algorithm bit is now in the middle and not at the top.
Yes, this does compile with a couple of warnings about incomplete matches in failure cases.
This is what makes the Internet such a nice place. I'm working with a new language and environment because in a simple experiment, it showed promise for addressing a real problem at work, something involving concurrency and network connections i.e. the sort of arena Erlang was made to play in. My trouble then is, with no other in-house expertise, I can't get a code review for that which gives any great degree of cross-checking -- and I can't (obviously) put the real code out in the public arena for review.
By putting a separate piece of code -- nothing to do with the real work -- out on this blog, I have at least managed to get something of an arm's length review of style at least.
Having reflected on Vat's comment on the first post, I'm more minded to move the bit masking into the print_swap/2 function, to localise the concern (determining which side of the traverse one is going to) into one single scope, rather than spreading that process around two different functions, even though that loses the option to pattern match on a simple argument:-
The issue of localization-of-concerns wasn't such an issue with the Python version, since that was less aggressively broken into functions.
Clearly in earlier (unpublished) attempts at using the case construct in Erlang, I had been making some very n00bish mistakes. Today with a set of code that worked, and could be modified step-wise, I find that when used properly, it does make things terser -- fewer intermediate variables, and without the true branch meaning "false" -- and then lets me pattern match on expressions that are functions of arguments, rather than only the arguments themselves.
The use of if for crossing_time and display gives a natural if/else if cascade (as the most "traditional" analogue for what the Erlang if does). Most of the time, using case has made the code terser (removing the need for most temporaries in simple binary choices, if nothing else -- here best_step is an exception, where the temporary looks to be a necessity); for update, it was about neutral. Maybe there is a trick I am missing, but anything going through a binary looks like it would make crossing_time and display more cumbersome, rather than less.
Posts
