HDTenEightyP/NetNews huggingface dataset:
From: dpkemp@afterlife.ncsc.mil (David P. Kemp)
Newsgroups: comp.lang.idl-pvwave
Subject: Re: signal processing package for IDL
Date: 25 Jul 92 14:23:50 GMT
Organization: The Great Beyond

In article <ghsu.711219193@critical> ghsu@critical.nswc.navy.mil () writes:
>I am interested in finding procedures for signal processing (design of
>filters, filtering, etc), similar to the signal processing toolbox for
>matlab), for IDL.   Is there something like that in existence?    Is
>there such package available for pvwave?   Any pointer will be
>appreciated. 
>
Don't get your hopes up.  Filter design is probably best done by
a specialized application (there are lots of them), but it would be
nice to do the actual filtering in PV-wave.

Unfortunately, the technical support person I talked to at PVI didn't
know anything about filters, not even the vocabulary.  I asked if there
was any primitive to support Infinite Impulse Response (variously known
as Auto Regressive, or Recursive) filters, and this person didn't know
what I was talking about.

FIR filtering is, of course, supported by PV-wave's convolution operation,
but there doesn't seem to be any operation for doing recursive filters
without doing it sample-by-sample with an explicit loop - horribly slow.

Question for the net:  Am I missing something in the documentation?
IIR is a term used by DSP people, AR is used by statistics people.  Is
there some other term used in Geology, or Fluid Dynamics, or whatever,
that I should have been asking for?


-- 
   Dave Kemp   dpkemp@afterlife.ncsc.mil 
-----------------------------------------------------------------------------
"The use of history as therapy means the corruption of history as history."
    -- Arthur Schlesinger          (quote stolen from Chet Ramey, CWRU)
From: dpkemp@afterlife.ncsc.mil (David P. Kemp)
Newsgroups: comp.lang.idl-pvwave
Subject: Re: Colors with XOR plotting: How to do it
Date: 25 Jul 92 15:31:51 GMT
Organization: The Great Beyond

An alternative to XOR that may be useful is using drawing surfaces.
For example if you have a red line and you want to slide a blue disc
along it, you may do so by drawing them on separate surfaces.  Depending
on your colormap assignment, the disk is made to appear either above
or below the line.

As an example, assume you have a background axis with a red line, yellow
tick marks, and green labels.  You want to slide a blue marker along
below the axis.  Set up your two surfaces as follows:

   Surface 1 (Axis)       Surface 2 (Marker)         Colormap
Write mask:    011                       100       000  Gray
  Transparent   00    Background (grey)  0         001  Red
  Red           01    Marker (blue)      1         010  Yellow
  Yellow        10                                 011  Green
  Green         11                                 100  Blue
                                                   101  Red
						   110  Yellow
						   111  Green

To make the marker appear on top of the axis, just change the
last three entries in the colormap to all be Blue.  That has the
interpretation of Axis color 00 = Gray, and Marker color 0 = Transparent.

The only trick here is to figure out from the manual how to set the
write mask.  If the mask is 011, drawing operations affect just the
axis surface; if it is 100, they affect just the marker surface.
Use normal (Source) drawing mode instead of XOR, and when moving
the marker, you can just erase the whole surface, or redraw the
marker in the background color, whichever turns out to be faster.

This technique can be used for any number of independent surfaces
as long as the sum of the bits in the surfaces doesn't exceed the
number of bits in your colormap.  (For example an 8 bit colormap
(256 colors) can support 8 separate 1 bit surfaces, or 2 4 bit 
surfaces, or the usual 1 8 bit surface.)

----

With regard to a previous poster's acerbic comment, I agree that
the net is no substitute for reading the manuals and playing around
(oops, conducting research), but I have often been in the position
of having spent hours or days working on something because I missed
something or wasn't aware of a particular technique.  Mr. Austin
didn't appear to be lazy, just inexperienced.  We can all learn
from each other - let's keep the flame wars in alt.politics.greek
and news.admin.

