HDTenEightyP/NetNews huggingface dataset:
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.lang.misc
Subject: Re: Ideas for time-series manipulation language
Keywords: time series, semantics
Date: 17 Aug 92 20:30:27 GMT
Organization: U. C. Berkeley
NNTP-Posting-Host: forney.berkeley.edu

In article <Bt3Jt3.3Kn.2@cs.cmu.edu> tgl+@cs.cmu.edu (Tom Lane) writes:
>I'm thinking about designing a language in which discrete time series are a
>fundamental data type.  I have vague memories of having seen similar ideas
>before, so I'm hoping someone can point me to prior work.

There are a couple of stream-oriented languages you should check out:
Lucid, which I think was first developed at SRI, and SIGNAL, developed at
INRIA, France by Benveniste, Le Guernic, and others.

>In trying to work out these ideas, I've run into some nasty problems of
>semantics, particularly when combining series having different time bases.
>How to make a reasonably efficient implementation is not obvious either.

Given this, you'll be more interested in the SIGNAL work, I think, which
deals quite a bit with different time bases and how to determine whether
systems with different time bases are consistent.



--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: comp.lang.misc
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: Ideas for time-series manipulation language
Keywords: time series, semantics
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: Tue, 18 Aug 92 05:18:43 GMT

In article <Bt3Jt3.3Kn.2@cs.cmu.edu> tgl+@cs.cmu.edu (Tom Lane) writes:
>I'm thinking about designing a language in which discrete time series are a
>fundamental data type.  I have vague memories of having seen similar ideas
>before, so I'm hoping someone can point me to prior work.
>
>The data I want to manipulate comes as series of observations taken at
>certain intervals of time (not necessarily the same interval for each series).
>I want to be able to refer to such a series as a single data object;
>to perform operations on such objects (eg, to add corresponding elements
>of two series to deliver a sum series), and to define functions that work
>on such objects (integration and correlation might be examples).  I want
>the functions to be able to work incrementally as new values are added to
>each data series (lazy evaluation might help here).
>
>In trying to work out these ideas, I've run into some nasty problems of
>semantics, particularly when combining series having different time bases.
>How to make a reasonably efficient implementation is not obvious either.

a. One of the main reasons that Reuters bought I.P. Sharp Associates
   (aside from their blathering about "the worth of the employees",
    who they have been butchering in periodic purges), was the
   IPSA "historical data bases", which are a large collection of
   time series data on energy, economics, transport, finance, etc.

b. These time series were stored as APL arrays, in the SHARP APL File
   System. Hmm. Still are. Reuters has not been able to figure out how
   to store them in another fashion efficiently.

c. APL has proven to be the most effective tool for manipulating,
   maintaining, correcting, and analyzing, these times series. 
   The functions you describe above sound fairly simple to do in APL 
   on time series.

d. I recommend you look at either SHARP APL/PC or J. Both are
   available free, via FTP from watserv1.waterloo.edu (cd /languages/apl/...)
   or with manuals, etc., from Iverson Software Inc, 33 Major St.
   Toronto.

e. J is an ascii-based language based on the Good Ideas of APL. 
    
   The Waterloo archive also has source code for J available. The APL
   code is unfortunately only available in binary form.


Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
Newsgroups: comp.lang.misc,comp.lang.logo,comp.lang.scheme,comp.lang.forth,comp.edu
From: jwb@eos.ncsu.edu (John W. Baugh Jr.)
Subject: Re: Small Language Wanted
Reply-To: jwb@eos.ncsu.edu
Organization: North Carolina State University
Date: Fri, 21 Aug 1992 14:44:44 GMT

Mike Coughlin writes:
>   As a user of Fortran, I must protest the idea that Fortran is an 
> old language. Since structured programming concepts were introduced
> into Fortran many years ago, there are no "modern" programming ideas
> that are need in Fortran to accomplish its purpose of scientific
> and mathematical computation. The mathematical notation used by 

Of course one can express "scientific and mathematical computations"
in Fortran, C, TeX, PostScript, etc.  However, the tremendous interest
in "object-oriented" programming among engineers and scientists shows
that they have finally come to realize that the structure and
organization of data are important---not exactly one of Fortran's
strong points.

--
John Baugh
jwb@eos.ncsu.edu
From: mwm@contessa.palo-alto.ca.us (Mike Meyer)
Newsgroups: comp.lang.misc
Subject: Re: PL/1 non-local goto versus setjmp/longjmp
Date: 15 Aug 92 21:39:50 GMT
Article-I.D.: contessa.mwm.1jk3
Distribution: world
Organization: Missionaria Phonibalonica
X-NewsSoftware: Amiga Yarn 3.4, 1992/08/12 15:49:52

