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.

PP3 images in SVG

The original PNG files produced from PP3 seems to be disused on English Wikipedia. One glorious guy named User:Kxx seems to have converted the images to SVG, he applies an unknown extra script or program to the TeX (?) code produced by PP3. The method is however undocumented – no deal – the maps should be replaced anyways.

Orion

I just observed that there was no sample on this blog, only on the Swedish language blog Haccationes. So here yet another sample for this blog. The constellation Orion, the upper one generated by mkmap (2010-09-01), the lower one the SVG version (PP3 generated) residing on Wikimedia Commons.

mkmap currently generates a map in the Lambert Conformal Conic Projection, which is very popular on orientation maps (especially military maps) covering a small area because an angle is the same as in reality, and a distance on the map is nearly the same scale irrespective of direction where measured. This is a pretty good quality for star maps too, unless a major part of the sky is to be depicted by the image.

The Wikimedia image, besides being more mature and differently colored, has one great disadvantage from mkmap: only the bright star constitute a realistic picture as seen in the night, and when observing fainter stars, one cannot recognize star patterns from that map. This is because the Wikimedia map doesn't draw stars with a radius according to the apparent magnitude, instead it first sorts the star into one of the magnitude categories -1, 0, 1, 2, 3, 4, 5 and possibly 6, then draws all stars with a certain magnitude with one radius only. So the Wikimedia map simply cannot be used for astronomical observations because the astronomer won't be able to recognize the star patterns in the sky based on that star map.

Revision 82 to 84

Preparations for stricter and error detecting parse: the token shall contain info about line number in source code where scanned, functions for strict token detection added in mkmap.c.