HDTenEightyP/NetNews huggingface dataset:
From: zawodny@arbd0.larc.nasa.gov (Dr. Joseph M Zawodny)
Subject: Color Contouring Proceedure Note
Organization: NASA Langley Research Center, Hampton, VA
Distribution: comp.lang.idl-pvwave
Date: Fri, 11 Sep 1992 14:45:57 GMT

	There was an immediate response to my offer of a color contouring
routine, so I will post it.   It comes in two parts, CONTTW.PRO and EXPAND.PRO,
both of which have been tested to a fair degree.  You may hack these to bits as
you see fit.  I have indicated areas of CONTTW where you may wish to change
things (such as color tables, what is black and what is white etc.) with a
comment line containing ****.  This routine has LOTS of keywords, some of which
interact with each other.  Play with it for awhile before declaring that a
"feature" is a bug.  I have no doubt that may of you will improve on this
routine, please keep me informed of enhancements.

	EXPAND.PRO performs a two dimesional stretch (or shrink) of an array of
any size to any size via a bilinear interpolation (sort of like the way
CONGRIDI was supposed to work).  Currently the result is always a floating
point array although the input may be anything.  There is some interesting
manipulations of subscripts in this routine which may be of general interest to
the newcommer to IDL.  See if you can figure out why it works.

	Have fun but don't blame me.

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
 Joseph M. Zawodny   (KO4LW)                      NASA Langley Research Center
 zawodny@arbd0.larc.nasa.gov                      MS-475,    Hampton VA, 23681
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


Newsgroups: comp.lang.idl-pvwave
From: bowman@csrp.tamu.edu (Kenneth P. Bowman)
Subject: NetCDF support within IDL
Followup-To: comp.lang.idl-pvwave
Organization: Texas A&M University
Distribution: usa
Date: Tue, 8 Sep 1992 19:02:47 GMT

There was mention in this group a few weeks ago of pending
support for netCDF file access from within IDL.  Has this
been announced or released?  Will it be a built-in function
or library routines?  And lastly, is it possible to get
it now?

Thanks for any help,
Ken Bowman
Newsgroups: comp.lang.idl-pvwave
From: zawodny@arbd0.larc.nasa.gov (Dr. Joseph M Zawodny)
Subject: Re: EXPAND.PRO - needed by CONTTW.PRO
Organization: NASA Langley Research Center, Hampton, VA
Distribution: comp.lang.idl-pvwave
Date: Fri, 11 Sep 1992 19:23:53 GMT

	Wayne is correct about his mods to my EXPAND program.  However, if you
do expect to utilize the "missing data" capabilities, I think that you are
still better off utilizing my original posting.  I will be playing with it a
little to see how much faster using INTERPOLATE will be over the way it is
written now and will re-post if there is a significant speed increase.

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
 Joseph M. Zawodny   (KO4LW)                      NASA Langley Research Center
 zawodny@arbd0.larc.nasa.gov                      MS-475,    Hampton VA, 23681
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Newsgroups: comp.lang.idl-pvwave
From: zawodny@arbd0.larc.nasa.gov (Dr. Joseph M Zawodny)
Subject: More on CONTTW and color tables
Organization: NASA Langley Research Center, Hampton, VA
Distribution: comp.lang.idl-pvwave
Date: Fri, 11 Sep 1992 15:42:36 GMT

	Before the onslaught begins, If you want to have black be black and
white be white in CONTTW you might consider adding the following lines of code
to CONTTW just after the LOADCT call.

	r=[0b,255b,0b,0b,255b]
	g=[0b,0b,255b,0b,255b]
	b=[0b,0b,0b,255b,255b]

	tvlct,r,g,b,251