-- 
   Dave Kemp   dpkemp@afterlife.ncsc.mil 
-----------------------------------------------------------------------------
"The use of history as therapy means the corruption of history as history."
    -- Arthur Schlesinger          (quote stolen from Chet Ramey, CWRU)
Newsgroups: comp.lang.idl-pvwave
From: murtagh@stsci.edu (Fionn D. Murtagh)
Subject: Poisson noise generator
Originator: murtagh@sol.stsci.edu
Organization: Space Telescope Science Institute
Date: Thu, 30 Jul 1992 14:13:27 GMT

Hi IDLers,

I am looking for a Poisson noise generator that takes a 1D or 2D array as 
input and returns a noisified version of it according to the Poisson 
distribution. (The input is taken as defining the mean at every pixel.)

I am surely not the first one to consider this problem. Is there 
a ready-to-use IDL-routine out there that I could pull over?

If I get more than one reply, I'll summarize.

Since I am not regularly reading this bulletin board I would appreciate 
answers to be mailed to adorf@eso.org on the Internet.

Thanks.

Hans-Martin Adorf
Space Telescope - European Coordinating Facility
Garching, FRG
From: dpkemp@afterlife.ncsc.mil (David P. Kemp)
Newsgroups: comp.lang.idl-pvwave
Subject: Re: signal processing package for IDL
Date: 30 Jul 92 12:56:24 GMT
Organization: The Great Beyond

In article <14663@umd5.umd.edu> dmatthews@uap.umd.edu writes:
>If you don't have to do your filtering in real time, do it in the
>frequency domain, i.e. take the Fourier transform of the data,
>_multiply_ the result by the desired transfer function, and transform
>that result back to the time domain.  It's faster and easier to understand
>than filtering in the time domain directly.  
>

I'm certain it isn't faster.
It may or may not be easier to understand.
I don't believe it is even possible to do exactly.

Everyone :-) knows that convolution in the time domain is equivalent
to multiplication in the frequency domain, which is the basis for
Fourier transform filtering.  This works well if your filter has a
relatively large, but finite length impulse response.

If the impulse response is short, filtering in the time domain takes
much less computation than doing a forward and inverse FFT.

If the impulse response is infintely long (such as you might get 
with even a tiny single pole-pair filter, if the poles are near the
unit circle), I don't know if it is even possible to do the filtering
using FFT's.  If it is possible, then keeping track of the filter
state to enable reconstruction of the time domain signal from the
Fourier transform blocks is a nightmare.

Here is how to filter L samples of a signal X, producing signal Y, using
an all-pole filter of length N, in the time domain:

   do i = 1, L
      y(i) = x(i)
      do j = 1, N
         y(i) = y(i) + filt(j)*y(i-j)
      end do
   end do

I doubt that an FFT based filter could be any easier to understand than
that (but perhaps I am left-brained and you are right-brained, and "easy"
is in the eye of the beholder :-).

-----

My complaint with PVI is that they don't seem to realize that all-pole
filters even exist.  It seems like it would be easier for PVI to add
an IIR filter primitive to PV-wave, than for MathWorks to add good
graphics to Matlab!

Mr. Anderson's package to link Matlab and PV-wave sounds excellent,
and it would be great to have it included with the PV-wave distribution,
but I'd hate to tie up *two* expensive licenses on a routine basis
just so the user could do filtering and good graphics simultaneously.

-- 
   Dave Kemp   dpkemp@afterlife.ncsc.mil 
-----------------------------------------------------------------------------
"The use of history as therapy means the corruption of history as history."
    -- Arthur Schlesinger          (quote stolen from Chet Ramey, CWRU)
Newsgroups: comp.lang.idl-pvwave
From: knight@ll.mit.edu (Fred Knight)
Subject: SUMMARY: formatted printing of structures
Originator: knight@ll.mit.edu (Fred Knight)
Keywords: print,string
Reply-To: knight@ll.mit.edu (Fred Knight)
Organization: Group 45, MIT Lincoln Lab.
Date: Tue, 28 Jul 92 20:33:52 GMT