In <id.VJBS.0DK@ferranti.com>, peter@ferranti.com (Peter da Silva) wrote:
> Personally, I'd prefer if C had no goto at all, but an organized system of
> contexts, so you could perform setjmp/longjmp operations within a routine.

I'm not quite sure what you mean by "organized system of contexts"? If
this mechanism would allows multilevel loop breaks. If not, I'd like
more details on it.

	<mike
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.lang.misc
Subject: Re: Origin of "dope vector"
Date: 23 Aug 92 11:34:02 GMT
Organization: CWI, Amsterdam

In article <ESH.92Aug20140859@boron.tekbspa.com> esh@boron.tekbspa.com (Edward S. Hirgelt) writes:
 > On 19 Aug 92 20:56:11 GMT,
 > rro@cs.ColoState.EDU (Rod Oldehoeft) said:
 > Rod>                                   The oldest reference I
 > Rod> have for this particular term is Gries' 1971 book, where
 > Rod> the reference is:
 > 
 > I'm not sure of the exact first use, but I first encountered ``dope
 > vector'' in reading the PL/I reference manuals for the OS 360 in late
 > 1969. Gries was at that time pretty IBM oriented so his use may have
 > derived from the same PL/I documentation. PL/I had already been around
 > for a while in 1969 so the terminology is prabably older. 
 > 
Certainly.  In front of me I have K. Sattley and P. Z. Ingerman, The
Allocation of Storage for Arrays in Algol-60, University of Pennsylvania
Report, AFOSR-TN-60-1320, November 1960.  On page 3 they say:
	Stored along with the elements of an array will be a "dope vector"
	containing the information necessary to reference the array (the
	parameters of the storage-mapping function).
But I do not know whether *that* is the first use.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland
dik@cwi.nl
Newsgroups: comp.lang.misc,comp.lang.logo,comp.lang.scheme,comp.lang.forth,comp.edu
From: oususalg@cs.montana.edu (Glassy)
Subject: Re: Small Language Wanted
Organization: Montana State University, Bozeman Montana USA
Date: Fri, 21 Aug 1992 15:37:33 GMT

In article <1992Aug21.144444.11414@ncsu.edu> jwb@eos.ncsu.edu writes:
!Mike Coughlin writes:
	[...Fortran works...]

!Of course one can express "scientific and mathematical computations"
!in Fortran, C, TeX, PostScript, etc.  However, the tremendous interest
!in "object-oriented" programming among engineers and scientists shows
!that they have finally come to realize that the structure and
!organization of data are important---not exactly one of Fortran's
!strong points.                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^

Have you taken a look at Fortran-90 lately?  If you have, you'll have
noted that the structure and organization of data are indeed strong
points in F90.  As far as the recent (1980-present) fashionable
interest in object-oriented this-and-that, F90 supports data-hiding via
modules, generic subprograms, operator and function overloading...

F90 is not a 'small language', but it is an excellent tool in its
appropriate application domain (science and engineering).  People seem
to be especially reluctant to 'update' their opinions regarding
Fortran, and casting the baby out with the bathwater is all too
common.

!--
!John Baugh
!jwb@eos.ncsu.edu


-- 
Lou Glassy (oususalg@cs.montana.edu)                  C Delenda Est
From: tgl+@cs.cmu.edu (Tom Lane)
Newsgroups: comp.lang.misc,comp.lang.functional,comp.dsp
Subject: Ideas for time-series manipulation language
Keywords: time series, semantics
Date: 16 Aug 92 22:00:39 GMT
Article-I.D.: cs.Bt3Jt3.3Kn.2
Followup-To: comp.lang.misc
Organization: School of Computer Science, Carnegie Mellon

I'm thinking about designing a language in which discrete time series are a
fundamental data type.  I have vague memories of having seen similar ideas
before, so I'm hoping someone can point me to prior work.

The data I want to manipulate comes as series of observations taken at
certain intervals of time (not necessarily the same interval for each series).
I want to be able to refer to such a series as a single data object;
to perform operations on such objects (eg, to add corresponding elements
of two series to deliver a sum series), and to define functions that work
on such objects (integration and correlation might be examples).  I want
the functions to be able to work incrementally as new values are added to
each data series (lazy evaluation might help here).

