22:56: libvisualid 0.2 released

Version 0.2 of my `applied mathematics and primitive art' project, libvisualid, is out.

There's some new functionality, and a new toy included, but the biggest change is that the internals have been completely refactored to use GObject.

Restructuring everything around GObject has actually been really helpful in clearing up some points of confusion that I encountered during the initial implementation--now those semantic bugs have been squashed.

Now that the big pieces of new architecture are in place, I can start shedding the old (and less usable) interfaces, I can start developing the finer points in the new interface, and I can start evolving the actual functionality to include things like:

• A glyph-mutator system that can automatically derive new glyphs from existing glyphs (I have a weighted Levenshtein algorithm on which I've been working).
• New glyph-types (Pam wants butterflies...).
• More dimensions to the system (colour should be fun).
• Tools that end users can use to provide feedback to the system and tune its operation.
• A portable, stable, and re-entrant PRNG (glib provides the base for this).
• etc.

(look for that stuff to start showing up in 0.3)

The existing patches for Nautilus still work, for anyone who's using them (or who hasn't tried them but would like to).

[From the NEWS file included in the tarball]

Version 0.2.0 is a significant revision of libvisualid, though the
user-interface of the `mkvisualid' command remains mostly unaltered;
visible changes include:

    * A new "--base-weight" option has been added, to set the default
      weight for generators in the probability-set; it's possible to
      disable all generators with "--base-weight=0" and then easily
      enable only specific generators.
    * A new "--autocache-dir" option has been added, allowing the
      glyph-cache directory to be specified.
    * The "--autocache" and "--output" options can now be used
      simultaneously (in the future, the `autocache' files will be in
      a different format capable of storing glyph-structures with all
      attribute-data intact, instead of just storing renditions).
    * If the path specified via the "--output" option exists and is a
      directory, then a file is created in that directory with a name
      according to the input name.

A new `VisualID Explorer' demo-application has been added, using GTK+ with
several alternate GUIs defined using Glade.


The libvisualid library contains several new features, including:

    * visualid_complexity(), a function providing overall
      complexity-metrics for VisualID glyphs.
    * visualid_set_cachedir(), a function that allows the global
      cache-directory to be changed.
    * Automatic limiting of overall glyph-complexity: an integer in
      constants.c (complexity_max) controls the maximum
      glyph-complexity, having a default value of 5000 (a measure of
      something akin to `number of brushstrokes').
    * As the result of everything having been refactored using GObject
      (cf. details below), we finally have a way to *deallocate*
      VisualID glyph-structures!
    * Some bugfixes.


This release of the libvisualid library is binary-incompatible from
all previous releases, and is source-incompatible in a few minor ways:

    * exec_generator() has been renamed to visualid_draw_path().
    * generate_child() has been split into two special-purpose functions:
        - visualid_glyph_new(), for producing root glyphs,
        - visualid_glyph_spawn(), for producing and assigning
          subordinate glyphs.
    * All of the class-specific generator-functions have been reworked
      to have the same parameters as visualid_glyph_spawn().

Aside from the above changes, libvisualid should be source-compatible
in every meaningful way.

The `generator' structs have been converted into GObject classes,
including a base `VisualID_Glyph' class; the existing structs have
been preserved for the time being, but this marks the beginning of
API-redesign whereby terminology will be corrected and the API will be
reformed into something more fit for general consumption (e.g.: public
names put into a namespace).

The naming of the structs in 0.1.x as `*_generator' was somewhat
inappropriate, and due to some misinterpretation of some ambiguous
text in the essay: while the `*_generator' structs /are/ data
/related/ to generators, the `gen_*' function itself (not the data
that it produces) /is/ the generator. The term, "glyph", has been
chosen for the base-class in the VisualIDs `shape grammar' by analogy
with written-language grammar where `glyphs' of typography are
realisations of abstract `characters'; the `characters' of the
shape-grammar would then be the classes per se: `radial', `spiral',
`figure', `line', etc.

[Reply]

23:56: Pretty Baby-names

I just came up with a new way for choosing baby-names:

cat /usr/share/dict/words | xargs -i mkvisualid --output={}.svg {}

... and then just pick one that looks nice.

It gives a whole new meaning to the idea of "a pretty name".

[Reply]

22:24: Inspiring Minds... want to know?

I just sent this to some teacher-friends of mine:

Joshua Judson Rosen <rozzin@geekspace.com> writes:

Kim writes:

Joshua Judson Rosen <rozzin@geekspace.com> writes:

I thought you all might get a kick out of a project on which I've been working for a while: basically, it's an exercise in applied mathematics and primitive-art principles.

I've been keeping a weblog for it:

http://www.twisted-muse.org/~rozzin/weblog/VisualIDs?limit=0

Is this a private viewing? I'd love to share it with a couple folks - one of the teachers I work with, in particular. She has a dual degree in physics and studio art and is helping me "prove" that there are other ways to learn math than textbooks!

No, not private at all--actually, since it's a Free/OpenSource Software project, the more people see it the more chance it should have of attracting contributions and actually being successful.

I did hold off on actually publishing the /code/ for a while, because there was a certain minimum quality that I wanted to attain before I let it out into the world (like raising children, I guess, in so many ways). But now it's public--so, by all means, share away :)

And, actually..., part of the reason that I wanted to share this with you, Amy, Bill, and the other educators /is/ that I hope that maybe it can give you guys something new to work with in trying to get kids interested in both mathematics and art-history--both the math and the art can be taken pretty far/deep in something like this, but, at same time, it's amazing how /basic/ the understanding necessary to get started on a project like this is; and the very premise of the project is, in some respect, that the beauty of mathematics and the deep insight of art should be accessible to everyone--even, hopefully, a taste of the `daily "aha!"' experience that helps to make both mathematics and art so lovable for their practitioners.

It's all the same sort of stuff that I was espousing when I was a student at SHS a decade ago, I guess :)

On that note, my old Senior Project stuff is still up on my website, if you want to show that to your physics-math-art friend:

http://www.twisted-muse.org/~rozzin/senior-project

Also, I just came across Paul Lockhardt's "A Mathematician's Lament" the other day, by way of this blog-post:

http://scottaaronson.com/blog/?p=410

It's [yet another] interesting essay that addresses the problems with mathematics-education. His initial statement (after some illustrative contra-scenery):

Sadly, our present system of mathematics education is precisely this kind of nightmare. In fact, if I had to design a mechanism for the express purpose of destroying a child’s natural curiosity and love of pattern-making, I couldn’t possibly do as good a job as is currently being done— I simply wouldn’t have the imagination to come up with the kind of senseless, soul- crushing ideas that constitute contemporary mathematics education.

Everyone knows that something is wrong. The politicians say, “we need higher standards.” The schools say, “we need more money and equipment.” Educators say one thing, and teachers say another. They are all wrong. The only people who understand what is going on are the ones most often blamed and least often heard: the students. They say, “math class is stupid and boring,” and they are right.

Mathematics and Culture

The first thing to understand is that mathematics is an art. The difference between math and the other arts, such as music and painting, is that our culture does not recognize it as such.

High school still seems, to me..., like a particulary great opportunity to reach out to growing people in a pivotal moment of their lives and either nurture them as they grow roots and blossoms or just save them from becoming disillusioned as the enchantment really starts flaking off.

I'm still hopelessly romantic about things :)

[Reply]

22:09: Mediaeval Icelandic VisualIDs!?

It looks like my opinion on the `meta-primitive art' of VisualIDs is vindicated by actual, direct evidence--JP mentioned, in a recent e-mail:

By chance I came across these images tonight, in the 'comprehensive latex symbols guide'.
Interesting...

Look familiar?

The Museum of Icelandic Sorcery & Witchcraft website (referenced in the URL at the bottom of the second image) says:

All of the signs and staves seen here can be found in Icelandic grimoires, some from the 17th century, some from later times though all of them seem to be related. The origin of this peculiar Icelandic magic is difficult to ascertain. Some signs seem to be derived from medieval mysticism and renaissance occultism, while others show some relation to runic culture....

... and includes numerous example-glyphs with explanations.

[Reply]

02:17: An Exercise in Applied Mathematics and Primitive Art

One of the things that really struck me about VisualIDs was something that wasn't even discussed in the original essay--something that even seemed to be conspicuously missing after actually working with VisualIDs for even a brief period: there is ever-so-subtle a mention of the `radial' generator, for example, as having `children that could be interpreted as eyes and a mouth', but there was no mention of just how supportive of that `possibility' the visual details end up being--how cleverly (how artfully) they play on the human tendency to see familiar meanings in familiar forms, even when there's really nothing there.

Not only do we see `eyes' and a `mouth' inside a Radial glyph invented by the machine, but the `angle-limited edge-children' (using the terms of the shape-language) even appear as `a hairdo' and, when applied recursively in drawing the inner sub-glyphs, Radial's the edge-glyphs often appear to give the `eyes' eyelashes and to give teeth or a `mustache' to a mouth.

When Radial and Line combine to form Figure, they resultant glyphs are strongly suggestive of `animals' and `people'.

These were, I think, the first generators that I implemented, and there was quite a punch to it when it started working and, out of nowhere, the machine drew what I could have sworn was a turtle.

It's been really interesting to see what sorts of things are suggested by different Radial/Figure productions: some of the icons in my screenshots, I just can't resist calling things like "ninja", "lion", "turtle", "urchin", "tic-tac-toesoldier", "warrior", "spider"....

I do wonder what other people would call them. What I've encountered thus far is that, where I see Shapes as `amoebas', my wife sees them as `thought-bubbles'; a friend of mine remarked that `shaving.htm looks hairy', and my wife referenced one file as "the guy with the spiky hair".

These glyphs, which are formed by pseudo-randomly applying the shape-grammar, really and honestly don't have any inbuilt meaning, but it seems that they're so readily assigned meaning that we just can't help it (in the same way that it's nearly impossible to avoid the reading of words, seeing sculptures and canals on Mars, and becoming fraught with cognitive dissonance when we try to cite the colour of the next word: "green"), and that's just... fantastic.

