Reading Julian date into SuperMongo

  • Thread starter Thread starter polystethylene
  • Start date Start date
  • Tags Tags
    Reading
Click For Summary

Discussion Overview

The discussion revolves around the challenges of reading Julian dates into SuperMongo, a niche graphics language. Participants explore issues related to data precision, significant figures, and potential workarounds for data manipulation within the software.

Discussion Character

  • Technical explanation
  • Debate/contested

Main Points Raised

  • One participant describes the format of Julian dates and notes that SuperMongo reads them inaccurately as scientific notation, suggesting a potential issue with significant digits.
  • Another participant proposes that the software may not handle high precision values well and suggests writing a program to process the numbers digit by digit.
  • A participant questions the commonality of programming languages struggling with high significant figures and expresses uncertainty about SuperMongo's capabilities based on its documentation.
  • Another reply recommends setting the precision in SuperMongo using a specific command and discusses the rarity of programming languages handling 16 significant figures without explicit configuration.
  • One participant suggests that if SuperMongo cannot read the values correctly, transforming the data into a more manageable format might be necessary, questioning the actual precision needed for the task at hand.

Areas of Agreement / Disagreement

Participants express uncertainty about SuperMongo's ability to handle high precision values, with no consensus on the best approach to resolve the issue. Multiple competing views on data handling and precision requirements are present.

Contextual Notes

Limitations include potential misunderstandings of SuperMongo's capabilities and the need for clarity on the precision required for the data being plotted.

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!
 
Technology 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.
 

Similar threads

  • · Replies 2 ·
Replies
2
Views
2K
Replies
4
Views
4K
  • · Replies 4 ·
Replies
4
Views
2K
  • · Replies 13 ·
Replies
13
Views
4K
  • · Replies 8 ·
Replies
8
Views
2K
  • · Replies 16 ·
Replies
16
Views
5K
  • · Replies 4 ·
Replies
4
Views
12K
  • · Replies 2 ·
Replies
2
Views
22K
  • · Replies 5 ·
Replies
5
Views
4K
  • · Replies 1 ·
Replies
1
Views
3K