In trying to work out these ideas, I've run into some nasty problems of
semantics, particularly when combining series having different time bases.
How to make a reasonably efficient implementation is not obvious either.

So, if anyone can point me to related papers, language designs, working
systems, etc, I'd appreciate it.

-- 
			tom lane
Internet: tgl@cs.cmu.edu	BITNET: tgl%cs.cmu.edu@carnegie
Xref: sparky comp.lang.misc:2743 comp.lang.logo:163 comp.lang.scheme:2056 comp.lang.forth:2984 comp.edu:1289
From: gvw@epcc.ed.ac.uk (Greg Wilson)
Newsgroups: comp.lang.misc,comp.lang.logo,comp.lang.scheme,comp.lang.forth,comp.edu
Subject: Small Language Wanted
Date: 20 Aug 92 08:05:07 GMT
Organization: Edinburgh Parallel Computing Centre

[apologies if this is a re-post --- problems first time around]

Hello.  I am looking for a small language to use and modify for teaching
purposes.  Features I want include:

* small, simple implementation in C (at most one week for a senior
  student with a C/Unix background to read and understand source).

* very simple syntax --- preferably only a single syntactic form,
  like Scheme, Logo, and Forth.

* textual scoping of variables (which (sigh) rules out Logo itself)

* logical, integer, floating-point, and string data types (I'm
  happy to have single characters treated as 1-length strings)

Other features that would be nice include

* objects (something simple, like Object Logo, would do --- I
  regularly lambast physicists for using "old" languages like Fortran,
  so I feel I should set a good example for students by using some
  modern ideas myself)

* a source-language debugger

* the ability to cross-call C

Note that a compiler is not needed; performance is not a primary
concern, so interpretation would be fine. 

Any help would be much appreciated.

Thanks in advance,

 ========================================================================
  Gregory V. Wilson                    ||  For in much wisdom is much
  Technical Coordinator                ||  grief; and he that increaseth
  Edinburgh Parallel Computing Centre  ||  knowledge, increaseth sorrow.
  gvw@epcc.edinburgh.ac.uk             ||               - Ecclesiastes
 ========================================================================
Newsgroups: comp.lang.misc
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Small Language Wanted
Organization: Computer Science, University of Melbourne, Australia
Date: Sun, 23 Aug 1992 08:41:17 GMT

mbk@lyapunov.ucsd.edu (Matt Kennel) writes:

>mdchaney@fractal.ucs.indiana.edu (M Darrin Chaney) writes:
>: Not to fan a flame war, but indeed C++ is _excellent_ for working with
>: complex numbers, etc.  And, nobody will accuse you of using an outdated
>: language.
>
>C++:  complex A, B, C;
>
>C = A + B
>
>{ get A and B, call "+" operator.  Create new temporary structure for
>  result by calling complex constructor.  Run "+" operator. 
>  call overloaded "=" operator.  Copy into C. Delete temporary.}

The calls to operator "+" and operator "=" will be inlined.
Smart compilers (including Cfront) will optimize the temporary away.
The resulting object code is exactly the same as would result from
equivalent Fortran.

>And can C++ optimize
>
>for (i=1; i<1000; i++) {
>	<junk not altering A and B>
>	C = A + B
>	<more junk not altering A and B>
>	func(C)
>}
>
>by taking out C=A+B as a loop invariant?

Yes.

>How can it if the "+" and "=" operators could conceivably do *ANYTHING*
>which might possibly alter something else somewhere else.

These operators are declared as inline functions, so the
compiler can see exactly what they do and can thus make the
appropriate optimizations.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: gmt@CS.ARIZONA.EDU ("Gregg Townsend")
Newsgroups: comp.lang.icon
Subject: does VMS Icon problem affect you?
Date: 20 Aug 92 17:58:08 GMT
Distribution: inet
Organization: The Internet

We're unsure how widespread the VMS Icon installation problems are.
If you're having trouble installing VMS Icon 8.7, or are avoiding
it because of the problem, please let us know by email to
icon-project@cs.arizona.edu or uunet!arizona!icon-project.

To recap, the problem is that neither the compiler nor the interpreter
will run under VMS if the file SYS$SHARE:DECW$XLIBSHR.EXE is absent.
This is the shared library for DecWindows (X Windows).

A short note from anyone who's succeeded with the installation would
also be appreciated.

    Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
    +1 602 621 4325     gmt@cs.arizona.edu     110 57 16 W / 32 13 45 N / +758m

