wlandsman / idlastro

Astronomy related procedures in the commercial IDL language

IDLAstro

Astronomy related procedures in the commercial IDL language

idlastro's Issues

question: gdl support

how's support for https://github.com/gnudatalanguage/gdl ?

what about a link to it from the README.md ?

JPRECESS

I got bored waiting for JPRECESS to precess a million positions, so I re-wrote it to eliminate the loop over positions in favour of large matrix operations, which sped it up quite a bit. I don't use github much: what's the protocol for uploading revisions?

queryvizier on GDL

Have anyone succeeded in running queryvizier in GDL? I am getting an error:

GDL> info = queryvizier('2MASS-PSC','m13',10)
% Compiled module: QUERYVIZIER.
% Compiled module: ZPARCHECK.
% Compiled module: REPSTR.
% Compiled module: IDLNETURL__DEFINE.
% Type conversion error: Unable to convert given STRING: '[2] 41280' to INT.
% MESSAGE: Variable must be a scalar in this context: <STRING Array[4]>
% Execution halted at: IDLNETURL::GET 138

I would appreciate if anyone has a solution for this issue. Thanks a lot.

Gabriel

NaN keyword does not work recursively comparing structures

On procedure compare_struct.pro the NaN keyword does not work recursively for the structures passed. This NaN keyword should be added as parameters when compare_struct function is called recursively.

Compare struct procedure cannot cope with structures having hashes as members

Procedure compare_struct.pro cannot does not work if any member of the target structures has as member a hash.

TEST PROCEDURE

print," "
print, "Test Case : Comparing structures with hashes on it"
s1 = {x:1,h1:hash("x",1,"y",2)}
s2 = {x:1,h1:hash("x",1,"y",2)}
print,"s1:",s1
print,"s2:",s2
compare_struct(s1,s21)

OUTPUT

% Compiled module: COMPARE_STRUCT.
{
"TAG_NUM_A": 1,
"TAG_NUM_B": 1,
"FIELD": ".H1",
"NDIFF": 1
}

Unable to read HTTP server

Hi,

Seems like the example command does not work for me: a=webget('http://www.mpia.de/index.html')
I have the following: % WEBGET: Unable to read HTTP server
I have Mac OS 10.12.6 and IDL 8.4.1 (and 7.0)
Trying an other command, which works on other machine linux/Mac, does not work either:
webget('http://cdsweb.u-strasbg.fr/cgi-bin/nph-sesame/-o/?HD%20360')

Note that urls works on the browser though.

Any idea why?

Some files are not under the BSD license, and some files are distributed by violating their license

The following files document a license that contradicts to the BSD-2 license of the whole package.

factor.pro, getwrd.pro, isarray.pro, polrec.pro, prime.pro, recpol.pro, repchr.pro, sphdist.pro, and ymd2dn.pro have

; Copyright (C) 1988, Johns Hopkins University/Applied Physics Laboratory
; This software may be used, copied, or redistributed as long as it is not
; sold and this copyright notice is reproduced on each copy made.  This
; routine is provided as is without any express or implied warranties
; whatsoever.  Other limitations apply as described in the file disclaimer.txt.

This license restricts the distribution to not being sold, while the BSD license does not have such a restriction. Also, the file disclaimer.txt that is referenced in the copyright notice is missing.

blkshift.pro, jplephinterp.pro, jplephread.pro, jplephtest.pro, and tdb2tdt.pro have

; Copyright (C) 2000, 2002, Craig Markwardt
; This software is provided as is without any warranty whatsoever.
; Permission to use, copy and distribute unmodified copies for
; non-commercial purposes, and to modify and use for personal or
; internal use, is granted.  All other rights are reserved.

This license restricts the usage and distribution to non-commercial purposes, while the BSD license does not have this restriction. Also it does not allow the public distribution of modified files.
As the modification history of these files document, this is already violated in the IDLAstro distribution:

;   Truncate if moving data block forward from  the end of file 
;             using TRUNCATE_LUN   W. Landsman Feb. 2005 
;   Assume since V5.5, remove VMS support  W. Landsman  Sep 2006
;   Assume since V5.6, TRUNCATE_LUN available  W. Landsman Sep 2006
;   MacOS can point beyond EOF    W. Landsman   Aug 2009
;   Use V6.0 notation  W. Landsman Aprl 2014

eqpole_grid.pro, qdcb_grid.pro, and wcs_demo.pro have

;       Copyright 1991, The Regents of the University of California. This
;       software was produced under U.S. Government contract (W-7405-ENG-36)
;       by Los Alamos National Laboratory, which is operated by the
;       University of California for the U.S. Department of Energy.
;       The U.S. Government is licensed to use, reproduce, and distribute
;       this software. Neither the Government nor the University makes
;       any warranty, express or implied, or assumes any liability or
;       responsibility for the use of this software.

My interpretation of this license is that usage and distribution is only allowed for the U.S. Government.

These licenses makes it impossible to distribute these files with open source distributions, like Debian. In Debian, there are Debian Free Software Guidelines that don't allow discrimination against fields of endeavor (point 6).

Could you clarify the licenses of these files? For some of them (isarray.pro, repchr.pro, ymd2dn.pro, ), there is a replacement in Debian.

Inconsistent behavior of ten

ten function has an inconsistent behavior between numeric and string input, consider the following:

GDL> print, ten(-5.0, -60.0, -3600.0), ten("-5.0:-60.0:-3600.0")
      -7.0000000      -3.0000000
