Roy & I

March 11, 2017

Roy Austen (1953-2017), a former colleague, died a few days ago on March 5.

A friend recently told me that Roy had been diagnosed with cancer in January, although he had actually been unwell for months before then.

Not long after the diagnosis, Roy set up a GoFundMe page for medical expenses and for the ongoing care of his son, in preparation for the inevitable.

I really did mean to get in contact, but I got busy and Roy died before I did. At least there was still the fund…

Roy’s main line of work and his passion was photography, but that’s not how we got to know one another.

I bought my first Windows (3.1) PC from his family business, KM Computers.

Then, awhile later, he offered me a job and became my boss…

By the end of 1995 I was in search of my next job after 5 years at the University of Tasmania (UTAS) in Launceston as a computer systems officer then a junior academic in the Department of Applied Computing. A lot of university contracts weren’t being renewed around that time.

Luckily for me, Roy had recently started Vision Internet, one of a small but growing number of competing Internet Service Providers (ISPs) in Tasmania. It was a small business arising from KM Computers at a time when Internet access was still dial-up, ISDN/ISDL was the fastest you could hope for (128 Kbps), but most people just had a dial-up modem, giving up to around 56 Kbps, less in practice. Vision Internet started in Launceston but quickly added points of presence in other parts of the state, including an Internet Cafe.

In 1995 while still at UTAS, I had helped Roy out by writing a basic customer time accounting program in C that read utmp/wtmp logs and generated simple output when someone else had difficulty doing so.

By 1996, Roy needed a programmer and system administrator and I needed a job. Before accepting Roy’s job offer, I was up front with him that I would probably want to do something different after about 18 months. That happened with Karen and I moving to Adelaide in 1997 where I spent 10 years with Motorola. That move was more difficult than I expected, and at least as hard as Karen knew it would be. In the end, it was a good move.

Ironically, UTAS asked me to come back for some occasional part-time tutoring soon after I started working for Roy, which may have been less economical than if they’d just renewed my contract!

Vision Internet was good while it lasted. To be honest, for the first few months, I couldn’t believe I was being paid to write C  (and Perl) code, something I enjoyed doing anyway. 🙂

The compact machine room doubled as my office for the first year or so before we moved down the road to a more spacious building; not as cushy as my office at UTAS. I actually didn’t mind the machine room too much. A terminal with function key accessible “virtual consoles”, the vi editor, command-line shell, a C compiler, and a Perl interpreter kept me pretty happy. Roy was fine with me working from home occasionally as time went by too. He expected me to keep things rolling and solve problems as quickly as possible, but he was good to me and we got along pretty well.

There were only about half a dozen people working at Vision Internet, fewer early on. Everyone pitched in. Roy and I didn’t always see eye to eye though. For example, at one point we disagreed about who should have super-user privileges; more than I would have liked for a brief time. 🙂

I experienced a number of things during my time with Roy at Vision Internet and learned lessons from some:

  • Early mobile phones were fairly bulky. 🙂 Roy gave me my first mobile before I started in the job. Of course, this meant he could contact me whenever. He didn’t abuse that though. A former UTAS colleague took one look at the phone hanging off my belt and declared amusingly: “wanker phone”. 🙂 Even worse when a larger battery was added! Still, I appreciated Roy giving me my first mobile.
  • You can’t always spend time doing what you want in a job, even one you mostly like, unless you’re very lucky. I guess I already knew that from being a nurse in the 80s. I had no real interest in sysadmin tasks like applying security patches to BSD Unix kernels, maintaining backups, chasing hackers, worrying about what dodgy things people might be doing with our systems or customer sales, credit card transactions, help desk (shades of The IT Crowd: “is your modem plugged in?”). I mostly wanted to design, code, and test software. Still do. That’s largely why I told Roy I thought I’d want to move on after about 18 months. Having said that, a fair amount of my time was spent writing software in the form of a suite of customer time usage programs, each prefixed with tu, written in C and Perl. We also eventually sold tu to another local ISP.
  • The practical difference between code that uses a search-based processing algorithm over a linear data structure that runs in polynomial vs logarithmic time – O(n^2) vs O(n log n). This matters a lot as the number of customer records (n) increases when your task is to write a program that processes customer time usage once per day and obviously before the next day starts. To simplify: given a processing time of a second per customer, n≈300 can mean the difference between a run that takes a day instead of an hour. You can make incremental changes to the processing time per customer (t), but eventually you’ll hit a point where n is too large, e.g. when n=1000 and t is 0.1 seconds. Anyway, I don’t recall what our n and t were, but we hit such a limit with a tu program. When I realised what was going on and fixed it, Roy was delighted and relieved. I was pretty happy too and thanked my computer science education, in particular, the discipline of computational complexity.