In an earlier posting (~10 Jul) I considered the inconsistent results of
printing elements of a structure.  This posting summarizes the results,
including a reply from RSI.

The problem is exemplified by the following:

IDL> t={a:0,b:1,c:2}
IDL> print,format='(3f10.2)',t           ; BAD---NOT ON ONE LINE
      0.00
      1.00
      2.00
IDL> print,string(format='(3f10.2)',t)   ; BAD---f11.2 FOR 2ND AND 3RD TAGS
      0.00       1.00       2.00
IDL> print,format='(3f10.2,$)',t & print ; OK---WHAT I WANTED
      0.00      1.00      2.00

In brief, this behavior will be corrected in the next version (> 2.3.2) so
that all three statements produce the same results.  The explanation from
RSI is the following.

> When printing a variables, IDL decomposes each structure into its
> non-structure components, and then prints all of the components
> according to the format statement or the default formatting.

> There was a problem with the way IDL decomposed the structure into
> its components.  Instead of treating all the components as part
> of the same variable, it treated them as separate variables.  This
> caused the first example shown above to produce three separate lines
> rather than a single line.

> The IDL routine STRING also uses the same method to deal with variables,
> so the same problem caused STRING to create a string array of three
> elements rather than one string.  When the elements of the string array
> are printed they are padded with a single space which explains the output
> from the second example above.  This can be seen clearly by using the
> following IDL statement:
>    help, string(format='(3f10.2)',t)

> The problem with the decomposition of structure variables has been fixed,
> and will be available in the next version of IDL after IDL V 2.3.2.

Thanks to the people who contributed the solution of using the $ format.

Fred
-- 
=Fred Knight (knight@ll.mit.edu)	(617) 981-2027
 C-483\\MIT Lincoln Laboratory\\244 Wood Street\\Lexington, MA  02173
From: dmatthews@uap.umd.edu
Newsgroups: comp.lang.idl-pvwave
Subject: Re: signal processing package for IDL
Date: 26 Jul 92 20:10:52 GMT
Reply-To: dmatthews@uap.umd.edu
Organization: IPST, U. of Maryland, College Park

In article <1992Jul25.142350.26849@afterlife.ncsc.mil>, dpkemp@afterlife.ncsc.mil (David P. Kemp) writes:
>In article <ghsu.711219193@critical> ghsu@critical.nswc.navy.mil () writes:
>>I am interested in finding procedures for signal processing (design of
>>filters, filtering, etc), similar to the signal processing toolbox for
>>matlab), for IDL.   Is there something like that in existence?    Is
>>there such package available for pvwave?   Any pointer will be
>>appreciated. 
>>
>Don't get your hopes up.  Filter design is probably best done by
>a specialized application (there are lots of them), but it would be
>nice to do the actual filtering in PV-wave.
...
If you don't have to do your filtering in real time, do it in the
frequency domain, i.e. take the Fourier transform of the data,
_multiply_ the result by the desired transfer function, and transform
that result back to the time domain.  It's faster and easier to understand
than filtering in the time domain directly.  

Dr. David L. Matthews, IPST, Univ. of Maryland, College Park MD 20742-2431 
Telephone  (301)405-4830	Internet   dmatthews@uap.umd.edu
FAX 	   (301)314-9363	NSI/SPAN   UMDUAP::DMATTHEWS
Newsgroups: comp.lang.idl-pvwave
Newsgroups: comp.lang.vhdl,comp.lang.verilog,comp.specification
Subject: Specification languages for hardware description languages
From: dsims@leo.ece.uc.edu (D. Lyle Sims)
Date: Tue, 28 Jul 1992 17:23:54 GMT
Organization: University of Cincinnati

I'm curious what people use as specification languages for hardware
description languages such as VHDL.  Gate level descriptions?  Anything
else?  Anything with a formal syntax and semantics?
-- 
D. Lyle Sims                    Dept. of Electrical and Computer Engineering
dsims@thor.ece.uc.edu           University of Cincinnati
(513) 556-2499                  Cincinnati OH  45221-0030
                                USA