Newsgroups: comp.lang.icon
From: ppetto@wariat.org (Peter J. Petto)
Subject: Icon Question(s)
Organization: Akademia Pana Kleksa, Public Access Uni* Site
Date: Thu, 20 Aug 1992 20:11:00 GMT

I'm trying to learn Icon, and have run into a little roadblock.  I'm
hoping that someone here might help me get unstuck.  I'm starting by
trying to convert an old SNOBOL routine to Icon.  The routine I'm
working on is as follows:

*
*   CHOP USENET FILE INTO MORE READABLE FORM
*
     &ANCHOR = 1
     &TRIM = 1
       HONE = 'Article: '
       HTWO = 'From: '
     HTHREE = 'Subject: '
      HFOUR = 'Date: '
      HFIVE = 'Organization: '
       SONE = 'From ncoast'
       STWO = 'From usenet'
     STHREE = 'From wariat'
     HMATCH = HONE | HTWO | HTHREE | HFOUR | HFIVE
     SMATCH = SONE | STWO | STHREE
*
*
     INPUT('READLINE', 5, 1024)
     OUTPUT('PRINT', 6, 1024)
*
*
HREAD LINE = READLINE                             :F(END)
      EQ(0,SIZE(LINE))                            :S(BREAD)
      LINE HMATCH                                 :F(HREAD)
      PRINT = LINE                                :(HREAD)
*
*
BREAD PRINT = LINE
BLOOP LINE = READLINE                             :F(END)
      LINE SMATCH                                 :S(HREAD)
      PRINT = LINE                                :(BLOOP)
*
END


One of my first attempts at an Icon equivelant is as follows:

#  unet.icn
#
#     filter Usenet news headers
#     for printing and reading
#

global Mode

procedure main()
   Mode := "header"
   while line := read() do
      if Mode := "header"
         then head(line)
         else body(line)
   end


procedure head(line)
   if match("Article: " | "Date: " | "From: " | "Organization: " | "Subject: ", line) then write(line)
   if *line = 0 then { write(line); Mode := "body" }
   end


procedure body(line)
   if match("From ncoast" | "From usenet" | "From wariat", line)
      then Mode := "header"
      else write(line)
   end


This Icon program seems to filter the headers properly, but I'm not
getting any body text through.  I'm stumped and KNOW that I'm missing
something obvious.  Please help me!  I'd also appreciate some advice
as to rephrasing the match patterns as co-expressions -- assuming
that this would be a better method.

(I think if I get this one right, I should be able to translate the
rest of my routines.)  Thanks in advance for any and all help.

---
Peter Petto          |       ppetto@wariat.org
Bay Village, Ohio    |    73125.617@compuserve.com
From: janpeter@mpi.kun.nl (Jan Peter de Ruiter)
Newsgroups: comp.lang.icon
Subject: list scanning
Date: 20 Aug 92 14:57:09 GMT
Distribution: inet
Organization: The Internet

Could someone perhaps elaborate on the problems and/or proposed
solutions in the field of list-pattern-matching? I certainly believe that
it is a tough nut to crack, but I'm interested in what efforts have been
made in this field, and why they are not working (..well enough).

One aspect of existing attempts at list scanning that I'd like to hear more
about is the question whether the problems mentioned by Richard & Ralph 
are problems of a conceptual type (elegance-related) or mainly performance 
related.

Jan P. A. de Ruiter
janpeter@mpi.kun.nl
From: ralph@CS.ARIZONA.EDU ("Ralph Griswold")
Newsgroups: comp.lang.icon
Subject: 8.7 Icon for UNIX
Date: 17 Aug 92 17:09:26 GMT
Distribution: inet
Organization: The Internet

There are very few language differences between Version 8.6 and 8.7.  The
differences mostly are in the implementation, including bug fixes and
adjustments to X-Icon.

If you have 8.6 and aren't having any troubles, you probably don't need to
get 8.7.

If you're using X-Icon, however, you probably should get 8.7.  There also
are several X-Icon programs in the program library in 8.7
    
Ralph E. Griswold			ralph@cs.arizona.edu
Department of Computer Science 		 uunet!arizona!ralph
The University of Arizona		602-621-6609 (voice)
Tucson, AZ 85721			602-621-9618   (fax)
From: kwalker@CS.ARIZONA.EDU ("Kenneth Walker")
Newsgroups: comp.lang.icon
Subject: Re:  Icon Question(s)
Date: 21 Aug 92 16:53:02 GMT
Distribution: inet
Organization: The Internet

> From: destroyer!wsu-cs!usenet.ins.cwru.edu!wariat!ppetto@gumby.wisc.edu  (Peter J. Petto)
> ...
>       if Mode := "header"
>          then head(line)