Before I left to go work at Motorola, I made sure Roy wasn’t going to be left without someone in my role. This gave one of my former UTAS students (Craig Madden) the opportunity he needed to break into the industry; it turned out well for Roy and Vision too.

At the height of Vision Internet, I remember occasional staff gatherings at Roy’s. He was a good host and I think he mostly enjoyed that period, despite the worry that must’ve accompanied running a business. He was generally optimistic and trusted those he employed. He had his moments, like the rest of us, when he was unhappy or angry, but mostly, he was a good guy to be around.

If I could do so, I’d tell him this:

Roy, I’m really sorry you’re gone and that I didn’t make the time to get in contact. In recent years, I should have told you how much I appreciated the opportunity you gave me a long time ago. Upon reflection, after time spent together at Vision and elsewhere, I think we would have used the word “friend” (now distorted by social media) to describe our relationship, not just “colleague”, even if we didn’t say so. I should have told you that too.

On porting an ACE program to HTML5 (among other things)

March 1, 2017

In recent times I’ve been thinking about ACE BASIC, a compiler for the Amiga I stopped working on just over 20 years ago; nostalgia’s setting in I guess. A few years ago wrote a bit about ACE in relation to BASIC’s 50th; there’s more in these 1994 and 1997 articles.

As mentioned in the 50th post, a wonderfully thriving community built up around ACE between 1991 and 1996 centred upon an active mailing list and contributions of ideas, example programs and tools. I have been mildly (but pleasantly) surprised by a couple of things since I stopped development:

  1. Continued use of ACE on Amiga hardware and emulators for at least a decade afterward.
  2. An project to modify the code generator for post mid-90s Amiga operating systems and additional targets such as PowerPC and Intel.

Among other things, I’ve been thinking about a re-write for a modern platform or target, e.g. HTML5. The world of the 90s was still very platform-centric, but in the same year I stopped developing ACE, version 1.0 of the Java Development Kit was released, putting the power of Java and its  virtual machine into the hands of eager programmers. Java and JavaScript helped to consolidate the browser as an important platform and to define the shape of web development in a post-CGI (Common Gateway Interface, not Computer Generated Imagery) world.

A new compiler or interpreter is a non-trivial task, especially in my current spare-time-poor state, but I wanted to explore how an ACE program could be rewritten for an HTML5 context.

One of my favourite ACE programs was an implementation of IFS (Iterated Function Systems) to generate simple 2D structures such as ferns, trees, the Sierpinski Triangle and so on. So I started with this. It’s simple yet complex enough to allow for a comparison of approaches.

Here are a few observations on the original IFS ACE source code (ifs.b) and my initial HTML5 port of the code.

  • JavaScript in the browser appears to be faster than ACE on the Amiga. Sure, processors and clock speeds have improved since the mid-90s but ACE generated native 68000 assembly code. Then again, to think of JavaScript as an interpreted language is very simplistic with just in time compilation in widespread use.
  • The ACE code is quite data-centric. DATA statements containing comma-separated values are read into two dimensional arrays, so the original data is not close to where it’s used and it’s not clear what the numbers are associated with. I could have taken this approach in the port, but chose instead to create a data object, a map, close to the point of use, copying the original array names (bad in some cases: a, b, c, okay in others: xoffset, yscale) from the ACE program for use as map key names, to make a correspondence easier to see.
    • This meant first transposing the data (in Excel) so that DATA columns became rows.
    • Preserving the existing DATA organisation could be accomplished by introducing functions such as data() and read() that create and read, respectively, a pool of data values. For future DATA-centric ACE program ports, I’ll try that approach.
  • In ACE, the creation of a menu and its items is simple as shown by the creation of the Special menu below; this menu name is an Amiga convention. Shortcut key letters are optional.
    • menu 1,0,1,"Project"
      menu 1,1,1,"Sierpinski Triangle"
      menu 1,2,1,"Square"
      menu 1,3,1,"Fern"
      menu 1,4,1,"Tree #1"
      menu 1,5,1,"Tree #2"
      menu 1,6,1,"Sunflower"
      menu 1,7,0,"-------------------"
      menu 1,8,1,"Help...","H"
      menu 1,9,1,"About...","A"
  • Compare this with the odd combination of HTML, CSS and JavaScript in this initial attempt at a port.
  • On the other hand, ACE’s (and so AmigaBASIC’s) reliance upon numeric identifiers is almost as unreadable as a collection of DATA statements. The MENU statements above declare the Project menu to be the first (from the left of a menu bar), with each menu item numbered in order of desired appearance and 1 or 0 enabling or disabling the menu item. Subsequent enable/disable operations on menus must refer to the same combination of numeric IDs, e.g. menu 1,2,0 would disable the Square item. Also, menu item selection handling is a bit awkward in ACE.