Around here we do not like or use the supplied IDL color tables and have our
own set.  We have decided to utilize only the first 251 colors and reserve the
last 5 for black, red, green, blue, and white.  This is what CONTTW expects.
If you have adopted a similar scheme you can just change CONTTW to correspond
to your definitions of black and white.  Otherwise the code listed above will
modify the color table to work with CONTTW.

	Hope this helps,

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
 Joseph M. Zawodny   (KO4LW)                      NASA Langley Research Center
 zawodny@arbd0.larc.nasa.gov                      MS-475,    Hampton VA, 23681
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
From: rclark@lpl.arizona.edu (Richard Clark x4971)
Newsgroups: comp.lang.idl-pvwave
Subject: axis ticks
Date: 9 Sep 92 21:09:55 GMT
Distribution: usa
Organization: Lunar & Planetary Laboratory, Tucson AZ.


Does anybody have any routines that can be called to replace the default
axis tick labeling on simple PLOTs? The default selection of the number of
major/minor ticks and their labeling leaves quite a bit to be desired. On
rare occasion I have gotten a plot with an axis (either x or y) with a
SINGLE LABELED TICK and axes with only 2 labeled ticks are fairly
frequent. It is also common to get no minor ticks at all.

There is a similar problem with the assignment of levels to be CONTOURed.
The levels selected for contouring seem to be the same with or without the
use of /follow.

The detailed control over the plot apearance which can make for a nice
final product is possible but this gets to be quite a nuisence when you
need to do it on your first look at new data.

And yes, I have asked RSI about this, even captured some examples complete
with programs and minimal datasets to email them. But my personal generic
io proceedure to read_file_of_colums seems to have portability problems
they couldn't overcome. (I had thought it should work on any unix machine
but I only have the one to verify it with.)

Richard Clark
rclark@lpl.arizona.edu
From: thompson@stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
Newsgroups: comp.lang.idl-pvwave
Subject: Re: New IDL Prices!
Keywords: Ouucchhh
Date: 5 Sep 92 20:52:00 GMT
Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics
News-Software: VAX/VMS VNEWS 1.4-b1

In article <15318@umd5.umd.edu>, paul@astro.umd.edu (Paul Butler) writes...
>I have just heard that IDL is raising prices to PV Wave levels!
>Unlimited access on a single CPU is going up to $15k
>Single access on a single CPU is going to $3k
> 
>I hope this is not true.  Such a pricing policy could
>relegate IDL to the high end specialty market.  Given
>IDL is already developed, it would make sense to attempt
>to make IDL a wide spread data analysis and visualization
>standard.  If this new pricing policy is true, it seems
>that IDL's market share will contract rather than expand.
>This can not be good for the long run.

Hear, hear!

Unfortunately, it is true.  RSI's current policy seems to decouple the cost of
IDL from the class of machine it's running on.  This seems to be a highly
unusual pricing strategy for a high end software product.

IDL does do a lot more than it used to, and it does seem to be going through a
period of expansion of capabilities.  In that sense, maybe the prices aren't
all that unreasonable when applied to the highest end platforms.  However, one
should expect to spend less for IDL on more modest platforms.

The new pricing policy will particularly hurt in two areas:

	1.  As workstations get cheaper and cheaper, the price of a single-user
	    IDL license starts getting close to the cost of the machine itself.

	2.  When people who have already bought IDL in the past under the old
	    pricing agreement upgrade to new platforms, they will have to pay
	    the difference between the old and new prices as an ugrade fee.
	    With the prices so much different, this could be a substantial
	    amount of money.

The price of IDL is about 50% higher than I would expect to pay for the
platforms that I use.  This also goes for IDL for Windows--I fully expected
that to come in for less than $1000.  Of course there are generous discounts
when buying multiple copies, but that isn't always possible or practical to
arrange.

I would like to stress that this represents my opinion only.  I do not speak
for anybody but myself, in particular I do not speak for the NASA Goddard Space
FLight Center, or the Laboratory for Astronomy and Solar Physics.

Bill Thompson
Newsgroups: comp.lang.idl-pvwave
From: mcgraw@sunspot.sunspot.noao.edu (Robert McGraw)
Subject: IDL and X and PS
Keywords: idl X PostScript
Organization: National Solar Observatory/SP, Sunspot NM, USA
Distribution: na
Date: Mon, 14 Sep 92 20:47:50 GMT