From: doug@hpscit.sc.hp.com (Doug Sojourner)
Date: Fri, 24 Jul 1992 23:58:51 GMT
Subject: Re: Resolved signals
Organization: Hewlett-Packard, Santa Clara, CA
Newsgroups: comp.lang.vhdl

In comp.lang.vhdl, jmessenger@cix.compulink.co.uk (John Messenger) writes:

> subtype RTYPE is RESOLVED INTEGER;
> type ARR is ARRAY (0 to 1) of RTYPE;
> signal S: ARR;

> I know that RTYPE is a resolved subtype.

RTYPE is resolved if RESOLVED is a function with one argument
of type array(INTEGER range <>) of INTEGER, which returns INTEGER.
RESOLVED is not a keyword which makes signals resolved.

> is S    a resolved signal? 

Under the conditions above, S would be a resolved signal

>     John Messenger (jmessenger@cix.compulink.co.uk) Tel: +44 904 692700

Doug Sojourner (dsojourner@cdc.hp.com)
Newsgroups: comp.lang.vhdl
From: jab3@cec2.wustl.edu (John Alonzo Breen)
Subject: Pin numbers in VHDL descriptions
Organization: Washington University, St. Louis Mo.
Date: Tue, 21 Jul 1992 21:13:46 GMT

Has anyone come up with a "standard" way of adding pin number info to
a VHDL component?  I assume that it could be done with attributes
(although in the 3+ years I've been using VHDL, I've never done
anything with user-defined attributes :-), but I can see where there
might be some problems, particularly if a port is an array.

If anyone has any suggestions, I would appreciate hearing from you.

Thanks.
--
John A. Breen                   |
jab3@cec1.wustl.edu             | This space unintentionally left blank
johnb@hobbes.mdc.com            |
Tel: (314)234-4341              |
Newsgroups: comp.lang.vhdl
From: garp@isy.liu.se (Johan Garpendahl)
Subject: Is there VHDL for the Mac?
Organization: Dept of EE, University of Linkoping
Date: 21 Jul 92 07:11:13 GMT

As you might have guessed, I wonder if anyone knows if there
is such a thing as a VHDL compiler for the Macintosh.

Thanks,

	Johan

-- 
Johan Garpendahl                   | Email: garp@isy.liu.se
Linkoping University               | Phone: +46 - 13 - 28 13 24
Dept. of Electrical Engineering    | Fax  : +46 - 13 - 13 92 82
S-581 83  LINKOPING // SWEDEN      | This space is left blank.
Newsgroups: comp.lang.vhdl
From: jmessenger@cix.compulink.co.uk (John Messenger)
Subject: Resolved signals
Reply-To: jmessenger@cix.compulink.co.uk
Date: Fri, 24 Jul 1992 13:11:00 +0000


Here are a couple of apparently simple questions, but I can't find the
answers in the LRM or the interpretations:

subtype RTYPE is RESOLVED INTEGER;
type ARR is ARRAY (0 to 1) of RTYPE;

signal S: ARR;

I know that RTYPE is a resolved subtype.  But
is S    a resolved signal?   (I believe not)
Is S(0) a resolved sigal?    (Who knows?)

        -- John Messenger (jmessenger@cix.compulink.co.uk)
--
    John Messenger (jmessenger@cix.compulink.co.uk) Tel: +44 904 692700
From: jwithana@tan.cit (Janaka Withana, 402 Feinberg Hall, (609) 258-8811,)
Newsgroups: comp.lang.vhdl
Subject: Re: Resolved signals
Date: 31 Jul 92 20:07:30 GMT
Reply-To: jwithana@tan.cit
Organization: Princeton Univeristy