The code eventually morphed into what I’ve dubbed ACEjs, in the spirit of some other JavaScript library/frameworks. I’m not claiming any novelty here. The idea was to answer the question: how might ACE code look in a modern context? I’m less concerned with slavishly preserving the look and feel of the program, i.e. I’m not trying to make it look like it’s running on an Amiga. I just want to make it functionally equivalent.

Here’s a screenshot of the simple example ifs.b program in ACEjs form:

IFS in ACEjs

I don’t currently have a screenshot of ifs.b running on an Amiga or an emulator.

In any case, the outcome so far is that I have made progress toward an ACE-inspired JavaScript library for HTML5. Here are some key aspects:

  • CSS, DOM, jQuery (so JavaScript) as web assembly language but only JavaScript code needs to be written.
  • Functions like menu(), window(), dialog() manipulate the DOM to add elements (canvas, list etc) via jQuery under the hood.
    • A menu declaration corresponding to the ACE code’s Project menu (with Help and separator items omitted) follows, a key difference being that menu items are paired with callback functions (e.g. see sierpinski below), another being that there is no support for shortcut keys currently:
      • acejs.menu("Project", [
            ["Sierpinski Triangle", sierpinski],
            ["Square", square],
            ["Fern", fern],
            ["Tree #1", tree1],
            ["Tree #2", tree2],
            ["Sunflower", sunflower],
            ["About...", about]
        ]);
    • A window declaration that adds a framed canvas looks like this:
      • wdw_id = acejs.window("IFS", 640, 400);
    • and operations on the window make use of an ID:
      • acejs.clear(wdw_id);
      • acejs.pset(wdw_id, outX, outY, pixelColor);
    • Multiple menus and windows can be created.
    • acejs.css is almost non-existent currently. I’m sure someone who delights in CSS could make it look suitably dark and brooding with their eyes closed. I make no claim to have any special talent in web design.

There’s arguably no need for a compiler or interpreter. JavaScript’s iteration, selection, and expressions are adequate. Having said that, ACEjs could form the basis of a target if I ever chose to write another ACE compiler or interpreter (with all that spare time of mine).

With ACEjs you only have to write an app.js source file for your application and use a standard index.html that brings in your code and whatever else is needed, in particular acejs.css (trivial right now) and acejs.js. The only special thing you have to do is to define an init() function in app.js to be invoked by the framework. The best way to see how this works is to look at the example.

You can either download the contents of the public_html directory and open index.html in your browser or see the example application running here.

In early 2000 I wrote an article for Sky & Telescope (S&T) magazine’s astronomical computation column entitled Scripting: a programming alternative which proposed JavaScript as a suitable alternative to BASIC for astronomical computation, long used by S&T and others to disseminate programs. Even at that time, JavaScript was arguably the only programming language interpreter available on almost every personal computer, by virtue of the ubiquity of web browsers.

In essence, JavaScript had become the equivalent of the BASIC interpreter every old personal computer (formerly called microcomputers, especially in the 80s) once had. I made the example programs from the article available and experimented further; some examples show the original BASIC listing along with the JavaScript implementation.

A variant of the ideas that led to ACEjs are revealed in what I said on this page:

Peter Girard has suggested the creation of an ECMAScript code library for astronomical algorithms.

An idea I’ve had is to write a BASIC (which dialect: GWBASIC, QBasic, etc?) to ECMAScript translator, written in ECMAScript or Java. One could paste BASIC code into a text area on a web page, and have ECMAScript and HTML code generated on the fly. This would make the BASIC code on Sky & Telescope‘s web site available as interactive programs. Or, it could generate a listing, making Peter Girard’s idea of a code library easier to achieve.

