Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

Reading Julian date into SuperMongo

  1. Dec 6, 2008 #1
    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 realise it's one of the more niche graphics languages.

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


    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 }


    read '%f' { HJD 1 }

    but to no avail...

    Any experienced sm users out there?

  2. jcsd
  3. Dec 6, 2008 #2
    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:
    Last edited by a moderator: Apr 24, 2017
  4. Dec 6, 2008 #3
    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.
  5. Dec 6, 2008 #4
    First, try the command:

    Code (Text):
    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 accomodate 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.
Share this great discussion with others via Reddit, Google+, Twitter, or Facebook