I am looking for any information and/or procedures that make it
eash to stay with the same coordinates system when going from
set_plot,'x to/from set_plot,'ps' in IDL.

For example, it seems that tv and xyouts uses a different coordinate
system in PostScript then when in the X environment.

Is there a way to make a procedure work the same when in X or PS
without having to make a lot of changes?


Thanks
Robert






-- 
------------------------------------------------------------------------
Robert P. McGraw, Jr.    
System Manager                 INTERNET:rmcgraw@sunspot.sunspot.noao.edu
National Solar Observatory/SP  SPAN: 5355::RMCGRAW or NOAO::RMCGRAW
Newsgroups: comp.lang.idl-pvwave
From: pat@jaameri.gsfc.nasa.gov (patrick m. ryan)
Subject: need color contouring routine
Keywords: not polycontour
Reply-To: pat@jaameri.gsfc.nasa.gov (patrick m. ryan)
Cc: pat
Organization: Oceans & Ice Branch, NASA/GSFC/STX
Distribution: na
Date: Thu, 10 Sep 1992 17:14:10 GMT


Does anyone have a color contouring routine which is better
than contour/polycontour?  Polycontour's inability to handle
unclosed contours is quite a handicap.  I use the trick of
adding the extra row of data around the border to compensate
but that often results in garbage around my plots, especially
with small datasets.

I could also use a better version of map_set.  I do a lot
of plotting over the Arctic and I get some bizarre results
with land masses which overlap the borders of my range.

thanks,
pat

--
                                                             patrick m. ryan
     nasa / goddard space flight center / oceans and ice branch / hughes stx
                     pat@jaameri.gsfc.nasa.gov / zmpmr@charney.gsfc.nasa.gov
From: black@breeze.rsre.mod.uk (John Black)
Newsgroups: comp.lang.idl-pvwave
Subject: E-mail address of RSI or PVI to send bug reports/suggestions to
Date: 9 Sep 92 16:41:02 GMT
Reply-To: jvb@uk.mod.hermes
Distribution: comp.lang.idl-pvwave
Organization: Defence Research Agency

Does anyone know if there is an E-mail address where you can send bug reports
or suggestions to for IDL or PV~WAVE. I'm a PV~WAVE user, So I'm more interestedin the latter, but I thought I'd raise the question for both packages.

					John Black.

						jvb@uk.mod.hermes
 
Newsgroups: comp.lang.idl-pvwave
From: zawodny@arbd0.larc.nasa.gov (Dr. Joseph M Zawodny)
Subject: Color Contouring Proceedure
Organization: NASA Langley Research Center, Hampton, VA
Distribution: comp.lang.idl-pvwave
Date: Fri, 11 Sep 1992 14:41:04 GMT

	There was an immediate response to my offer of a color contouring
routine, so I will post it.   It comes in two parts, CONTTW.PRO and EXPAND.PRO,
both of which have been tested to a fair degree.  You may hack these to bits as
you see fit.  I have indicated areas of CONTTW where you may wish to change
things (such as color tables, what is black and what is white etc.) with a
comment line containing ****.  Play with it for awhile before declaring that a
"feature" is a bug.
	EXPAND.PRO performs a two dimesional stretch (or shrink) of an array of
any size to any size via a bilinear interpolation (sort of like the way
CONGRIDI was supposed to work).  Currently the result is always a floating
point array although the input may be anything.  There is some interesting
manipulations of subscripts in this routine which may be of general interest to
the newcommer to IDL.  See if you can figure out why it works.

	Have fun but don't blame me.

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
 Joseph M. Zawodny   (KO4LW)                      NASA Langley Research Center
 zawodny@arbd0.larc.nasa.gov                      MS-475,    Hampton VA, 23681
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

Newsgroups: comp.lang.idl-pvwave
From: rivers@bnlux1.bnl.gov (mark rivers)
Subject: Re: NetCDF support within IDL
Organization: Brookhaven National Laboratory, Upton, NY 11973
Distribution: usa
Date: Wed, 9 Sep 1992 02:45:03 GMT

