R109

See R107 — R110: Constellations and asterisms.

R108

See R107 — R110: Constellations and asterisms.

R107

See R107 — R110: Constellations and asterisms.

R102 — R106: Docs and DB

Log of changes since last report:

• R102 (Jan 30, 2011): minor restructurings inspired by the program loading experiments previous early winter,
• R103 (Jan 30, 2011): more of the same,
• R104 (Feb 5, 2011): added my hand copied version of Tabulae Rudolphinae on a whim, probably the only one in database format on the entire web,
• R105 (Feb 5, 2011): doc cleanup,
• R106 (Feb 6, 2011): major rehaul to prepare for a novel database model (ADBMS) and to allow the struct program_state to be pushed/poped as procedure enviroments, added data and code for constellation lines.

R104 and R105

See R102 — R106: Docs and DB.

R102 and R103

See R102 — R106: Docs and DB.

Ada and UTF-8 literals

To my delighted astonishment, I found the following code quite legal in Ada05:

pragma Wide_Character_Encoding(UTF8);
with Ada.Text_IO, Ada.Integer_Text_IO;
procedure Read_Write_Loop is
    use Ada.Text_IO, Ada.Integer_Text_IO;
    β : String(1..40);
    N : Integer;
begin
    Put("> ");
    loop
        Get_Line(β,N);
    exit when β(1..N) = "quit";
        Put("Command: '" & β(1..N) & "'");
        Put(" ("); Put(β'Length,2); Put_Line(")");
        Put("> ");
    end loop;
    Put_Line("Bye");
end;

"Ridiculous", the most programmers use to say, one can write beta in Java/C# (which by the way is the most phantastiqual language ever constructed by the most intelligent godlike gurus, yada yada yada ...). Very nice when encoding mathematical formulae in Ada.

The above code works in GNAT if the data is stored in a file read_write_loop.adb and compiled with

gnat make read_write_loop

Other perceived advantages of using Ada for numeric parts of the sternons project are:

1. Ada is available wherever gcc is
2. The Ada programmer have a detailed control over data precision f.ex. being able to declare long reals by type My_Float is digits 12;

R101: License change

R101: just a license change in the code from GNU LGPL to GNU GPL. The reason was easier code pilfering from other projects, of which the vast majority is GPL. Now, Microsoft's CEO Steve Ballmer also consider my code "a cancer", which is maybe honorable coming from him, and "viral" according to Craig Mundie, also Microsoft. Microsoft is nice, nice doggie, do not bark on bearded men with turban!

R100 (new year revision)

R100 occured after some time of vacation from the project. My dive into program parsing made me get some intuitive plan in my head for in what direction the project is going to be developed, but I believe the mkmap program syntax needs some heavy revision after I've rehacked the main non-program-parsing code in accord with my vague intuitions. That's the life with theory and praxis: back and forth, nilly-willy over the border of the true and the functioning.

Semi-dead project

The project was semi-dead for about one and a half month, due to so called ordinary life. So called ordinary life irritates us, but the project was only semi-dead, which automatically implies zombielike. The revisions r98 and r99 where ueber-silently released, both of them designing some data structures to be constructed after the parsing of the map program. The program parse_program parses the program and constructs a program prototype. Nevertheless I'm considering yet another program redesign, that makes some assumption on the so called graphical layers: given a "fixed" sky layer (or for that part a "fixed" globe layer on any planet), there could be a conceptually different viewing window layer that applies filters on any fixed surface layer,

1. a selection, for example stars brighter than 5.5, galaxies brighter than 9.5,
2. a projection, for example lambert conic, simple conic, cylindric
3. an orientation, centering α₀, α₁, δ₀, δ₁, image rotation ν and some such...

Sexagesimal handling – R97

At last some real programming (again), although frustratingly slow (revision 97). In general I wish everything accomplished immediatelly!! I enabled some correct sexagesimal constant scanning allowing mkmap map programs to specify float constants as sexagesimals, f.ex.:

• 23ʰ12ᵐ03.14ˢ (a right ascension)
• 23ʰ12.17ᵐ (another)
• 48°34'16.07" (a declination without a sign)
• 33° (another)

The acceptable sequence of the sexagesimal markers are ʰᵐˢ, ʰᵐ, ʰ, °'", °' and °. All other sexagesimal marker sequences within a floating point literal constant are illegal. The code is also prepared for hexadecimal and octal constants, but correct scanning of those are not yet implemented.

CAVEAT 1: The scanner doesn't create a floating point value from the scanned token – that's up to the parser. A token "method" for creating a floating point value is to be added in the future.

CAVEAT 2: The scanner is not screaming (fprintf stderr) from the occurrence of erroneous sexagesimal tokens, the screaming philosophy is not yet determined.

Revision documentation

Added clarifying revision documentation from R1 to R51 and some general comments from R86 to the current R97. The point is that I'm successively learning some complex options of svn and the facilities (and lack thereof) of googlecode. The following pretty complex svn command generates a diff overview:

# svn diff --diff-cmd /usr/bin/diff -x '--brief'

In "the best of worlds" the syntax would instead have been

# svn diff --brief

or

# svn diff -B

Project mgmt on google code?

Q: Project mgmt on google code?
A: Not likely!

Actually, I examined the facilities on google code a while ago, added a few issues and deleted them again as experimental evaluations. My immediate reaction was that I could find no life cycle stages of a certain module – a module could attain any of the following intellectual stages:

• vapor: imagined, probably needed or possibly not, no implementation nor any evaluation supporting nor opposing the creation of the module,
• rejected: the module development is stopped at any of the pre-gamma stages, and stowed away for trackability and a possible future reevaluation, ¹)
• evaluated vapor: text, design and evaluations describing and underbuilding the creation of a module
• experimental: a code that implements some important aspect of a module, used for demonstration for further evaluation and a code base for the future module
• alpha: the module is implemented but unstable,
• beta: the module is pretty stable, but not systematically bug-tested
• gamma: stable and systematically bug-tested
• gamma-old: gamma but considered for replacement: replacement documentation exists
• delta: actively being replaced