In article 1407@clsi.COM, shankha@clsi.COM (Shankha Mitra) writes:
> 
> In article <48320002@hpscit.sc.hp.com>, doug@hpscit.sc.hp.com (Doug Sojourner) writes:
> > In comp.lang.vhdl, jmessenger@cix.compulink.co.uk (John Messenger) writes:
> > 
> > > subtype RTYPE is RESOLVED INTEGER;
> > > type ARR is ARRAY (0 to 1) of RTYPE;
> > > signal S: ARR;
> > 
> > > is S    a resolved signal? 
> > 
> > Under the conditions above, S would be a resolved signal
> > 
> 
> I disagree.  LRM 4.3.1.2 explicitly states:
>    If the name of a resolution function appears in the declaration of a
>    signal, or in the declaration of the subtype used to declare the
>    signal, then that resolution function is associated with the declared
>    signal.  Such a signal is called a resolved signal. 
> 
> Since ARR doesn't have a resolution function associated with it in its
> declaration, S is NOT a resolved signal.

but the sub-elements RTYPE of ARR do have a resolution function! 

> 
> You can declare S to be a resolved signal in two ways:
>    signal S: resolution_function ARR;
> or,
>    subtype RESOLVED_ARR is resolution_function ARR;
>    signal S: RESOLVED_ARR;
> 
> On the second method, the LRM 2.4 has the following to say:
>    If a resolved signal is of a composite type, and subelements of that
>    type also have associated resolution functions, such resolution
>    functions have no effect on the process of determining the resolved
>    value of the signal.

in this cases function resolution_function will "replace" the function RESOLVED that
resolves the sub-elements of ARR! 

> 
> So, it'll work okay.
> 
> Shankha
> 

aw, c'mon. get real. it is pretty darn obvious that S is a resolved signal!

type ARR is an array of RTYPE. since RTYPE is resolved, ARR is therefore resolved.
and S is resolved!

comments, anyone?

---
 -----------------------------------------------------------------------------
| jwithana@phoenix.princeton.edu                 janaka@lucille.princeton.edu |
| janaka@ee.princeton.edu      JWITHANA@PUCC.bitnet         bt283@po.cwru.edu |
 -----------------------------------------------------------------------------
Newsgroups: comp.lang.vhdl
From: mmccolli@ess.harris.com (Mike McCollister)
Subject: Bidirectional ports
Reply-To: mmccolli@ess.harris.com
Organization: Harris (Government Aerospace Systems)
Date: Tue, 21 Jul 1992 14:28:53 GMT

I'm in the process of writing a RAM model which requires the use of bidirectional
ports (with Hi-Z).  If anyone has any experience to share, I'd greatly appreciate it.

Mike

  _________________________________________________________________________
 /                                                                        /|
+------------------------------------------------------------------------+ |
|  _________                          |                                  | |
| |  _   _  | Michael J. McCollister  | Phone:  (407) 729-7054           | |
| |_| |_| | | Harris Corporation      | Email: mmccolli@ess.harris.com   | |
| |_/\/\/\|_| P.O. Box 94000          | ________________________________ | |
| | |_| |_| | Mailstop 100/4823       |                                  | |
| |_________| Palm Bay, Florida 32905 | I'm not going to say anything    | |
|                                     | stupid today.  Not!              |/
+------------------------------------------------------------------------+

Newsgroups: comp.lang.vhdl
From: shankha@clsi.COM (Shankha Mitra)
Subject: Re: Resolved signals
Originator: shankha@clsi
Organization: CAD Language Systems, Inc.
Date: Fri, 31 Jul 92 15:47:37 GMT


In article <48320002@hpscit.sc.hp.com>, doug@hpscit.sc.hp.com (Doug Sojourner) writes:
> In comp.lang.vhdl, jmessenger@cix.compulink.co.uk (John Messenger) writes:
> 
> > subtype RTYPE is RESOLVED INTEGER;
> > type ARR is ARRAY (0 to 1) of RTYPE;
> > signal S: ARR;
> 
> > is S    a resolved signal? 
> 
> Under the conditions above, S would be a resolved signal
> 