Of course, there are now plenty of examples of BASIC interpreters written in JavaScript, e.g. here’s a QBasic implementation that generates bytecode and uses canvas. Then again, as I have noted, my aim was not to slavishly recreate the exact look & feel of the original platform.

S&T showed some initial interest in JavaScript, again in 2005 regarding an orbit viewer page I wrote that combined JavaScript, a Java applet and cross-domain AJAX while Internet Explorer allowed it, and before CORS was a thing.

Of course since then and for all kinds of reasons, JavaScript has come to dominate rich client browser applications, especially after the introduction of AJAX, and has generally become the assembly language of the web. More recently we’ve seen the rise of Node.js, an explosion of JavaScript web frameworks (Angular, React, …), and mobile JavaScript development frameworks like Apache Cordova. JavaScript has good points and bad along with detractors aplenty, but it’s hard to argue with its success.

History has shown that a programming language does not have to be perfect to succeed. I love C, but it’s far from perfect and holes in its type system allow one to, as the saying goes, “shoot one’s foot off”. Additionally, these same holes are responsible for security vulnerabilities in the operating systems we rely upon. Notice, I’m not saying that C itself is responsible (it’s not a person or a company) for exploits of those vulnerabilities; that’s attributable to the moral barrenness of the people involved. It’s unlikely that we’ll see the sum total of mainstream OS-land rewritten in safer languages (Rust, Haskell, …), to save us from ourselves, anytime soon.

But I digress…

I could repurpose ACE to generate JavaScript, but we are living in a time of “programming language plenty”. Creating a new language today should be considered a last resort. Domain Specific Languages, sure. Libraries and frameworks, perhaps. New languages? Looking at what’s available first before reinventing the wheel should be considered a responsibility. Also, a language is no longer enough by itself. You need an ecosystem of tools (IDE, debugger at least) and libraries for anyone to care enough to want to use your shiny new language beyond very simple programs. ACE had a couple of IDEs but no debugger. Heck, I didn’t even use a debugger when writing the compiler! Now I seem to live in source level debuggers. I’m obviously getting soft. 🙂

When I was a junior academic in the computing department at UTAS in the mid-90s, upon learning about my development of ACE, a senior and sometimes less-than-tactful colleague remarked that creating a new language was, as he so delicately put it, “a wank”. I disagreed. ACE was about providing the power of a compiled language for a particular platform (Amiga) to people who knew an interpreted language (AmigaBASIC), wanted to leverage that experience and existing code and didn’t feel confident enough to learn the dominant systems-level language of the time (C). It was also about improving the precursor language.

Now, I would agree that the decision to create a new programming language or library requires some circumspection, at the very least. But the programming language landscape has expanded a lot since the mid-90s. There is of course value in writing an interpreter or compiler, just for the learning as an end in itself and every computer science or software engineering student should do so.

So, in the end: why ACEjs?

In part because I wanted to explore simple ways to write or port a certain class of application (e.g. old ACE programs) to client-side web applications.

Partly out of a sense of nostalgia.

In part because I want to learn more JavaScript, Canvas, jQuery and jQuery-ui and the subtle differences between JavaScript versions.

Mostly, I wanted to get a bundle of ideas out of my system, which I’ve more or less done.

ACEjs is a simple starting point and if it’s useful to me, I’ll continue to improve it; if not, it will happily fade away. So far, I’ve tested it using Chrome version 56 and Safari version 9 and ECMAScript (the underlying JavaScript standard) 5 and 6.

Finally, look in the About box of the example application for a small dedication, also present in the even simpler About box of ifs.b; my wife spent far too long listening to me talk about programming languages and compilers in the 90s. Now the talk is more likely to be about variable stars. Thanks Karen. We both like ferns as well, IFS generated or natural. 🙂

In any case, enjoy. Feedback welcome.

The Arrival, linguistic determinism, and programming languages

January 1, 2017

My son and I recently saw The Arrival, a movie that at first reminded me of Arthur C. Clarke’s Childhood’s End. The trailer suggested more action than was delivered, not a bad thing; the impact was primarily psychological.

Spacecraft arrive in several locations, hovering just above the ground. As you might guess, each country’s military forces quickly take control. The focus is on the US contingent (of course), although Australia, China and other countries are initially in frequent communication to collectively figure out what’s going on.

A sliding “door” periodically opens in the underside of each craft and personnel enter to try to make contact. Artificial gravity inside the atrium in which the humans stand makes things a little easier. A mostly opaque rectangular window separates them from the aliens and their atmosphere. The military personnel quickly realise that they need outside help so they enlist a linguist and a physicist. Apparently only America has competent linguists and physicists. 🙂