GDL> print, ten(-0.0, 60.0), ten("-0.0:60.0") 
       1.0000000      -1.0000000

I know that negative inputs are a problem (and negative zero in particular), but the algorithm used in the case of numerical input seems to be rather inconsistent (see the first line). The current algorithm for the numeric case is:

sign = sign(deg)
return sign*(abs(deg) + abs(min)/60.0 + abs(sec)/3600.0)

I would suggest to use the same algorithm used in the string case

sign = deg >= 0 ? 1 : 1
return sign*(abs(deg) + min/60.0 + sec/3600.0)

or even (for both numeric and string input)

degsign = deg >= 0 ? 1 : 1
minsign = min >= 0 ? 1 : 1
return degsign*(abs(deg) + minsign(abs(min)/60.0 + sec/3600.0))

in order to make ten("0:-0:60") conceptually consistent with the behavior of ten("-0:60:0"). I can't find an authoritative source stating which is the "correct", or at least the most commonly accepted, algorithm for sexagesimal to decimal conversion (especially with regard to dealing with signs of degrees, minutes, and seconds).

Of course, these change, the last suggested one in particular, raise backward compatibility concerns, I don't know the policy of the project in this regard.

This code should have a license

Normally, when people publish open-source works, they include a file named LICENSE or COPYING in the project root that makes clear the terms under which the software was released.

The GitHub help manuals have a FAQ on this issue:

You're under no obligation to choose a license. It's your right not to include one with your code or project, but please be aware of the implications. Generally speaking, the absence of a license means that the default copyright laws apply. This means that you retain all rights to your source code and that nobody else may reproduce, distribute, or create derivative works from your work. This might not be what you intend.

GitHub's choosealicense.com offers more information on the matter:

You retain all rights and do not permit distribution, reproduction, or derivative works. You may grant some rights in cases where you publish your source code to a site that requires accepting terms of service. For example, publishing code in a public repository on GitHub requires that you allow others to view and fork your code.

It looks to me like you probably intend this code to be used by others. Your readme says:

The success of the IDL Astronomy User's Library depends upon the
willingness of users to give as well as take. Submission of relevant
procedures is strongly encouraged. Equally important is the notification
(or correction) of programming bugs or documentation errors.

Encouraging people to submit code is great, but not if you don't give them the legal rights to do so. As things stand, programmers outside your organization will likely avoid contributing code for fear of legal risk. But your readme sounds to me like you'd prefer to encourage contributions!

Please take a look at choosealicense.com and consider giving people the right to make modifications to this work.

A new version of fxbread.pro is available in the Solar Software Library

New version at https://soho.nascom.nasa.gov/solarsoft/gen/idl/fits/fxbread.pro

How to make the headers of two fits files the same?

Infact I have to make the header of fits file 'exponential.fits' same as that of 'empirical.fits'. Is there any way to do it with writefits.pro?Please help

WCSSPH2XY

In the 'MOL' (Mollweide) case, the Newton iteration can get stuck in a loop before tolerance is reached because the numerator in the iteration step reaches the double precision "EPS" value (defined as the smallest value for which 1-eps NE 1). Fix is to separately test for this:

machine_constants = MACHAR(/DOUBLE)
eps = machine_constants.eps > machine_constants.epsneg
repeat begin
...
endrep until (old condition OR MAX(ABS(numerator) LE eps)

imcountour.pro frames unusable/wrong results for larger sky fields and other than TAN projection

imcontour .pro uses ticlabels.pro which has the statement:

; RESTRICTIONS:
; Invalid for wide field (> 2 degree) images since it assumes that a
; fixed interval in Y (or X) corresponds to a fixed interval in Dec
; (or RA)

which explains why imcontour.pro gives wrong labeling and tick marks when using a larger sky field...
Also, when using SIN projection rather than TAN projections the routine gives wrong results and coordinates drawn around an image are not correct. If the image is converted e.g. from SIN to TAN projection by using e.g.

remap -w TAN -o output_TAN.fits Input_SIN.fits

If someone has a routine which does it better than ticlabels.pro please share...

-9223372036854775808LL in MRDFITS

The routine MRDFITS uses the value -9223372036854775808LL as an offset (in line 984).
This value is not currently accepted by GDL nor FL
(see gnudatalanguage/gdl#1037) and makes the routine unusable.
Replacing that value with 2LL^63 would work properly in IDL, GDL and FL.

Queryvizier.pro not working anymore

I've run into an issue with the IDL Astro user's queryvizier.pro.
It seems that query results from VizieR now end with an INFO
line stating the number of matches, e.g.,

#INFO matches=636 matching records

But queryvizier.pro (line 236-239) picks this up as an error
and returns nothing. Would it be possible to fix this? I think
just removing those lines would do it.

WCS_ROTATE fails (again) for 180 degree rotations

Just discovered that WCS_ROTATE is still not working properly for 180 degree rotations; specifically, it fails at longitude 180 degrees:

HIDL> wcs_rotate, 180d0+[1,0,-1], 7d0+[0,0,0], phi, theta, [180d0,0d0], theta0=0d0
HIDL> print, phi
1.0000000 180.00000 -1.0000000
HIDL> print, theta
7.0000000 7.0000000 7.0000000

QUERYVIZIER: No sources found within specified radius

Hi,

I always get the "no sources found within specified radius" error when I try to fetch data from catalogue of II/348 but I'm able to get the data from II/328. I use the version of queryvizier with Feb 2018 update.

all the best.