pure-lang-users Mailing List for Pure (Page 3)
Status: Beta
Brought to you by:
agraef
Menu
▾
▴
pure-lang-users — Discussion of the Pure programming language.
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(31) |
May
(422) |
Jun
(241) |
Jul
(268) |
Aug
(281) |
Sep
(109) |
Oct
(1) |
Nov
|
Dec
|
|---|
|
From: Albert G. <Dr....@t-...> - 2008-09-24 01:19:39
|
Eddie Rucker wrote: > This is an email I sent on Sept. 19 that keeps returning to me. Yeah, I noticed some hiccups on Sep 19 as well, looks like they migrated the mailing lists to the new datacenter. > Should null be nullp? I keep making the error of typing nullp since all > of the other predicates end with p. It's null for Haskell compatibility. I think it's been called null in Q already for a long time, maybe even going back to Bird/Wadler ed. 1 which Q's notation was originally based on. And Lisp uses 'null', too. In Pure I started using the xyzp naming for the type predicates, replacing Q's "isxyz" because it's shorter and I don't have to look up whether it's actually "isxyz" or "is_xyz" all the time. :) Cheers, Albert P.S.: Pure's GSL matrix implementation is now complete in svn, I still have to update the manual and fix a bug in system.pure tomorrow, then I'm ready to release Pure 0.7. (In case anyone else wonders what this is all about, think Pure+Octave under one hood. That also solves once and for all the lack of a decent and efficient array data structure in Q. I'll post more about this before the release. For the time being, you can find a very brief summary in the NEWS file, see: http://pure-lang.svn.sourceforge.net/viewvc/pure-lang/pure/trunk/NEWS) -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Eddie R. <er...@bm...> - 2008-09-23 20:07:59
|
This is an email I sent on Sept. 19 that keeps returning to me. Should null be nullp? I keep making the error of typing nullp since all of the other predicates end with p. e.r. |
|
From: Albert G. <Dr....@t-...> - 2008-09-18 14:34:01
|
John Lunney wrote: > On the machine where I'm a normal user, it doesn't have permission to > edit the global environmental variables, so there's an error. Unfortunately the freeware MSI builder I'm using (AdvancedInstaller, which is the only half-decent freeware GUI-based MSI builder that I could find) doesn't provide many configuration options there. AFAICT, the MSI must be configured for either single-user or admin installation, and the environment variables to edit must then be set up accordingly. I see no way to tweak the MSI configuration in a more intelligent way, or based on user interaction. The full AdvancedInstaller software presumably has all those features, but I'm not going to shell out any money just to build a stupid MSI. > I presume there are user-level environmental variables in Windows? Yes, actually the MSI was set up to edit the user environment up to Pure 0.5, but that caused other issues, as reported by Rob Hubbard. So I changed it to use the system variables instead, which is more convenient if you want to do an admin install for all users and then go on to work from an ordinary user account. I thought that AdvancedInstaller would be clever enough to find a way to make that work with a user install, too, but obviously that was too optimistic. ;-) > I guess there are a few ways round this: > 1. Require Administrator access to install > 2. Automatically choose whether to edit the global or user variables > depending on who is running the installer > 3. Allow a "For all users" or "For this user" install, and act appropriately. Well, the only option that the AdvancedInstaller freeware seems to offer is #1, so I'm going to fix the MSI accordingly for the next release. That will no doubt raise many complaints about not being to able to install Pure as non-admin, but then so be it. > Hope this helps, Yes, thanks for reporting the issue. :) Cheers, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: John L. <joh...@gm...> - 2008-09-18 11:05:52
|
Hi Albert, Just a very small problem! I downloaded and tested the Windows installer package here in work. On the machine where I've given myself Administrator privileges, it installs fine. On the machine where I'm a normal user, it doesn't have permission to edit the global environmental variables, so there's an error. When you open PurePad then, obviously it can only look in the current directory for the prelude etc. I presume there are user-level environmental variables in Windows? (It's far from my primary platform) I guess there are a few ways round this: 1. Require Administrator access to install 2. Automatically choose whether to edit the global or user variables depending on who is running the installer 3. Allow a "For all users" or "For this user" install, and act appropriately. Hope this helps, John On Fri, Sep 12, 2008 at 1:56 AM, Albert Graef <Dr....@t-...> wrote: > The most important additions in this release are the support for macros > and lazy evaluation. The Windows package now includes PurePad, a little > GUI frontend which makes editing and running Pure scripts on Windows a > bit more convenient. (This is just a quick hack of Qpad to make it work > with Pure.) > > Downloads and release notes can be found here: > http://sourceforge.net/project/showfiles.php?group_id=226193 > > Enjoy. :) > Albert |
|
From: Albert G. <Dr....@t-...> - 2008-09-13 11:39:38
|
I wrote: > [...] Erlang-style message passing (but > without the copying, which will need some special provisions in order to > get safe but lockless reference counting) Well, I should add here that I'd like to avoid copying in the message passing because of efficiency considerations, and because this allows the passing of function objects (including thunks, and therefore lazy data structures). But I still consider the copying option because it makes things so much easier. Not sharing any data between threads except the message queues and the thread handles has the chief advantage that almost all tricky synchronization issues just go away, and it's easier to make this work across the network, too. So I'll certainly take a look at how the Erlang people have done this. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-09-13 07:24:10
|
John Cowan wrote: > Please give us something more disciplined than (p)threads, which are > nothing but an invitation to make a mess of a concurrent program. When I talk about pthreads an OpenMP, that's just the implementation. The concurrency model presented to the Pure programmer will be something entirely different. I'm not going to repeat the mistakes I did with Q. ;-) > (This assumes that you have already introduced state; threads are fine > without mutable state.) I'd prefer fork/join/pipe semantics like Unix > processes myself, since they are already known to distribute well over > multiple cores and multiple machines, but I can live with any reasonable > discipline. So far, I've been looking at the following models which are known to work well in FPLs: Linda (or rather a variation called "concurrent tree bags" being used in Aardappel), Erlang-style message passing (but without the copying, which will need some special provisions in order to get safe but lockless reference counting) and concurrent futures a la Alice ML. The latter is especially attractive because it unifies concurrency and the lazy futures which Pure already has, but it lacks the message passing aspect. I think that a combination of concurrent futures with message passing would be nice to have, and this should be pretty close to the fork/join/pipe model you have in mind. This will still require some kind of synchronization for the impure stuff in the library (references, sentries and direct C pointer manipulation, as well as eval/str), but this can be handled behind the scenes. In any case I want to make sure that purely functional code will never need any kind of mutex locking. Lockless synchronization might also work for some of the impure features. Of course, the message passing channels themselves also need some kind of protection, but if possible I will also use a lockfree data structure there. I'm open to suggestions, so if you know about any other concurrency models and/or implementation tricks that might be interesting in this context, please let me know. Cheers, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: John C. <co...@cc...> - 2008-09-12 20:38:06
|
Albert Graef scripsit: > 0.8: Multithreading support. Not sure how long that will take, as I > haven't really decided about the concurrency model and the base > libraries (pthreads? OpenMP?) yet. Please give us something more disciplined than (p)threads, which are nothing but an invitation to make a mess of a concurrent program. (This assumes that you have already introduced state; threads are fine without mutable state.) I'd prefer fork/join/pipe semantics like Unix processes myself, since they are already known to distribute well over multiple cores and multiple machines, but I can live with any reasonable discipline. -- John Cowan http://ccil.org/~cowan co...@cc... Economists were put on this planet to make astrologers look good. --Leo McGarry |
|
From: Albert G. <Dr....@t-...> - 2008-09-12 20:22:22
|
Hi Libor, and welcome back! Libor Spacek wrote: > Congratulations, it even installs and runs easily on my 64bit Windoze Vista. Thanks for the info, nice to know that it works on 64 bit Windows, too. Note that the Windows binary is actually 32 bit, but that shouldn't make much of a difference as far as Pure is concerned (except for the range of pointer values, of course). Also note that you can readily implement 'timex' as a macro now, in fact that example is discussed in the new macros section in the manual. > This is progress indeed, well done! Thanks. :) In fact I'm quite pleased with how quickly Pure has gone from a proof of concept to an almost complete base system. LLVM has proved to be rather nice to work with, and I'm confident now that it was the right decision to retire the slow Q interpreter and its aging codebase, and start from scratch. Just for the record, here's my current roadmap: 0.7: GSL vector and matrix support. Started working on that today, expect to finish it still in September. 0.8: Multithreading support. Not sure how long that will take, as I haven't really decided about the concurrency model and the base libraries (pthreads? OpenMP?) yet. At that point we'll have a pretty solid and complete base system and work can start on the library interfaces. Only the blue sky will be the limit then. :) Cheers, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Libor S. <li...@gm...> - 2008-09-12 16:40:42
|
Congratulations, it even installs and runs easily on my 64bit Windoze Vista. This is progress indeed, well done! Libor On Fri, 12 Sep 2008 01:56:40 +0100, Albert Graef <Dr....@t-...> wrote: > The most important additions in this release are the support for macros > and lazy evaluation. The Windows package now includes PurePad, a little > GUI frontend which makes editing and running Pure scripts on Windows a > bit more convenient. (This is just a quick hack of Qpad to make it work > with Pure.) > > Downloads and release notes can be found here: > http://sourceforge.net/project/showfiles.php?group_id=226193 > > Enjoy. :) > Albert > |
|
From: Albert G. <Dr....@t-...> - 2008-09-12 00:54:00
|
The most important additions in this release are the support for macros and lazy evaluation. The Windows package now includes PurePad, a little GUI frontend which makes editing and running Pure scripts on Windows a bit more convenient. (This is just a quick hack of Qpad to make it work with Pure.) Downloads and release notes can be found here: http://sourceforge.net/project/showfiles.php?group_id=226193 Enjoy. :) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-09-11 15:13:12
|
Eddie Rucker wrote: > I know I'm the one that brought this up, but how about we revisit the > issue later when we have time to think about this. Well, in any case it was bad to have these two cases return inconsistent results, so I fixed that now in the way I described. Making it conform with the ISOC99 recommendations is now just a matter of editing the two rules for complex * and /, if we lateron decide that we need that. > Later, we can compare Pure results to GSL's > results. I think consistency with GSL should be a must. The only way to achieve 100% compatibility with GSL there would be to actually use the complex multiplication and division routines employed by GSL itself. But presumably GSL just uses whatever complex arithmetic the C compiler provides (or Fortran, in the case of BLAS). In the case of the GNU compilers (which are the ones we use on all major platforms except the *BSDs) the results should be compatible with what math.pure provides now. An alternative would be to actually use the complex double routines provided by the C runtime and library, and add marshalling of complex results to the C interface. That would be useful to have anyway, for interfacing to GSL. I'll have a look at that in the next release. > I'll note math things that look funny and we can hash them later. I'll > just report other types of errors for now. Ok, thanks. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Eddie R. <er...@bm...> - 2008-09-11 12:42:00
|
I know I'm the one that brought this up, but how about we revisit the issue later when we have time to think about this. IIRC you needed to finish Pd for you classes. Later, we can compare Pure results to GSL's results. I think consistency with GSL should be a must. I'll note math things that look funny and we can hash them later. I'll just report other types of errors for now. e.r. On Thu, 2008-09-11 at 12:34 +0200, Albert Graef wrote: > I'm beginning to wonder whether it's really worth the hassle to follow > the ISOC99 recommendations concerning the treatment of infinities and > NaNs for complex * and /. The algorithms in Annex G do look like a kind > of kludge to me, and they employ C99 functions for extracting and > scaling the exponents of floating point numbers which might not be > available on some systems (such as Windows), at least not directly. > Hence special support in the runtime would be needed to implement these > in a portable way across all platforms. > > That seems like an awful lot of kludges to just make those nan+:nan's go > away, considering that Pure also offers the polar representation where > you'll get the correct infinite results for division by zero and similar > cases, as long as the phase angles are finite. > > So actually John's suggestion seems to be the most reasonable: just > promote real operands of * and / to complex, then the results will at > least be consistent. Or does anyone here really need the ISOC > recommended behaviour? > > Albert > |
|
From: Albert G. <Dr....@t-...> - 2008-09-11 10:31:52
|
Albert Graef wrote: > Good point! In fact gcc seems to do that, too (I get nan+:nan for /0.0 > just as well as for /(0.0+I*0.0). As a matter of fact, Haskell gives the same results, too (at least Hugs does), and the Haskell report uses the same formulas as math.pure in the complex/complex case. I'm beginning to wonder whether it's really worth the hassle to follow the ISOC99 recommendations concerning the treatment of infinities and NaNs for complex * and /. The algorithms in Annex G do look like a kind of kludge to me, and they employ C99 functions for extracting and scaling the exponents of floating point numbers which might not be available on some systems (such as Windows), at least not directly. Hence special support in the runtime would be needed to implement these in a portable way across all platforms. That seems like an awful lot of kludges to just make those nan+:nan's go away, considering that Pure also offers the polar representation where you'll get the correct infinite results for division by zero and similar cases, as long as the phase angles are finite. So actually John's suggestion seems to be the most reasonable: just promote real operands of * and / to complex, then the results will at least be consistent. Or does anyone here really need the ISOC recommended behaviour? Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Eddie R. <er...@bm...> - 2008-09-10 12:42:23
|
On Wed, 2008-09-10 at 00:43 +0200, Albert Graef wrote: > There are many tradeoffs in numerical mathematics, even more so in > computer algebra, design decisions are difficult, and sometimes I'm not So true! > even aware of them. So please continue to raise those questions, that > always gives me an opportunity to rethink those things! OK, I'll keep fanning the poo pile. Keep your trusty flyswatter at hand ;-) e.r. |
|
From: Albert G. <Dr....@t-...> - 2008-09-09 23:16:50
|
Albert Graef wrote: > [1] I'm referring to the 2005 draft, couldn't find anything newer. > Here's the URL: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf Here's a newer version, linked to from the Wikipedia C99 page: http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-09-09 23:10:51
|
John Cowan wrote: > The FastCGI interface keeps the language processor running rather > than starting a new process for every incoming request, so it is > much more lightweight. Thanks for the information, I wasn't aware of this. In fact, being able to answer more than one request in a single interpreter instance was one of the main advantages of the Q Apache module, so I'm rather happy that there's another, simpler way to achieve that! This will be even more important for Pure, since compilation times are longer, being traded for much shorter execution times. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-09-09 23:06:30
|
Eddie Rucker wrote: > I got this wrong then. Apologies to Albert. There's no reason to apologize, and there's no easy right or wrong in these questions, that's what makes them so difficult. Of course we don't want to violate mathematical truths (and even that's not guaranteed with floating point numbers!), but apart from that there's still a lot of leeway in which formulas and algebraic identities we're going to use. The acclaimed but essentially vacuous "principle of the least surprise" may yield different results here, depending on whether you look at it from the pov of functional analysis, numerics, or just plain software engineering. That's why I try to stick to established standards, but even ISO/IEC9899 says that they're not sure about their "informational" design decisions in that area either, that's why they tagged them that way. I can understand that, I think that I'm a reasonably well-educated mathematician, but I'm not sure about the right way to implement these things either. :) For the time being, I'll try to follow the ISO/IEC9899 recommendations, so if you notice anything which is at odds with these, please let me know! Cheers, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-09-09 22:41:20
|
Eddie Rucker wrote: > What about ln 1? Scheme has a different philosophy from Pure: all > operations *try* to return an exact value if the operation's argument(s) > are exact. That's true, of course. But in the case ln 0 there's no exact result. In fact, Scheme's approach to this raises many difficult questions, because it's not clear immediately what, in a precise mathematical sense, should be an exact result. That borders on computer algebra which is a *very* difficult area which goes way beyond just rational numbers and the like. > I think I've totally > chased the rabbit away from my original question which was about > consistency for which you found the answer in a later post. I agree, that should be the goal. And in fact you've been right, the definitions in math.pure have some bugs there. There are many tradeoffs in numerical mathematics, even more so in computer algebra, design decisions are difficult, and sometimes I'm not even aware of them. So please continue to raise those questions, that always gives me an opportunity to rethink those things! Thanks, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-09-09 22:20:40
|
John Cowan wrote: > If only. In fact, int/int in C is truncating integer division, but that's > okay, because C is obviously broken there. I know Pure is supposed to > "do it the C way", but that's carrying things too far. Right, thanks for correcting me. s/C/Pascal/ (which does it in a much more sensible way than C IMHO.) -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: John C. <co...@cc...> - 2008-09-09 15:05:09
|
Eddie Rucker scripsit: > I got this wrong then. Apologies to Albert. I assumed all Scheme > implementations implemented arithmetic like MzScheme. You'd think by now > I would not assume anything ;-) R5RS Scheme implementations are really separate languages with a common small core, not like C or Ruby or Python implementations. -- Mark Twain on Cecil Rhodes: John Cowan I admire him, I freely admit it, http://www.ccil.org/~cowan and when his time comes I shall co...@cc... buy a piece of the rope for a keepsake. |
|
From: Eddie R. <er...@bm...> - 2008-09-09 14:59:52
|
On Tue, 2008-09-09 at 10:30 -0400, John Cowan wrote: > R5RS only requires this of a particular list of standard procedures, > which does not include / or the transcendental functions. R6RS, which > requires support for arbitrary ratios as R5RS does not, does require / > to produce exact results on exact arguments, and expt to produce exact > results if the first argument is an exact real value and the second > argument an exact integer. > > R6RS also explicitly says that sqrt, exp, log, sin, cos, tan, asin, acos, > atan, expt, make-polar, magnitude, and angle may (but are not required > to) return inexact results even when given exact arguments. I got this wrong then. Apologies to Albert. I assumed all Scheme implementations implemented arithmetic like MzScheme. You'd think by now I would not assume anything ;-) e.r. |
|
From: John C. <co...@cc...> - 2008-09-09 14:30:36
|
Eddie Rucker scripsit: > What about ln 1? Scheme has a different philosophy from Pure: all > operations *try* to return an exact value if the operation's argument(s) > are exact. R5RS only requires this of a particular list of standard procedures, which does not include / or the transcendental functions. R6RS, which requires support for arbitrary ratios as R5RS does not, does require / to produce exact results on exact arguments, and expt to produce exact results if the first argument is an exact real value and the second argument an exact integer. R6RS also explicitly says that sqrt, exp, log, sin, cos, tan, asin, acos, atan, expt, make-polar, magnitude, and angle may (but are not required to) return inexact results even when given exact arguments. > (log 1) => 0 ; an exact 0 not an approximated 0.0 In fact, this produces 0.0 in all of Scsh, Guile, and Chicken (both with and without the numbers egg). > (sin 0) => 0 > (cos 0) => 1 ; an exact 1 > (sqrt 4) => 2 ; an exact 2 > (sqrt -4) => 0+2i ; no approximations on the img part. > (expt 16 1/2) => 4 > (expt 8 1/3) => 2.0 ; uh oh? My Casio gives the exact value of 2 here. And likewise with all of these. > (/ 1 3) => 1/3 This is indeed exact on Chicken with the numbers egg, Guile, and Scsh; Chicken without the numbers egg prints a lexical-syntax warning, treats 1/2 as 0.5, and produces an inexact result. -- John Cowan http://ccil.org/~cowan co...@cc... Lope de Vega: "It wonders me I can speak at all. Some caitiff rogue did rudely yerk me on the knob, wherefrom my wits still wander." An Englishman: "Ay, a filchman to the nab betimes 'll leave a man crank for a spell." --Harry Turtledove, Ruled Britannia |
|
From: Eddie R. <er...@bm...> - 2008-09-09 13:27:59
|
On Tue, 2008-09-09 at 13:00 +0200, Albert Graef wrote: > Yes, you are, I'm afraid. :) The Scheme way doesn't make much sense > there because log is always an inexact operation. What about ln 1? Scheme has a different philosophy from Pure: all operations *try* to return an exact value if the operation's argument(s) are exact. (log 1) => 0 ; an exact 0 not an approximated 0.0 (sin 0) => 0 (cos 0) => 1 ; an exact 1 (sqrt 4) => 2 ; an exact 2 (sqrt -4) => 0+2i ; no approximations on the img part. (/ 1 3) => 1/3 (expt 16 1/2) => 4 (expt 8 1/3) => 2.0 ; uh oh? My Casio gives the exact value of 2 here. What does you HP give? I'm not disagreeing with your reasoning that Pure should promote its argument(s) to inexact values like C does though. I think I've totally chased the rabbit away from my original question which was about consistency for which you found the answer in a later post. My arm is getting tired of flogging. I'll shut up and go back to work now ;-) e.r. |
|
From: John C. <co...@cc...> - 2008-09-09 13:23:46
|
Albert Graef scripsit: > Yes, that's because int args of those floating point operations are > generally promoted to double. It's the most sensible way to do it. The > same is true for / (which is *always* an inexact floating point division > in Pure, just like in C). If only. In fact, int/int in C is truncating integer division, but that's okay, because C is obviously broken there. I know Pure is supposed to "do it the C way", but that's carrying things too far. -- How they ever reached any conclusion at all <co...@cc...> is starkly unknowable to the human mind. http://www.ccil.org/~cowan --"Backstage Lensman", Randall Garrett |
|
From: Albert G. <Dr....@t-...> - 2008-09-09 12:26:54
|
Albert Graef wrote: > However, that's *not* what ISO/IEC9899, Annex G [1] says (see G.5.1, > especially Example 2). It requires an inf+I*inf result in the /0.0 case, > if I read it right. Uhmm, of course it also requires a inf+:inf result in the /(0+:0) case, I'll have to fix that in math.pure... Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
6 messages has been excluded from this view by a project administrator.