I disagree.  LRM 4.3.1.2 explicitly states:
   If the name of a resolution function appears in the declaration of a
   signal, or in the declaration of the subtype used to declare the
   signal, then that resolution function is associated with the declared
   signal.  Such a signal is called a resolved signal. 

Since ARR doesn't have a resolution function associated with it in its
declaration, S is NOT a resolved signal.

You can declare S to be a resolved signal in two ways:
   signal S: resolution_function ARR;
or,
   subtype RESOLVED_ARR is resolution_function ARR;
   signal S: RESOLVED_ARR;

On the second method, the LRM 2.4 has the following to say:
   If a resolved signal is of a composite type, and subelements of that
   type also have associated resolution functions, such resolution
   functions have no effect on the process of determining the resolved
   value of the signal.

So, it'll work okay.

Shankha

-------------------------------------------------------------------------------
Shankha S. Mitra                                               shankha@clsi.com
CAD Language Systems, Inc.				 uunet!clsi.com!shankha
5457 Twin Knolls Rd, Suite 101
Columbia, MD 21045					(410) 992-1716 ext. 226
-------------------------------------------------------------------------------
-- 

-------------------------------------------------------------------------------
Shankha S. Mitra                                               shankha@clsi.com
CAD Language Systems, Inc.				 uunet!clsi.com!shankha
Newsgroups: comp.lang.vhdl
From: fross@super.org (Bradley Kendall Fross)
Subject: Synopsys C-BMOD Interface Question
Organization: Supercomputing Research Center (Bowie, MD)
Date: Tue, 28 Jul 1992 16:03:35 GMT


I am using Synopsys, Inc.'s C-Behavioral Models Interface, and am running 
into trouble utilizing some of the routines for pin arrays.  The problem
arises when I use the sbmod_SetPinArrayLong().  

The syntax I use is very similar that in the "Synopsys VHDL System Simulator
Interfaces Manual", section 4, page 74, and is as follows:

====
%BMOD_INFO
	name	foo
	parm	integer	NUMBITS	32
	port    output  INDATA  event   -	NUMBITS
	port    input   OUTDATA event   -	NUMBITS
        ptr	long	array_ptr
%%
%BMOD_NOTE
%%
%BMOD_CODE

#include "bmod.h"
#include <stdio.h>
#include "cstyle2.h"
#include "bbus.h"

sbmod_foo_event()
{
  sbmod_iGetPinArrayLong(OUTDATA,array_ptr);
  printf("array_ptr value %08x\n",array_ptr[0]);
  sbmod_SetPinArrayLong(INDATA,array_ptr);
}

sbmod_foo_open() {
  array_ptr = sbmod_plAllocateBMODMemory(4); /* 4 bytes allocated */
}

sbmod_foo_close() {}
sbmod_foo_restart() {}
sbmod_foo_error() {}

%%

====
The error run-time message I get from the simulator is:

**Error: vhdlsim,9997:
    The second argument of sbmod_SetPinArrayLong must be an array.

The thing that seems strange to me is that sbmod_iGetPinArrayLong()
did not complain about the fact that I used the very same array as
in sbmod_SetPinArrayLong().  In fact, sbmod_iGetPinArrayLong() works
just fine, and the value displayed by the printf() is what I expected.

I am using the default MVL7_VECTOR in my structural vhdl code for the
component "foo" port map, and I think the number of bits here matches 
the NUMBITS parameter in the BMOD_INFO section of "foo.bmod" okay:

I used:  
	INDATA: MVL7_VECTOR(31 downto 0);
	OUTDATA: MVL7_VECTOR(31 downto 0);

Is the problem with the way I am using this sbmod_SetPinArrayLong()
routine, or is the problem somewhere else?

I would appreciate any assistance from any Synopsys C-BMOD users,
especially if you have working C_BMOD code I could peruse.

Thanks in advance.

Brad Fross (fross@super.org)
Supercomputing Research Center
Newsgroups: comp.lang.vhdl