1

I won’t say more about the plot because I want to focus on one aspect and head off on a tangent. After a lot of puzzling by the main protagonists over the strange circle-based language in which the aliens try to communicate, the linguist eventually understands, with the help of a close encounter, why they have come. Nothing sinister as it turns out.

Along the way, the linguist talks to her physicist colleague and friend about the now somewhat outmoded Whorf-Sapir hypothesis (or just Whorfianism) of language or in which the structure of language is thought to affect the world view or cognition of its speakers. The weak form of this, linguistic relativity, says that a language merely influences thought, whereas the strong form, known as linguistic determinism, suggests that language determines what can be thought.

As the philosopher Ludwig Wittgenstein put it in his Tractatus Logico Philosophicus:

The limits of my language mean the limits of my world.

and

About what one cannot speak, one must remain silent.

The Arrival adds an interesting twist to this by allowing the linguist, who understands and internalises the alien language, to experience the world in a way that is, shall we say: temporally flexible.

The tangent has almost arrived; just a couple more paragraphs… 🙂

There is research suggesting that languages with names for particular colour shades make it easier for its speakers to remember those shades. This is an example of the weak form. However, we know that it is possible to perceive and describe shades, even if we have no explicit names for them, evidence against the strong form of the hypothesis.

Another example of the weak form would seem to be the fact that the Greek language has a different words for love: for God, friendship, the love of a parent for a child, and love between intimate partners.

I have not researched this enough to know whether there really are plausibly deterministic examples in natural languages, but I’d be interested in seeing some.

EDIT: It occurred to me today that I had heard of and recently read (here) about a culture whose language has only the number words one and two with many being the catch-all for other quantities. This most definitely places constraints upon the worldview of its people. In particular: the ability to count to specific numbers beyond two. It may be that in such a culture, this is all that’s required for enumeration in daily life, but it’s difficult to argue that growth is not limited by this, in particular: the discovery and use of mathematics. This is an example of linguistic determinism in natural languages.

Now finally, the tangent…

This all got me thinking about linguistic relativism and determinism in programming languages. To what extent does a programming language influence or determine what a programmer can think or limit his/her world view?

Whereas a language like assembly, C or C++ gives complete access to the hardware of a computer, Virtual Machine based languages like Java don’t, so too for explicit memory de-allocation vs garbage collection and other “unsafe” operations.

For example, not being able to express the thought in code: “write 42 to memory address 673416” limits what can be thought (programmed) in that language, an example of the strong form, so linguistic determinism.

There are of course many applications for which it is completely unnecessary (and dangerous) to be able to express such thoughts, so type systems that rule out whole classes of dangerous “code thoughts”, do us a great service, but at the cost of limiting our world and forcing us to be silent about certain things, as Wittgenstein might say, and possibly but not necessarily at the cost of performance.

Similarly, a language with even simple intrinsic data structures such as lists and maps permits more complex code with less effort. So long as suitable language constructs exist, i.e. pointers and dynamic memory allocation, such data structures (and algorithms to operate over them) can be created by the programmer, albeit at a greater cost and cognitive effort, and made available as libraries for use by others. Here we are closer to linguistic relativity I think. It was not uncommon to find myself, especially in the 90s, writing custom list data structures and search or sort algorithms from scratch when coding in the C programming language.

Perhaps the strongest encounter I had with the idea of language-as-influencer-of-thought was when learning Perl 20 years ago while working for a dial-up era Internet provider. The combination of regular expressions, lists, and maps in particular provided new ways to think about text processing, beyond simple character-by-character or sub-string comparisons.

If you had asked me 15 years ago which languages I could “think fastest” in, I would have said Perl and Java. Before them, the answer would have been C. The Perl experience translated to similar scripting languages all of which have been only incrementally better or worse, including Python.

At University I had studied and taught programming paradigms,  written a couple of compilers (e.g. ACE), engaged in some language design; I spent a lot of time in the 90s and early 2000s on the latter two.

The impact of object-oriented languages like Java and C++ (in fact, embodying multiple paradigms) was longer-lasting than most, especially with respect to the design and maintenance of large code bases. In recent years I’ve had increasing sympathy with the functional programming paradigm and strongly statically typed languages that limit the set of “legal” programs (for my own good).

