Reading Julian date into SuperMongo

  • Thread starter Thread starter polystethylene
  • Start date Start date
  • Tags Tags
    Reading
Join the discussion
Registration is free. Ask a follow-up in this thread, or start your own.
3 replies · 6K views
polystethylene
Messages
17
Reaction score
0
Hi all, I imagine this is an amazingly simple problem for anyone with the slightest bit of programing knowledge (which isn't me).

I hope there are people out there familiar with supermongo, I realize it's one of the more niche graphics languages.

Anyway, I have a column of Julian dates, in the form:

2454799.392986
2454799.402327

etc. (there are many other columns however, all comma separated).

Anyway, it seems supermongo is reading each row in as 2.45e+06. I thought that maybe it was just the print command not displaying the full value, but plotting the figure reveals that SM is reading in each row as exactly the same value. Anyone got any ideas?

I've tried :

read { HJD 1.f }

and

read '%f' { HJD 1 }

but to no avail...

Any experienced sm users out there?

Cheers!
 
Physics news on Phys.org
JD 2454799.39298 is
CE 2008 November 28 21:25:53.5 UT Friday
JD 2454799.40232 is
CE 2008 November 28 21:39:20.4 UT Friday

The number before the decimal point is the day, and the digits after the decimal point represent the time.
You get the same date probably the software is not able to process the large number significant digits required. If you can write a program to scan the number digit by digit, you should be able to work something out.

For individual conversions, you can try:
http://aa.usno.navy.mil/cgi-bin/aa_jdconv.pl
 
Last edited by a moderator:
Hi mathmate, thanks for the response. My problem is not knowing what to do with JD once I have it, It's getting supermongo to read the exact JD into a vector so that I can manipulate it. Your point about it being too many significant figures was interesting, is it common to not be able to read high sig. fig. values in programming languages?

I can't seem to find anything on the topic in the SM documentation, suggesting it should be able to read floating point values up to any number? If languages can't deal with large numbers, how do they work around this?

This must be a common issue with SM, so hopefully someone knows the workaround for it.
 
First, try the command:

Code:
define sig 18.6
ref: http://www.astro.lsa.umich.edu/~rstanek/ngc.sm
Also, see reference manual:http://www.atnf.csiro.au/computing/software/smongo/sm_toc.html

in your macros. It will set the precision to 18 significant digits and 6 decimal positions.
If that does not work, namely if the command is not accepted, or the syntax is wrong, and if you cannot find the correct syntax, you may have to read the following as a last resort.

Yes, it is in fact rare that programming languages are able to handle 16 significant figures without specifically asking for it, the type of storage called double precision in most languages. On the other hand, most modern languages are able to accommodate this requirement.

Having said that, I have to admit that I have not used Supermongo before, and I do not have access to the use of it, as it seems to be a language available on Unix, which I used to work with.

On the other hand, as it takes its input from a disk file, it would be relatively simple to convert the data by reading them in line by line and converting them into something Supermongo can manage. Julien date is a big range of dates that can handle centuries of information, like 3700 BC. Do you really need this range when you plot your data, or your problem only needs to plot data over a couple of years, or even months? How important is the precision? The dates above should have a precision of about one-tenth of a second. Do you need it only to be accurate to a day, an hour, or even a minute?

If you have answers to these parameters, it would be relatively simple to transform the data file that you have into a file Supermongo can manage. If you work on Unix, there are plenty of tools available to do transformations of this kind.