| Plea for IDL 2000 (was: a plea for more reliable mathematical routines) [message #17138] |
Thu, 16 September 1999 00:00  |
m218003
Messages: 56
Registered: August 1999
|
Member |
|
|
In article <MPG.124804e8864d03df9898ec@news.frii.com>,
>>
>> I definitely disagree. It is inferior to Java, Python, C/C++
>
> I mean, honestly, that fact that IDL is still selling as well
> as it does is not a testament to what a great language it is.
> It is a testament to how hard it is to write something like
> it that can beat it in the marketplace.
> Somebody has to be looking at the ol' man and thinking
> "I can do better than that." Perhaps that somebody is
> you, Arno. [...][/color]
Sound to me as if Dave Stern should take this as a wakeup call and
lock himself into the garage for a while ;-) Seriously: RSI has the
source code, so for them it would be a head start to come up with a
more modern version of IDL -- let's just name it IDL 2000 (although
it might be a little late for this). Who really needs more features in
IDL as it is? Why not consolidate all forces and give the old lady
(why "man" David?) a rejuvenalization? Start from scratch and rebuild
the language, but leave the general syntax (arguments and keywords,
comma seperation) untouched, so it would be somewhat less hard to
convert old programs (of course even better would be some kind of
conversion tool which would be helpful enough if it could convert
90% of the code and mark the remaining 10%).
As a start, here a short list of fundamentals that I would like to
see changed:
* Data types: The default integer should be 32 bit (if not even 64),
so you would get rid of many problems with loops and array indices.
For reading of binary files, a 2 byte integer should be kept as
SHORT.
* Mathematical routines: well, see the thread. But definitively, they
should all operate on DOUBLE as default and -- if at all -- allow a
/SINGLE keyword in case one runs out of memory with DOUBLE arrays.
* PLOT and the likes: should also operate with DOUBLE values. There
should be a solid 2D object oriented model together with a successor
of the direct graphics routines (which are still useful to create
real quick overview plots and maybe even for publication quality
plots exactly because of the lack of interactivity!).
All the keywords should be cleaned, e.g. it should be possible
to call PLOT with an /OVERPLOT keyword (i.e. the same as OPLOT)
and you should definitively not need an /ADVANCE keyword for
MAP_SET. Also (as I remarked about a year ago) it should be more
intuitive e.g. to turn of axis labels (would you have ever thought
of TICKFORMAT='(A1)' on your own?). AND: please get rid of these
annoying character units (e.g. MARGIN)!
* SMP (symmetric multiprocessing) is becoming more and more of a
standard, so IDL should support it.
* Foreign language support in the vector fonts would also be on my
wish list (but please don't go as far as Windows where you always
have to access the system's control panel to change from ',' as
decimal notation to '.' if you exchange data with colleagues in
an Excel spreadsheet). It would just be nice if one could e.g.
write "o for an o-umlaut (perhaps it would be great if the Tex2IDL
interface would become some integral part of IDL. TeX is extremely
powerful in formatting equations etc., and it is much more intuitive
to write 'A_3' or 'A_{3,2}' instead of 'A!L3!N' or 'A!L3,2!N'.
Also, TeX is fairly wide spread so people would not have to adapt
to yet another formatting syntax.
* The image routines should be standardized and not consist of a mixture
between procedures and functions as it is now.
* In order to achieve more consistency between the object oriented graphics
and direct graphics, one should perhaps think of adapting the GNUPLOT
approach: there you call a bunch of SET commands to specify the plot
style, and then the PLOT command becomes much shorter. In principle
one could map the object structure with its view, plotwindow, axis, etc.
onto a hierachical structure which could be used in the same way by the
direct graphics routines (probably direct graphics would in the end
be only another interface for what in fact is object graphics?).
Once again: I really think IDL as we know it has reached its maturity a
while ago, and now it's time to think of the future! Of course RSI still
needs to support the current IDL version and its users, but I really think
they should give their development team a new direction.
Have a good day,
Martin
--
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
[[ Martin Schultz Max-Planck-Institut fuer Meteorologie [[
[[ Bundesstr. 55, 20146 Hamburg [[
[[ phone: +49 40 41173-308 [[
[[ fax: +49 40 441787 [[
[[ martin.schultz@dkrz.de [[
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
|
|
|
|
| Re: Plea for IDL 2000 (was: a plea for more reliable mathematical routines) [message #17209 is a reply to message #17138] |
Wed, 22 September 1999 00:00  |
ronn
Messages: 123
Registered: April 1999
|
Senior Member |
|
|
In article <7s4q2u$51j$1@alster.dkrz.de>,
m218003@modell3.dkrz.de (Martin.Schultz@dkrz.de) wrote:
> But to be constructive:
> how about a user-bug-fix initiative? ..... LOTS CUT
> where people could download the most recent versions
> of the IDL procedures, and upload their corrected versions .... LOTS
CUT
On my web site (www.rlkling.com) I have a place for modified IDL
routines that people create. RSI knows about this and has given me the
OK for posting them. The only restricition they asked for was that the
routines be renamed with the authors initials as the first two
characters. This will avoid any confusion with their tech support.
To name an example: just last week I eliminated an
> annoying restriction in VELOVECT.PRO which is that it does not accept
> 2D arrays for X and Y and hence does not work for irregulariliy
gridded
> data. Well, now it does;-) and I would be happy to contribute this
fix.
If you send it to me I will post it as MSVELOVECT.PRO !
> BUT OF COURSE: We need to be sure that our effort will be
> honored in that bug fixes will make it into the official distribution!
I cannot promise that, but RSI does know about the site and I as new
routines are added I will let them know that they are there.
-Ronn
--
Ronn Kling
Ronn Kling Consulting
www.rlkling.com
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
|
|
|
|
| Re: Plea for IDL 2000 (was: a plea for more reliable mathematical routines) [message #17239 is a reply to message #17138] |
Mon, 20 September 1999 00:00 |
m218003
Messages: 56
Registered: August 1999
|
Member |
|
|
> In article <onyae3c0ui.fsf@cow.physics.wisc.edu>,
> craigmnet@cow.physics.wisc.edu wrote:
>
>> have spent a profound amount of my time working around IDL bugs.
>>
>> Love/Hate, that's what it is!
>
>
at least the quirks keep your attention focused on IDL ;-)
(not on your scientific problem though ;-() But to be constructive:
how about a user-bug-fix initiative? A great many of IDL's routine
are written in the IDL language, so everyone can go ahead and check them
through (at least it's partly open source that way -- although RSI
imposes a pretty stringent copyright notice on their routines). If
RSI would be willing to cooperate here and perhaps set up a web site,
ftp archive etc. where people could download the most recent versions
of the IDL procedures, and upload their corrected versions (or submit
them with some guarantee that they would appear in the archive with
a reasonable response time) that could give them a bunch of programmers for
free so to speak. To name an example: just last week I eliminated an
annoying restriction in VELOVECT.PRO which is that it does not accept
2D arrays for X and Y and hence does not work for irregulariliy gridded
data. Well, now it does;-) and I would be happy to contribute this fix.
BUT OF COURSE: We need to be sure that our effort will be honored in that
bug fixes will make it into the official distribution! Another example:
wouldn't it be great to see MP_FIT appear in the official online help?
Although they would have to loosen copyright on those routines which
have a user component, I believe...
Nice start for a week!
Martin
--
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
[[ Martin Schultz Max-Planck-Institut fuer Meteorologie [[
[[ Bundesstr. 55, 20146 Hamburg [[
[[ phone: +49 40 41173-308 [[
[[ fax: +49 40 441787 [[
[[ martin.schultz@dkrz.de [[
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
|
|
|
|
|
|
|
|
| Re: Plea for IDL 2000 (was: a plea for more reliable mathematical routines) [message #17244 is a reply to message #17138] |
Sat, 18 September 1999 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Greg (ushomirs@my-deja.com) feels like this discussion
is getting a little hot. I'm sorry he feels that way
and I'm sorry if he feels like I'm contributing some of
the heat.
Let me just say, again, that I am completely in favor of
discussions of IDL's weaknesses. Many people at RSI
read this newsgroup (I know this from my personal experience
of feeling a little heat myself from time to time) and
this is a useful forum for making our thoughts, feelings,
and even our wish-lists known to them. They DO pay attention.
And they DO care about what you have to say. Their goal--as
even the most cynical among us must acknowledge--is to sell
software. They can't write software that is indifferent to
the needs and wishes of their users if they want to be
successful.
But what is not helpful--indeed it might even be
counterproductive--is to couch our disappointments
and displeasure and whatever it is that is not working
for us in invective. Better, and MUCH more productive,
to voice our concerns and offer a few constructive
suggestions, as Mr. Vukovic did a day or so ago.
You might even try wit and humor if you are capable
of it. Although humor sometimes goes awry in
print form, it at least makes for more interesting
reading than a rant of the things you don't like
and it can be every bit as sharp.
Will RSI respond to everything we want? Not likely.
While the software costs more than Microsoft Office,
RSI probably sells the same number of licenses in
a year that Microsoft sells in an hour. Pockets
and staff (whatever you may have heard) are not
nearly so deep. So wish-lists have to be balanced
against time, priorities, and staff considerations.
What people have asked for and what they want DOES
figure into that equation. More now, I think, than
it did several years ago when I was more familiar
with the process.
The bottom line is this: keep those cards and letters
pouring in. RSI *needs* our feedback. But nobody--from
dogs to children to software companies--responds well
to shouted criticism. Show them the stick (and your
wallet), but give them the carrot, too.
> So i don't see how unsound programming practices
> that would have been acceptable in a prototype could pass in a real,
> shipping product.
Several years ago now RSI realized that what seemed like
a good program structure 16 years ago wasn't working so
well anymore. It was becoming more and more difficult
to graph new features onto the underlying program
scaffolding. So they took nearly one and a half
years to completely rewrite the IDL internals, using
the best programming practices at the time. The idea
was to create an internal structure that would allow
things like objects and pointers and the new development
environment, which would probably not have
been possible with the old structure.
What I remember most about that time was how often
I had to face irate people who were screaming
at me that for a year and a half they had gotten
NOTHING for their maintenance dollars! Why was RSI
ripping them off! Was David Stern talking the whole
company on vacations to Mexico with their money, etc.,
etc. I felt like *I* was under a lot of pressure,
and I wasn't even writing the code. I can imagine
what the engineers were feeling, working 10-12 hour
days. I think the fact that a fair number of them
left the company at the end of that effort is testament
to the strain they were under.
But you see, it is the nature of people that they want to
have their cake and eat it too. I wouldn't be a
programmer for a software company for anything. You are
always in the hot seat, no matter what you do. And
who among us can write bug-free code under that kind
of pressure?
> And boy, does Microsoft get major flak for bugs in their stuff!
Yeah, well, they deserve it. Gates is rich as hell. :-)
> SO while my original complaint about bad documentation for LSODE started
> this big flame war, nobody even bothered to take on my second question,
> how the heck do i call an IDL function from an external (linkimage or
> dlm) module??
Donno. Not my job as Defender of the Realm. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Plea for IDL 2000 (was: a plea for more reliable mathematical routines) [message #17245 is a reply to message #17138] |
Sat, 18 September 1999 00:00 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
davidf@dfanning.com (David Fanning) writes:
> What I don't understand is the heat behind these
> feelings that IDL is a big hack. Heck, go use something
> else if you feel that way. It's a competitive marketplace
> that IDL lives in and you are free to buy (or build)
> anything that does the job for you. IDL only exists because
> *somebody* keeps buying it.
Hi David--
I love IDL. It's got a wonderfully expressive language, powerful
vectorizable operators, and mountains of library software (my own, and
from others). As an interactive analysis language it has profoundly
changed how I work (for the better). I have made software the beats
the socks off its C/FORTRAN equivalents.
I could hate IDL. It's got a quirky language with objects tacked on.
I have made a large investment in mountains of software that won't run
on any other system. IDL is not very friendly to the
programmer/maintainer and has introduced and obsoleted several
language features over the course of a year or less. Software bugs
persist through several versions. When a bug appears we have no
recourse in fixing it, since we don't have the core IDL source code.
For example, witness the arguments about mathematical functions. I
have spent a profound amount of my time working around IDL bugs.
Making a simple hardcopy in direct graphics is a serious
inconvenience.
Love/Hate, that's what it is!
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
| Re: Plea for IDL 2000 (was: a plea for more reliable mathematical routines) [message #17250 is a reply to message #17138] |
Sat, 18 September 1999 00:00 |
ushomirs
Messages: 14
Registered: May 1993
|
Junior Member |
|
|
well, i knew i'd be in for some flames when i wrote this, so heck,
bring 'em on.
but seriously, you do NOT need to convince me that IDL it is useful.
I've been using it for ..pause to count.. well, since 1991. not
continuously of course, there have been periods of order months when i
just haven't needed it. i've used it for processing satellite data
(GOES, YOHKOH, DMSP), but most recently for crunching though the output
of my simulations and making publication-quality plots.
and yes, i instructed my advisor to buy idl, not the other way around.
in fact, my department has 50 licenses now.
it's just that the number of hoops one has to jump through to get a
decent (publication-quality) plot out of idl is tremendous. for
example, you can say device,font_size=12 when in postscript mode to
request 12pt fonts. but if you stack 2 plots on a page with !p.multi,
you won't get 12pt fonts, but something much smaller? so you have to go
back and screw around with charsize keywords. i can name a gazzilion
things like that. in fact, there's not a single element of the plot that
i don't end up doing by hand (including placing axis captions, etc).
what's the point in having a PLOT command if i basically have to do
everything by hand?? i don't have time for that...
as far as developing idl as a "hack". i'm sure none of the original
code Stern wrote at LASP is in idl. that would be property of University
of Colorado, he wouldn't be able to sell that commercially. Just like
netscape people had to rewrite netscape from scratch, without using any
of the mosaic code. So i don't see how unsound programming practices
that would have been acceptable in a prototype could pass in a real,
shipping product. a product that costs many times more than microsoft
office. and boy, does Microsoft get major flak for bugs in their stuff!
the story is that in astronomy (my field) idl has become one of the
de-facto standards (god, it's a lesser evil than IRAF). there's tons of
data reduction software written in IDL. stuff that has been tested and
works. so many people's sense is that, while idl has many shortcomings,
using something different to replace it would take a while to get up to
speed. now, since we don't program for programming sense, but only to
get scientific results, it's easier to deal with all the quirks than
start fresh.
SO while my original complaint about bad documentation for LSODE started
this big flame war, nobody even bothered to take on my second question,
how the heck do i call an IDL function from an external (linkimage or
dlm) module??
greg
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
|
|
|
|
| Re: Plea for IDL 2000 (was: a plea for more reliable mathematical routines) [message #17254 is a reply to message #17138] |
Fri, 17 September 1999 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Greg (ushomirs@my-deja.com) writes:
> yeah.. IDL started out as a big hack, so I could understand some of
> these inconsistensies in the original version. But still developing it
> as a hack after 16 years? c'mon!
"A big hack" is one way to describe a program that
started out of solve some interesting scientific
problems, but I doubt it is the most helpful way
to think about it. Did David Stern have *this* IDL
in mind when he started out 16 years ago? I doubt it.
He was just trying to make something useful for his
colleagues and create a job for himself. I know
David personally and I am pretty sure that is *still*
his motivation. And after all, it's not like he has
a ton of shareholders he has to please. RSI is
privately owned and David can do whatever he likes,
including chuck it all and move to Cancun.
You can say whatever you like about IDL, but I
can assure you there are LOTS of people who find
it useful. And there are probably more of us than
you like to think who wouldn't think of programming
in anything else. By that standard IDL has been
amazingly successful.
I can think of several software products that do
specific tasks better than IDL, but I can't think of
one that does the range of things IDL can do any better
than IDL can do them.
What I don't understand is the heat behind these
feelings that IDL is a big hack. Heck, go use something
else if you feel that way. It's a competitive marketplace
that IDL lives in and you are free to buy (or build)
anything that does the job for you. IDL only exists because
*somebody* keeps buying it.
The only explanation I can come up with for the strong
animosity is that that "somebody" is your boss, who
purchased IDL against your recommendation. But, hey, it's
a programmer's market out there. You can always get a new
boss. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Plea for IDL 2000 (was: a plea for more reliable mathematical routines) [message #17255 is a reply to message #17138] |
Fri, 17 September 1999 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Greg (ushomirs@my-deja.com) writes:
> yeah.. IDL started out as a big hack, so I could understand some of
> these inconsistensies in the original version. But still developing it
> as a hack after 16 years? c'mon!
"A big hack" is one way to describe a program that
started out of solve some interesting scientific
problems, but I doubt it is the most helpful way
to think about it. Did David Stern have *this* IDL
in mind when he started out 16 years ago? I doubt it.
He was just trying to make something useful for his
colleagues and create a job for himself. I know
David personally and I am pretty sure that is *still*
his motivation. And after all, it's not like he has
a ton of shareholders he has to please. RSI is
privately owned and David can do whatever he likes,
including chuck it all and move to Cancun.
You can say whatever you like about IDL, but I
can assure you there are LOTS of people who find
it useful. And there are probably more of us than
you like to think who wouldn't think of programming
in anything else. By that standard IDL has been
amazingly successful.
I can think of several software products that do
specific tasks better than IDL, but I can't think of
one that does the range of things IDL can do any better
than IDL can do them.
What I don't understand is the heat behind these
feelings that IDL is a big hack. Heck, go use something
else if you feel that way. It's a competitive marketplace
that IDL lives in and you are free to buy (or build)
anything that does the job for you. IDL only exists because
*somebody* keeps buying it.
The only explanation I can come up with for the strong
animosity is that that "somebody" is your boss, who
purchased IDL against your recommendation. But, hey, it's
a programmer's market out there. You can always get a new
boss. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Plea for IDL 2000 (was: a plea for more reliable mathematical routines) [message #17257 is a reply to message #17138] |
Fri, 17 September 1999 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Greg (ushomirs@my-deja.com) writes:
> see! that's yet another example of how poorly thought out IDL is!!
> other directives (such as .RUN, .COMPILE) don't need a comma after
> their names. Why not make it .COMPILE_OPT, so that the lack of comma
> would at least make sense? I guess that would be too reasonable and
> well thought-out for RSI.. sigh..
Well, to be fair, other "compiler option" commands don't
take commas either. For example, "Forward_Function foobar".
Such syntax is undoubtedly necessary to make the compiler aware of
an option for it rather than to compile a procedure or
function, which it would do otherwise. It makes sense
to me and I would have probably realized it if I had
taken 5 seconds to think about it, rather than typing
away. Or, I could have just looked at the example in
the book. It was pretty obvious there. :-)
Cheers,
David
P.S. Incidentally, another compiler option will make it
necessary to use square bracket subscripting for all
array subscripts. This will virtually eliminate the
need for Forward_Function, I think.
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
|
|
| Re: Plea for IDL 2000 (was: a plea for more reliable mathematical routines) [message #17261 is a reply to message #17138] |
Fri, 17 September 1999 00:00 |
Mirko Vukovic
Messages: 124
Registered: January 1996
|
Senior Member |
|
|
In article <7rsidq$j5s$1@nnrp1.deja.com>,
ushomirs@my-deja.com wrote:
> In article <MPG.124ad31447ec3ccd9898f7@news.frii.com>,
> davidf@dfanning.com (David Fanning) wrote:
>
>> New in IDL 5.3 (according to the on-line documentation in the beta
>> version is a "compile option" routine that can change the default
>> integer size from 16-bit to 32-bit:
>>
>> IDL> Compile_Opt DefInt32
>> IDL> a = 0
>> IDL> Help, a
>> A LONG = 0
>>
>> Cheers,
>>
>> David
>>
>> P.S. Note there is NO comma after the COMPILE_OPT
>> command! Took me about 10 minutes to realize that. :-(
>
> see! that's yet another example of how poorly thought out IDL is!!
> other directives (such as .RUN, .COMPILE) don't need a comma after
> their names. Why not make it .COMPILE_OPT, so that the lack of comma
> would at least make sense? I guess that would be too reasonable and
> well thought-out for RSI.. sigh..
>
> greg
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
>
Agreed
It seems to me that they should have a comp.lang.
specialist that would help them with routine names,
and parameter and keyword names and usages.
Sometimes a parameter is used to signal two different things.
Mirko
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
|
|
|
|
| Re: Plea for IDL 2000 (was: a plea for more reliable mathematical routines) [message #17263 is a reply to message #17138] |
Fri, 17 September 1999 00:00 |
ushomirs
Messages: 14
Registered: May 1993
|
Junior Member |
|
|
In article <MPG.124ad31447ec3ccd9898f7@news.frii.com>,
davidf@dfanning.com (David Fanning) wrote:
> New in IDL 5.3 (according to the on-line documentation in the beta
> version is a "compile option" routine that can change the default
> integer size from 16-bit to 32-bit:
>
> IDL> Compile_Opt DefInt32
> IDL> a = 0
> IDL> Help, a
> A LONG = 0
>
> Cheers,
>
> David
>
> P.S. Note there is NO comma after the COMPILE_OPT
> command! Took me about 10 minutes to realize that. :-(
see! that's yet another example of how poorly thought out IDL is!!
other directives (such as .RUN, .COMPILE) don't need a comma after
their names. Why not make it .COMPILE_OPT, so that the lack of comma
would at least make sense? I guess that would be too reasonable and
well thought-out for RSI.. sigh..
greg
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
|
|
|
|
| Re: Plea for IDL 2000 (was: a plea for more reliable mathematical routines) [message #17266 is a reply to message #17138] |
Thu, 16 September 1999 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Martin.Schultz@dkrz.de (m218003@modell3.dkrz.de) writes:
> As a start, here a short list of fundamentals that I would like to
> see changed:
>
> * Data types: The default integer should be 32 bit (if not even 64),
> so you would get rid of many problems with loops and array indices.
> For reading of binary files, a 2 byte integer should be kept as
> SHORT.
New in IDL 5.3 (according to the on-line documentation in the beta
version is a "compile option" routine that can change the default
integer size from 16-bit to 32-bit:
IDL> Compile_Opt DefInt32
IDL> a = 0
IDL> Help, a
A LONG = 0
Cheers,
David
P.S. Note there is NO comma after the COMPILE_OPT
command! Took me about 10 minutes to realize that. :-(
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