I have just finished implementing the complete netCDF library from
within IDL on VAX/VMS systems. I used the call_external routine to call
the C netCDF library which I linked as a shareable image. This could be
done quite simply for many Unix systems (SunOS, AIX, HP, etc.), although
one additional layer of C interface routines is needed under Unix.

I wrote IDL "wrapper" procedures with the same names as the netCDF C
routines, so the calling interface is almost identical to that
documented in the NetCDF User's Guide. The IDL routines do a lot of
bookeeping, type conversions, etc. which considerably ease the
programmers task compared to writing in C.

Anyone interested in getting what I have done let me know. I am
aware that netCDF is going to be added to IDL directly soon, but I wanted
to get started now. My routines should also work fine from PV-WAVE
wheras PV-WAVE may never have direct support for netCDF.


-- 
Mark Rivers                              (516) 282-7708 or 5626
Building 815                             rivers@bnlx26.nsls.bnl.gov (Internet) 
Brookhaven National Laboratory           rivers@bnl (Bitnet)                   
Upton, NY 11973                          BNLX26::RIVERS  (Physnet)             
Newsgroups: comp.lang.idl-pvwave
From: gmhm@pvi.UUCP (Mike Mayer)
Subject: Sig Proc: Phase Delay
Organization: Precision Visuals Inc., Boulder, Colorado
Date: Mon, 14 Sep 1992 19:12:02 GMT

I am posting this for a colleague of mine.  Please respond
directly to her if anybody has any input:

Mary Verkade, Sr. Technical Support Engineer
verkade@pvi.com
Phone: 209-892-7198

The question:

Does anyone have any WAVE/IDL routines that will allow someone
doing signal processing to calculate Phase Delay and Group Delay
of a signal(s)?

Thanks very much.

Mike Mayer
PVI

-- 
^-_-^-_-^-_-^-_-^-_-^-_-^-_-^-_-^-_-^-_-^-_-^-_-^-___Catch the WAVE___-^-_-^-_-
Mike Mayer - Senior Technical Support Engineer
Precision Visuals, Inc.  32915 Aurora Rd., Suite 160, Solon OH  44139  USA 
Email: gmhm@pvi.com    Human: 216/248-4900    Fax: 216/248-2733
From: zawodny@arbd0.larc.nasa.gov (Dr. Joseph M Zawodny)
Newsgroups: comp.lang.idl-pvwave
Subject: Re: need color contouring routine
Keywords: not polycontour
Date: 11 Sep 92 11:51:21 GMT
Distribution: na
Organization: NASA Langley Research Center, Hampton, VA


	I have a color contouring (imaging) routine which generates a color
image of an array and places a set of axies and titles along with a color bar.
The color bar has its own axis and title.  The bar may be located on any of the
four sides via keywords.  The routine also handels log axies as well as log
data and color bar.  It can be asked to overlay a line contour as well.  It now
handels missing data as well!  While it supports X and PS devices it does have
at least one limitation, it does not currently work with !p.multi.  It is very
long at least for IDL programs (8-10 pages of reasonably well documented code)
and has at least one extra routine (EXPAND - a CONGRIDI that really works!)
that it likes to have. If I get at least five requests for it then I will
consider posting it to this group. I also have my own map drawing routines
which predate the IDL routines and do not use the snazzy transformations
(!p.t=2), but IMHO are somewhat easier to use if you just want to overlay a
map.  My map routine support 8 or so of the more common projections and I also
have a routine which allows the user to overplot or convert between map and
device coordinates.

	If interested please send e-mail to

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
 Joseph M. Zawodny   (KO4LW)                      NASA Langley Research Center
 zawodny@arbd0.larc.nasa.gov                      MS-475,    Hampton VA, 23681
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

