<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Dear Martin,<br>
<br>
Very nice result :)<br>
<br>
If I am correct the NESTED ordering uses a Z-order (or Morton)
curve (which rely on bit interleaving).<br>
It explains why computing a HEALPix index is very fast and does
not depends on the NORDER.<br>
Do you have the same kind of algorithm for the Peano-Hilbert?<br>
If yes, would you provide a pointer on it?<br>
The only ones I am aware of use recursion or a 'for' loop from 0
to NORDER...<br>
If not, what about performances when computing 100_000_000
Peano-Hilbert HEALPix indexes?<br>
<br>
If performances using Morton and Peano are similar it is (in
addition to MOCs) interesting to index data (in databases, ...)<br>
since Peano has "better locality-preserving behaviour" than Morton
(quoting Wikipedia but I heard/read this elsewhere),<br>
so needs less disk access, ...<br>
<br>
Even if it will not become a standard, I think it is worth having
it in the Java HEALPix libraries :)<br>
<br>
Best regards,<br>
<br>
François-Xavier<br>
<br>
<br>
Le 20/10/2014 12:37, Mark Taylor a écrit :<br>
</div>
<blockquote
cite="mid:alpine.LRH.2.11.1410201121260.32452@andromeda.star.bris.ac.uk"
type="cite">
<pre wrap="">Martin,
that's an interesting research result, and it might be useful for
improving efficiency in certain closed contexts. However, in my
opinion, it is not a good idea to proliferate format variants or
provide multiple options for exchanging data formats. So given that
MOC already declares NESTED as standard, I would not like to see
this alternative introduced into MOC I/O libraries in a way which
would lead to incompatible (or less-compatible) MOC instances
being generated routinely, e.g. from data services.
>From a VO perspective, that is in the context of a range of
heterogeneous data providers and consumers, providing/acquiring
data in forms that can be understood and worked with easily
(e.g. without having to worry about format variants) is a more
difficult and important goal than ensuring maximal computational
efficiency. Usage of such data in any case tends to be I/O rather
than compute bound.
That's my 2p - others may disagree.
Mark
On Mon, 20 Oct 2014, Martin Reinecke wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi again,
I did some further experiments with the HEALPix MOC implementation and
noticed that the MOC sizes (i.e. the number of pixel intervals in a MOC)
can be reduced by roughly 20% on average if one uses a
Peano-Hilbert-ordering of the pixels on the sphere instead of the more
conventional NEST ordering.
Support for this kind of ordering has been in the HEALPix C++ package
for many years now, and porting it to the Java package was a matter of
half an hour.
Would there be interest in such a kind of MOC?
Once generated, the MOC objects would behave in exactly the same way as
the currently used MOCs in NEST scheme, they would just be smaller and
operations on them would be faster.
Conversion between MOCs in Peano and NESTED representations is possible,
but fairly slow.
Regards,
Martin
On 10/15/14 14:16, Martin Reinecke wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
I was encouraged by Pierre Fernique to send this announcement to the
IVOA apps mailing list, since there might be broader interest ...
After the MOC standard document had been accepted, I started working on
native MOC support in the Java HEALPix package.
My aim was to provide a compact and highly efficient implementation of
the central functionality (MOC construction, input/output and set
operations). Here is a fairly complete list of the current capabilities:
- import/export from/to FITS (both files and streams are supported)
- import/export from/to strings (both the basic ASCII and JSON syntax
shown in the MOC standard)
- import/export from/to a highly compressed bitstream representation,
making use of interpolative coding. These objects are significantly
smaller than the FITS and ASCII representations, and can be read/written
very quickly; they could be useful on a VO server dealing with many MOCs
at the same time.
- import/export from/to RangeSets of UNIQ pixels
- set operations (union, intersection, subtraction, overlap test, subset
test, complement) that are even faster than what was available so far,
due to improvements in the RangeSet class.
- resolution degradation of a MOC to a desired Healpix order. Partially
covered pixels can be kept or discarded, depending on a parameter.
If you are interested, I have attached a source tarball of the current
Java HEALPix package. The most up-to-date version can always be found in
the subversion repository at <a class="moz-txt-link-freetext" href="http://sourceforge.net/projects/healpix">http://sourceforge.net/projects/healpix</a>
Please let me know if you think that essential functionality is still
missing!
Concerning class and function names, I'm still considering various
alternatives to make them as unambiguous as possible. Again, if you have
suggestions in that area, please tell me.
Best regards,
Martin Reinecke
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
<a class="moz-txt-link-abbreviated" href="mailto:m.b.taylor@bris.ac.uk">m.b.taylor@bris.ac.uk</a> +44-117-9288776 <a class="moz-txt-link-freetext" href="http://www.star.bris.ac.uk/~mbt/">http://www.star.bris.ac.uk/~mbt/</a>
</pre>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<table style="font-family: Arial, sans-serif; font-size: 12px;
color: grey;" border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td><span style="font-weight: bold">François-Xavier Pineau</span></td>
<td rowspan="4"><a href="http://astro.u-strasbg.fr"
title="Observatoire de Strasbourg"><img style="border:
0;" src="cid:part1.06050507.01080800@astro.unistra.fr"
alt="Université de Strasbourg"></a></td>
<td>CDS, Observatoire de Strasbourg</td>
</tr>
<tr>
<td><a href="mailto:francois-xavier.pineau@astro.unistra.fr"
title="Contacter
francois-xavier.pineau@astro.unistra.fr">francois-xavier.pineau@astro.unistra.fr</a></td>
<td>11, rue de l'Université</td>
</tr>
<tr>
<td>Phone +33 (0)3 68 85 24 14</td>
<td>F - 67000 Strasbourg</td>
</tr>
<tr>
<td><a href="http://snob.u-strasbg.fr/%7Epineau"
title="http://snob.u-strasbg.fr/~pineau">http://snob.u-strasbg.fr/~pineau</a></td>
<td><a href="http://astro.u-strasbg.fr"
title="http://astro.u-strasbg.fr">http://astro.u-strasbg.fr</a></td>
</tr>
</tbody>
</table>
</div>
</body>
</html>