These life cycle states are 'home hack' adapted, a test-based development enviroment should have a different set of stages: fulfilling this or that many test cases.

Whether google code usage can be adapted to an arbitrary life cycle management of individual modules is as yet undecided, but it is an infinitely important question for any opensource project.

1)

Extreme programmers and other modern project management use to dislike stowing away things for later reevaluation, but this is just an oversensitivity and disability to evaluate and correct oneself from own thought errors. The key points that makes stowing away problematic is keeping a database and any system of competition-by-blame.

R91 (R92, R93): one huge jump

Pretty abstinential from the last weeks administrative low effective time consuming tasks of mine (current Swedish ineffective unemployment system), followed by quite logical and notable failures, my programming/construction deficit resulted in me boldly splitting off all scanning/parsing functions to the separate modules parse.[ch], in order to experiment freely with the parsing. Intending to program as intensely as possible to make a programming system for map generation (see prev post), the revision R91 differs very much from R90. Foremost two files that were embarassingly missing, token.[ch] were finally added. Checking out the source without those two files wouldn't have worked! :-( Stupid and sloppy of me. Also the reworked syntax is in maps/ori-mon.mkm, which was however forgotten in R91 but came in R92 (also see prev post). The test program parse_program.c was created for testing the new parsing language. When mature it shall also generate and test-print a data structure constituting the map language program loaded.

Some history examination of the repository revealed that I renamed scan.[ch] in the code while not doing it properly in svn. So while a smart programmer might have been able to deal with the missing code by reading and analyzing, some intermediate versions of scan/token.[ch] are missing. Fixed now – I think.

A sample program

The following code is very preliminary, but exhibits the principle of map creation, that I've chosen. The stream system that I spoke of previously is not the primary way to organize the drawing of images. Instead a human map drawer reasons with various layers and objects to draw in those layers. The layers have an order: the first drawn first, then next one – possibly overwriting features in the previous layers – and so on till all layers are drawn. In map making most objects are coordinate transformed zero times or more, and finally the object is projected onto a flat surface, i.e. "the paper". When a label is attached to an object, (f.ex. the string "Sirius" to the star Sirius) it is not transformed/projected quite the same way: a label should be placed near the object that it labels, but "upright" from the perspective of the image spectator, so that the spectator needn't put the head on one side: the label has to take the paper position of the object and add a little offset so as to be written near but not on the object it refers to.

The programming system, and the code below, is not finally defined: it needs some fixes to become logical, and to reflect the stream system that I've speculated about earlier, but at last I got an idea of how to code maps in a generic way. The long term intention is of course not just star maps, but any map. The details of how to store databases in files and how they're loaded and processed is of course a remaining topic: I'm inclined towards relation algebras rather than the clumsy SQL thinking, but this is a matter of syntax, not semantics, since a well designed relation algebra should be mapable to SQL statements.