This code will be provided as is and is well documented enough for a typical
IDLer to hack to suit their needs.
Newsgroups: comp.lang.idl-pvwave
From: jjb@beta.lanl.gov (Jeffrey J Bloch)
Subject: Multidimensional Histograms re-visited
Organization: Los Alamos National Laboratory
Date: Sat, 5 Sep 1992 21:30:45 GMT


In article <27AUG199209562770@stars.gsfc.nasa.gov> you write:
>In article <1992Aug27.075540@highwire.gsfc.nasa.gov>,
>burel@highwire.gsfc.nasa.gov (Jonathan Burelbach) writes...
>
>>Help!  I am trying to create a scatterplot of 2 Landsat Image bands (ie 
>>band 4 vs band 5) for clustering purposes and I need to be able to determine
>>the density of points on the plot.  I have tried to create a 256x256 z array
>>by looping through the images, but this takes forever with images of any 
>>size.  Does anyone have any suggestions?
>
>This may do what you want.  It uses HISTOGRAM to cut down on some of the
>looping.
>
>Bill Thompson
>-------------------------------------------------------------------------------
>	PRO FORM_HISTO2,X,Y,HISTO,XSTEPS,YSTEPS,XDELTA,YDELTA

	(code here left out)


If I understand the intent of the question and the response, I think there
is a cleaner and simpler way to do this. I have imbedded this technique
in several codes so I don't have a stand alone routine to offer, but what
follows is an outline of the technique:

	x = array of x values
	y = array of y values
	minx = minimum x value for x histogram axis
	maxx = maximum x value for x histogram axis
	miny = ditto for y etc.
	maxy = ditto for y etc.
	nx = number of histogram bins on the x axis
	ny = number of histogram bins on the y axis


IDL code in outline form:

	(Note: I usually deal with integer data for this problem so you
	  might want to pay attention to rounding issues here more than
	  I have....)

	ix=long(nx*(x-minx)/(maxx-minx))
	iy=long(ny*(y-miny)/(maxy-miny))
	good=where((ix ge 0) and (ix lt nx) and (iy ge 0) and (iy lt ny))

	(If good(0) eq -1  quit at this point....)

	ixy=ix(good)+(iy(good)*nx)

	hist=histogram(ixy,min=0l,max=nx*ny-1,binsize=1)

	hist=reform(hist,nx,ny)



And we are done. Note that there is no looping at all!!!
Hope this helps.

					Jeff Bloch
					Space Astronomy and Astrophysics Group
					Los Alamos National Laboratory
Newsgroups: comp.lang.idl-pvwave
From: avourlid@nrao.edu (Angelos Vourlidas,,,)
Subject: Help: ARL routines & view settings
Reply-To: avourlid@nrao.edu
Organization: National Radio Astronomy Observatory
Date: Wed, 9 Sep 92 20:28:02 GMT

Hello everybody,
	I'm trying to use the ARL routines in v4.0 PV~WAVE in order to visualize the
motion of 2-3 spheres attached to springs.For now I'm doing this in 2D and it seems
to work fine. However, I'd like to able to give a 3D appearance in the system but I'm
not able to understand how CENTER_VIEW or SET_VIEW3D work. I'm using POLY_SPHERE &
POLY_SHADE to create the spheres and then T3D,trans=[..] to move them in the x-y plane
finally stacking each position in an animation array. Whenever I try to set the view 
with another pespective or viewvector etc I get that POLYSHADE error: vertex # out of
range. There must be some easy way to keep the vertex in range so one could be able to
move around the spheres.
	One other educational application would be a solar system showing the planets
revolving around the sun where one could move in and out of the ecliptic or zoom to a planet and see its satellites as they revolve around it. I believe that it's feasible using the rendering routines and fun,too!
	Any suggestions would be greatly appreciated

Sincerely,
Angelos Vourlidas
avourlid@nrao.edu
From: thompson@stars.gsfc.nasa.gov (William Thompson, code 682.1, x2040)
Newsgroups: comp.lang.idl-pvwave
Subject: Re: Help: Coding iterative algorithm elimimating loops in IDL/PV~WAVE
Keywords: Vector Quantiser, Continuous Training Algorithm, Coding
Date: 11 Sep 92 14:41:00 GMT
Distribution: comp.lang.idl-pvwave,comp.ai.neural-nets,comp.dsp,comp.compression,comp.compression.research
Organization: NASA/GSFC-Laboratory for Astronomy and Solar Physics
News-Software: VAX/VMS VNEWS 1.4-b1