It looks like you have a simple typo, try

>       if Mode == "header"

  Ken Walker  kwalker@cs.arizona.edu   uunet!arizona!kwalker
From: goer@ellis.uchicago.edu (Richard L. Goerwitz)
Newsgroups: comp.lang.icon
Subject: Re: List Scanning
Date: 21 Aug 92 05:28:22 GMT
Reply-To: goer@midway.uchicago.edu
Distribution: inet
Organization: University of Chicago Computing Organizations

idealord@dorsai.com (Jeff Harrington) writes:

>Has anyone used the programs in the program library - lscan.icn?  I use
>Icon primarily for music composition/editing and the use of list scanning
>procedures would vastly simplify my programs.  The procedures in lscan.icn
>purport to be modelled on all of the string scanning builtins - find(),
>tab(), etc but I haven't found the opportunity to experiment with them yet.

I wrote the lscan routines, and can say (definitively) that they are of
very limited scope, mainly useful only for lists of strings.  I really think
that scanning lists in Icon is not the way to go.  Scanning only makes sense
for homogenous linear sequences.  Csets are not linear, so they wouldn't be
usable (except if converted).  Integers don't make sense, either, unless we
are talking a) about "large" characters (in which case, we're not talking
about integers at all), or b) bit series.  I have many times wanted to scan
integers as "strings" of 1s and 0s, without having to actually convert them
to genuine Icon strings.

If Icon's strings were simply altered to permit "characters" of any rea-
sonable width (from a single bit on up), this would probably not interact
very well with current computer architectures, even if it would be *very*
useful to us (and compatible with previous implementations).  Right now,
strings are implemented as series of characters, as defined by the machine
on which the implementation is running.  You can write 8 characters on an
output stream, and then read them back in.  No big deal.  What if we are
trying to write 32-bit characters?  Or 1-bit characters?  Reading them
back in would require some thought on the part of the user.  There would
have to be consistency.

If the defaults were set up properly, though, I guess the user would not
have to think much anyway.

My mind boggles at the idea.  Imagine:  Strings specified as having a
character-width.  Type conversions?  Convert an integer to a string of
1-bit-wide characters, and then scan it.  Neat for compressing informa-
tion.  Conversions, naturally, would not be possible for incompatible
strings (e.g. 3-bit wide chars vs 8-bit wide ones).  Output streams
would also be defined as requiring a specific character-width (e.g. 8-
bit), and all writes to those streams would trigger conversions or er-
ror messages, in cases of incompatible strings.

Imagine:  If ISO 10646 is ever combined with Unicode, and accepted as
a standard, there'd be no trouble using the system.  Just use 32-bit-
wide strings.  These would automatically be type-converted when neces-
sary to 8-bit-wide strings.

Would this actually work, or is it just too late at night for me to
think straight?

-- 

   -Richard L. Goerwitz              goer%midway@uchicago.bitnet
   goer@midway.uchicago.edu          rutgers!oddjob!ellis!goer
From: ralph@CS.ARIZONA.EDU ("Ralph Griswold")
Newsgroups: comp.lang.icon
Subject: VMS 8.7 Icon
Date: 18 Aug 92 17:17:04 GMT
Distribution: inet
Organization: The Internet

The VMS version of Icon 8.7 was built with X-Window (DecWindows) support
enabled.  We have found that some sites that do not have DecWindows
are unable to run Icon at all.  You can check for the presence of the
necessary library file by entering

       $ DIR SYS$SHARE:DECW$XLIBSHR.EXE

If this file does not exist, Icon 8.7 will not run.  We are investigating
this problem.
    
Ralph E. Griswold			ralph@cs.arizona.edu
Department of Computer Science 		 uunet!arizona!ralph
The University of Arizona		602-621-6609 (voice)
Tucson, AZ 85721			602-621-9618   (fax)
From: idealord@dorsai.com (Jeff Harrington)
Newsgroups: comp.lang.icon
Subject: Re: List Scanning
Date: 20 Aug 92 19:05:36 GMT
Distribution: inet
Organization: The Internet

Has anyone used the programs in the program library - lscan.icn?  I use
Icon primarily for music composition/editing and the use of list scanning
procedures would vastly simplify my programs.  The procedures in lscan.icn
purport to be modelled on all of the string scanning builtins - find(),
tab(), etc but I haven't found the opportunity to experiment with them yet.
Jeff Harrington
idealord@dorsai.com