orion() {
    ## procedure for the heavenly hunter 
    border    += load “ori_b.db”;
    labels    += [pos: [x: middle, y: bottom], 
                  string: "Orion",
                  justify: middle];
    projection [type: Lambert_conic, α: 5ʰ20ᵐ, δ: 10°, Δδ: 10°];
    frame [height: 500px, width: 500px];
}
monoceros() {
    ## procedure for the heavenly unicorn
    border    += load "mon_b.db";
    labels    += [pos: [x: middle, y: bottom], 
                  string: "Monoceros",
                  justify: middle];
    projection [type: Lambert_conic, α: 7ʰ10ᵐ, δ: 10°, Δδ: 10°];
    frame [height: 500px, width: 600px];
}
main() {
    
    ## ‘layer’ declares the layers wherein the program puts
    ## objects, when executing an ‘out’ all layers are drawn
    ## with stored objects one by one, background first, then
    ## border, aso. to at last map_labels. What layers that
    ## are to be used, is up to the programmer and the naming 
    ## is free by programmer choice:

    layer background(noproj); # background: no projections, 
                              #             just one frame
    layer border;             # border:     given in αδ* as
                              #             a loop → coorsys
                              #             change, projection,
                              #             frame
    layer grid;               # grid:       given in αδ* as
                              #             lines → coorsys 
                              #             change, projection, 
                              #             frame
    layer nebulae;            # nebulae:    given in αδ → 
                              #             coorsys change, 
                              #             projection, frame
    layer stars;              # stars:      given in αδ →
                              #             coorsys change, 
                              #             projection, frame
    layer labels(noproj);     # labels:     given in αδ →
                              #             x₀y₀ + xy offset ???
                              #             (MANUALLY!)


    background += infinite [color: [r: x00, g: x00, b: x40]];
    grid       += grid [α: 1ʰ, δ: 10°];
    stars      += load "stars.db";
    labels     += align stars "stardesg.db";
    nebulae    += load "nebulae.db";
    labels     += align nebulae "nebdesg.db";
    { # a stacklike block for loading local data
        orion; # run procedure ‘orion’
        out "orion.svg";
    }
    {
        monoceros; # run procedure ‘monoceros’
        out "monoceros.svg";
    }
}

Further notes on the layers: layer border is for constellation borders, layer labels is for star and galaxy labels, and are intended for manually copying positions from the star and galaxy layers, then adding an offset to place the star and galaxy labels at proper positions: not colliding with each other, not overlapping the labelled object.

n-body links

Added links to n-body solution information on algorithms and formulae part of astro and s/w links.

wstring vs. ustring – part II

Wstring vs. ustring fixed in rev90.

wstring vs. ustring

The problem with Windows cygwin gcc using 16 bits' strings instead of the hard coded 32 that I use is solved in the only way possible within C.

The problem is about the following: I rely on wide characters being signed, irrespective of what the local C implementation uses for wide characters. As a means to (in future) allow Unicode upper plane code points¹) I also implement wide characters with signed integers (assuming them to use 4 byte). The normal wcs string functions – f.ex. the comparison wcscmp instead of strcmp for old narrow characters – varies according to implementation, so I provide my own counterparts in ucstr.h. They're not complete, but they work for my purposes, including others that aren't on the web.

Fine, so far – but since cygwin use 16 bits internally for wide chars, the wide string literals, f.ex. L"ψ⁶ Aur" ²) won't work for my personal 32 bits wide chars. Therefore I have to replace them with uchar array declarations like

   uchar _L_psi_e6_Aur[] = {L'ψ',L'⁶',L' ',L'A',L'u',L'r',0}.

and replacing all occurrences of L"ψ⁶ Aur" with _L_psi_e6_Aur. It's not beautiful, but it's the only way to make the code portable.

---

1)	ponder f.ex. using a Mesopotamian Cuneiform glyph here, which is realistic, since there was Cuneiform star catalogues, f.ex. MUL.APIN, then such a Cuneiform glyph is implemented in plane 1 of Unicode, which needs 21 bits, which is so odd that 32 bits is provided by integer is the best match,
2)	a star in the eastern Auriga, formerly Telescopium Herscheli

---

A crucial question: why not use another programming language than C. Yes, why not, but the languages not to use for this kind of application are Java and C# (and all .NET languages), because they require loading of a heavy virtual machine that are not used for the conversion process. Other not-to-use-for-this languages are JavaScript and PHP, because of their web oriented implementations. Relevant languages are Python and C++. The current implementation will stick to C because of lib spinoffs that can be used in implementation of programming language experiments of mine – C++ won't do for parallel programming – until a full set of star maps can be generated: nothing is impossible in C, but many solutions require ugly-like-h*ck code.

Streaming theory – r87

Revision 87 just adds a few notes on the streaming theory I'm pondering to implement. The principle is creating stream filters and cascading star data in pipes of one stream filter after another. The theory should be analogous to the pipe streams of Unix, except the filters are not normally written in a Unix shell, even thought that is possible. Instead of using PP3:s simple state setup and having a fixed few steps cascade (1. set "parameters", i.e. any generation constants, 2. delete and add objects, 3. "compute and draw"), the filters and the pipe streams shall be configurable in the intended programming language of mkmap.

Star name raid

I did a star name raid in Wikipedia yesterday, removing fake star names such as "Biceps" for γ Her, or "Melqart, Melkarth" for μ Her.