Accompanying the original essay were also some stylisation options--merely alluded-to by way of example-imagery rather than being outright specified, the list of ideas included glyphs drawn purely with stark black-on-white lines, glyphs that had been colourised and embossed, and glyphs framed by a couple of different types of auxiliary `aqua blob' elements.

I have some ideas for how to implement some of the fancier styles, and even some stylistic ideas of my own (Cairo offers some interesting tools like transparency, gradients, clipping, and various options for stroking a path; coordinate-system transformations also apply when stroking a path--I've actually already had some success using that to render `calligraphically'), but I'm really not all that sure of their value: as neat as the `embossing' idea is, I think that I can appreciate it much more from a graphics-geek perspective than I can from an artistic one.

As an artist, I find the whole `vaguely-familiar line-drawing' thing to have excellent perceptual characteristics: it's just so easy for us to relate to it--on an even primal level. It's like... an evolution of cave-paintings. Cave-paintings for the digital age? Indeed. Meta-primitive art.

As such, the direction in which I'd like to move, as far as glyph-types goes, is toward additional impressionistic or primitive-art-style images mimicking a broader array of fanciful real-world object-types. My wife, for example, asked me:

"Can you make one that generates butterflies?"

In fact, under certain circumstances, certain generators do coalesce to produce semblances of `butterflies'..., but it would be nice to be able to tune the system such that `butterflies' could be a distinct feature rather than a rare and happy co-incidence. The definition of a specific `butterfly character' in the shape-grammar would also open-up some additional possibilities for obvious parameters: not adding too much detail (or, perhaps, too many details), because we want to preserve the `primitive art' aspects, but butterfly-wings do have certain universal tendencies that may not be properly captured solely by the use of a generalised system of polar-coordinate renderings of Fourier-series curves.

I can immediately imagine extending the visual language to include faces (Radial); people and animals (Figure); butterflies, dragonflies, and faeries; flowers and trees; snowflakes; etc. These should all be fairly straight-forward, since they can all be broken down into coarse geometric or trigonometric primitives with relative ease, and they seem like they should all be fairly successful with many audiences.

Myself, I do sort-of like a lot of the Spirals, and I wonder if part of their appeal is perhaps that they are, basically, sort-of vaguely-similar to flowers..., or maybe the appeal of spirals is just part my own idiopathy. These sorts of things can presumably be sorted-out empirically with sufficient number of testers.

Even forgoing the fancier render-styles for straight-up primitive-style line-drawing generators, I am somewhat interested in expanding the algorithms to include colour (including fills, background-vs.-foreground contrast...), and the addition of a Butterfly generator provide a perfect canvas for that. I do think, however, that one must be careful there: one should take care to avoid `colour' being the only distinguishing characteristics of things. I'm particularly sensitive to this because (is this evident from the graphics on my site?) I have colour-deficient vision, myself (`weak' red, shifted over toward green a little); luckily, I found a very good guide to colour vision and colour design, written from a UI-design/usability perspective:

http://www.firelily.com/opinions/color.html

Ultimately, it's almost certainly desirable to come up with ways of making the generated VisualID icons basically `fit in' with the rest of the user's desktop-theme, but that seems like a more bigger and more difficult task right now. Of course, I'd be glad to lend an ear to anyone else who's interested in pursuing that goal.

[Reply]