In article <BuBCF5.IEC@breeze.rsre.mod.uk>, jvb@uk.mod.hermes writes...

>Has anyone got an idea how to implment the following algorithm in IDL/PV~WAVE
>that DOESN'T use for loops. The reason for the avoidance of for loops is
>because, as everyone should know, for loops are slow. ...

I haven't put the time in to entirely understand your application, but when you
say ...

>4) Repeat steps 1 to 3 until the total error is acceptably small, or doesn't
>   change significantly

and

>2) Is there a fast way to implement iterations in IDL/PV~WAVE, ie one that
>   avoids do loops?

I would have to say no.  At some point you have to decide whether or not you've
converged, or whether you have to reiterate.  At that point you have to loop.
IDL does have tricks to avoid explicite loops in certain common vector
manipulations, but when you add a completeness test, then you can't avoid
looping for each reiteration.

I'm assuming that you have a large number of reiterations to process, but that
the code has been optimized so that you're not looping within the iteration, or
otherwise have inefficient code.

Bill Thompson
From: esagawa@cc.crl.go.jp (Eiichi SAGAWA)
Newsgroups: comp.lang.idl-pvwave
Subject: idl-pvwave-mode for emacs
Date: 10 Sep 92 09:59:20 GMT
Distribution: comp
Organization: Communications Research Laboratory


Does anyone know whether idl.el for emacs LISP code exists?  If this
is available, as anybody who use EMACS in writing IDL code could
imagine, it's a great help.

--

                            Eiichi SAGAWA (Communications Research Lab.)
                            esagawa@cc.crl.go.jp    CRLSMS::SAGAWA 
                            (INTERNET)              (DECnet/NSI)
                            fax: 81-423-27-6657     tel: 81-423-27-7550
Newsgroups: comp.lang.vhdl,comp.lsi.cad,comp.lang.verilog
From: jab3@cec2.wustl.edu (John Alonzo Breen)
Subject: Re: extended integer size?
Organization: Washington University, St. Louis MO
Date: Tue, 8 Sep 1992 17:48:07 GMT

In article <mike.kopp-080992123255@kopp.gatech.edu> mike.kopp@gtri.gatech.edu (Mike Kopp) writes:
>I am working on a high-level design in which I use integer variables.  Some
>of the variables can have up to 16 bits (unsigned) so that if multiply two
>of them the result could be 32 bits unsigned.  My vhdl implementation uses
>32-bit integers so the largest unsigned integer is 31 bits so I cannot
>represent the result using standard integers.  Has anyone implemented a
>portable "integer-like" type to extend the integer size to some arbitrary
>but fixed length?  Has anyone any suggestions as to how I should proceed?

I can tell you what I did in one case, but I don't know if it was the
"smartest" way.

A few years ago, I wanted to write a VHDL random number package.  To
simplify verification, I decided to emulate the Unix erand48 function,
which uses a 48-bit seed.  I made the seed type a 4-element array of
integers (12 bits per element), and did piecewise multiplication and
addition (division may be a little tricky - I didn't think about it
since I didn't need it).  You should be able to do something similar.
--
-- 
John A. Breen                   |
jab3@cec1.wustl.edu             | This space unintentionally left blank
From: pascal@lorelei.grenoble.hp.com (Pascal REGACHE)
Date: Thu, 10 Sep 1992 14:13:10 GMT
Subject: IEEE1164 package, Where ?
Organization: Hewlett-Packard, GND
Newsgroups: comp.lang.vhdl

I am looking for a ftp site where I can get the logic package 
approved by the IEEE, also known as IEEE 1164.

Thanks for any info
Pascal
Newsgroups: comp.lang.vhdl