As I have said in a different post, all programming languages are crude approximations of some Platonic ideal of a coming together of minds, artificial and natural, and there are very few languages yet that make communion with the machine or, just as important, with other programmers, a beautiful experience.

The idea of a programming language that doesn’t just place limits on my world, but one that radically changes the way I think about the world, as the alien language did for the linguist in The Arrival, is alluring.

I remain in search of such a language (and its ecosystem of libraries and tools), one that of course can only ever be asymptotically approached.

Writing this has scratched an itch that has been irritating me for a long time. Perhaps I’ll have more to say about particular languages and how they live up to the “ideal” in future posts.

Update on novae in Sagittarius

December 11, 2016

It’s been a month since my last update on ASASSN-16ma and  TCP J18102829-2729590, mostly due to family commitments; my wife was out of town with her sick father, and looking after her mother, so I was busy keeping things going on the home front.

As can be seen below, both novae have been in decline for most of that time.

tcp-j18102829-2729590

asassn-16ma

ASASSN-16ma declining?

November 11, 2016

Poor weather prevented any observations last night but tonight the sky cleared after a late afternoon storm and I estimated the nova at magnitude 6.3.

asassn-16manov11

So, it’s been gradually declining for 3 days, but whether that continues remains to be seen.

ASASSN-16ma update

November 9, 2016

As mentioned in yesterday’s updated post (with finder chart), conditions last night were less than ideal, but when the clouds cleared enough, I estimated the nova’s magnitude at 6.1.

asassn-16manov10

 

ASASSN-16ma: easy binocular object

November 8, 2016

Last night’s observation of ASASSN-16ma was with 7×50 binoculars rather than my Meade LX-90 8″ SCT. The nova is now on the verge of naked eye visibility!

asassn-16ma

I estimated the nova at magnitude 5.5 last night with one before mine at 5.4 and two subsequent observations of 5.8 and another at 5.9. Mine are highlighted in purple as usual.

Here’s the section of Sagittarius of interest as it currently appears from Adelaide, low in the south-western sky at around 9pm:

sgr

The nova is just west of the circled star HIP 90012, the 6.2 (labeled 62) magnitude star near the middle of this AAVSO finder chart:

x16923acn

If you rotate this chart 90 degrees to the right, it will have roughly the same orientation as the Stellarium sky scene.

Alnasl is the star labeled 30 (magnitude 3.0) at bottom right of the finder chart. Kaus Media corresponds to the label 27 and Kaus Borealis with the star labeled 28. Kaus Australis and Φ Sagittarii do not appear on the finder chart, but would be off to the left of the unrotated chart.

As I write this, the sky here in Adelaide is quite overcast, so there may be no observation from me tonight.

 

Update on two novae in Sagittarius

November 7, 2016

Poor weather then being away for work for three days last week has kept me away from variable star observing since October 29. Last night (November 6) I observed TCP J18102829-2729590 and ASASSN-16ma again.

While the first is on the decline currently (around magnitude 9):

tcp-j18102829-2729590-lc-nov-7

On the other hand, I caught ASASSN-16ma on the rise. My October 29 observation gave a visual magnitude of 10.3 whereas last night it was 7.3. Several hours later others were recording it at around 6.5:

asassn-16manov-7

So, ASASSN-16ma has exceeded TCP J18102829-2729590’s maximum (so far) by around one magnitude. If this rate of increase continues, who knows, maybe it will reach naked eye visibility. Here’s hoping!

 

TCP J18102829-2729590’s undulations

October 29, 2016

My visual estimate of nova TCP J18102829-2729590 last night was magnitude 8.0 using my trusty Meade LX-90 at 82x magnification. In my light-polluted corner of suburban Adelaide, 7×50 binoculars just aren’t good enough for this.

The third observation from right, three days ago, showed an apparent rapid increase in brightness. For me, one of the attractions of novae is their less than predictable nature.

Looking at the light curve today, my observations look a bit like (purple) buoys bobbing up and down on the surface of an undulating ocean.

tcp-j18102829-2729590-lc-oct-29

Maybe I’m spending too much time looking at novae at the moment. My wife would probably agree with you, even though she’s very understanding. 🙂

ASASSN-16ma = PNV J18205200-282210

October 29, 2016

ASASSN-16ma, the nova candidate in Sagittarius, has been designated PNV J18205200-282210 by IAU CBAT as per today’s AAVSO alert notice.

I made another visual estimate of the nova again last night at magnitude 10.3.

asassn-16ktlcsep29