pure-lang-users — Discussion of the Pure programming language.

Re: [pure-lang-users] Yet another quirk with MinGW

[Albert G. <Dr....@t-...>]

Eddie Rucker wrote:
> Thanks. I've been rattled this week over here with the fall semester
> starting.

Fortunately, we still have 2 more months over here. :) I hope to spend a 
big slice of that time on Pure.

> Yea, I need to add max, min, and the relational operations. I say go
> ahead and release 0.5 even though I haven't finished with the full test.

Yes, it will take some time to review all the test results anyway. At 
least we do have a test for math.pure now. Any remaining bugs will be 
slashed in the 0.6 release.

I still have to build the Windows package, but I hope that I can release 
0.5 tomorrow. It's taken long enough. ;-) But I think that it's also the 
most polished Pure release yet, and offers a lot of Good New Stuff(TM).

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

Re: [pure-lang-users] Yet another quirk with MinGW

[Eddie R. <er...@bm...>]

On Fri, 2008-08-22 at 11:14 +0200, Albert Graef wrote:
> Eddie Rucker wrote:

> I committed Eddie's math.pure test as test020.pure now, massaged 
> somewhat to produce a nicely formatted test log. (r563)

Thanks. I've been rattled this week over here with the fall semester
starting.

> What remains is the unattractive task to check all the untagged results. 
> As we say over here, that's a "job for someone who killed mom and dad", 
> so I'd rather suggest that we take a "many eyes" approach to that. 
> Everyone here who feels like it and has some spare time on his hands can 
> just scan a few results at a time and report on the mailing list if he 
> notices anything suspicious.
> 
> (Eddie, maybe we should also add another check on the result type and 
> flag results which aren't numbers? I leave that up to you.)

Yea, I need to add max, min, and the relational operations. I say go
ahead and release 0.5 even though I haven't finished with the full test.
It is just too much happening right now for me to focus on what I'm
doing. I was thinking of splitting the number tests up like the
following:

using math;
using system;

// unary functions 
let f = [sqrt, sin, cos, tan, ln, log, exp, atan, asin, acos, sinh,
	 cosh, tanh, asinh, acosh, atanh, abs, re, im, arg, conj, 
	 rect, polar, cis, ceil, floor, round, frac, complexp, realp,
	 rationalp, numberp, exactp, inexactp, infp, nanp];

// binary operations on complex
let f2 = [(+), (-), (*), (/), (^), (==), (!=)];

// binary operations on everything but complex
let f2_ordered = [(+), (-), (*), (/), (^), max, min, atan2, (!=), (==),
 		  (<), (>), (<=), (>=)];

// binary operations on just integers and rationals
let fw = [(pow), (div), (mod)];

// number sets
let Ns = [2,3000000000000000000000000000000000L];
let Zs = [-2,-1,0,1,2,5];
let Qs = [(-2)%3,0%4,4%5];
let Qno0s= [-1%2,5%4];
let Rs = [0.0, -e, pi];
let INs = [-inf,inf,-nan,nan];
let Cs = [a+:b; a=Zs+Qs+Rs+INs; b=Zs+Qs+Rs+INs];

... I'll have to finish later.

e.r.

Re: [pure-lang-users] Yet another quirk with MinGW

[Albert G. <Dr....@t-...>]

Albert Graef wrote:
> I committed Eddie's math.pure test as test020.pure now, massaged 
> somewhat to produce a nicely formatted test log. (r563)

Well, I had to fiddle with the output format some more, since 'make 
check' would fail on this test due to (more or less) small rounding 
discrepancies between systems. ("Almost zero" values are particularly 
nasty.) Therefore I'm rounding floating point numbers to 3 significant 
digits now, I hope that this is good enough. The latest log can be found 
here:

http://pure-lang.svn.sourceforge.net/viewvc/pure-lang/pure/trunk/test/test020.log

-- 
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

Re: [pure-lang-users] math.pure

[Eddie R. <er...@bm...>]

On Fri, 2008-08-22 at 01:42 +0200, Albert Graef wrote:
> Eddie Rucker wrote:

> NB: It would be possible to implement this for the bigint operations as 
> these are implemented as calls into the runtime, but I'd rather like 
> these to work consistently with the machine int operations. Also, this 
> is one of the cases where I think it's not really worth the effort, 
> because integer division by 0 almost invariably indicates a serious 
> program bug. Finally, note that you can still define x div 0 any way you 
> want as long as you're doing symbolic calculations (i.e., x is not an 
> integer).

My judgment sucks as of late, but I say err on the side of consistency.
If 1 div 0 is an error then 1L div 0L should be an error

> I'm about to remove the definition of pow on double, it just duplicates 
> the functionality of the ^ operator anyway.

Yes, there is no reason for duplicated functionality.

e.r.

Re: [pure-lang-users] math.pure

[Eddie R. <er...@bm...>]

On Fri, 2008-08-22 at 00:50 +0200, Albert Graef wrote:
> Eddie Rucker wrote:
> > I've been in faculty meetings all day today
> 
> Oh dear, that sucks. This silly ritual called "meetings" must have been 
> invented long ago by non-creative people to terrorize the rest of us, or 
> to pretend that they are actually doing something. ;-)

LOL. I agree completely! The only other thing I might add, It's the
administrator's way of making us pay for summers and holidays ;-)

> You surely mean inf^x=inf unless x<0 in which case inf^x=0.0. These 
> should all work now, also the -inf cases, except that C pow() insists on 
> setting 1.0^x = 1.0 no matter what x is. Also, x^0.0 will always be 1.0. 
> I guess that's POSIX behavior, so it should be ok.

What a moron :-O I'm totally embarrassed? Oh shame shame. If I reached
up right now, I would be too short to touch bottom.

> Not sure about the complex cases x^(+/-inf) where x<0, but I think that 
> these will always return nan+:nan right now. I'm open to suggestions 
> there. For finite, non-integral y, (-inf)^y gives inf+:inf or 0+:0, 
> depending on whether y>0 or y<0, which looks good to me.

Still mortified over that last one but mzscheme gives the following:
For x < 0,
  > (expt -4.0 -inf.0)
  0.0
  > (expt -4.0 +inf.0)
  +inf.0

For complex x,
  > (expt 1+2i -inf.0)
  +nan.0+nan.0i
  > (expt 1+2i +inf.0)
  +nan.0+nan.0i

e.r.

Re: [pure-lang-users] Yet another quirk with MinGW

[Albert G. <Dr....@t-...>]

Eddie Rucker wrote:
> On Wed, 2008-08-20 at 11:20 +0200, Albert Graef wrote:
> 
>> If anyone has noticed bugs which haven't been fixed yet, please report 
>> them *now*, as I'm about to release Pure 0.5 in the course of the next 
>> few hours.
> 
> I started playing around with the following script:
> [snip]

I committed Eddie's math.pure test as test020.pure now, massaged 
somewhat to produce a nicely formatted test log. (r563)

You can see the results at:

http://pure-lang.svn.sourceforge.net/viewvc/pure-lang/pure/trunk/test/test020.log?revision=563

Watch out for the line reading "*** UNARY ***", that's where the 
relevant stuff starts. Each line lists the function/operator, arguments 
and the result. Failed (i.e., irreducible) computations are flagged with 
'__failed__', exceptions with '__error__'. I already skimmed over these 
and AFAICT they should be ok.

What remains is the unattractive task to check all the untagged results. 
As we say over here, that's a "job for someone who killed mom and dad", 
so I'd rather suggest that we take a "many eyes" approach to that. 
Everyone here who feels like it and has some spare time on his hands can 
just scan a few results at a time and report on the mailing list if he 
notices anything suspicious.

(Eddie, maybe we should also add another check on the result type and 
flag results which aren't numbers? I leave that up to you.)

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

Re: [pure-lang-users] math.pure

[Albert G. <Dr....@t-...>]

Eddie Rucker wrote:
> On Thu, 2008-08-21 at 22:37 +0200, Albert Graef wrote:
>> That's why I think pow should actually be restricted to the exact 
>> rational and integer cases, with ^ covering all inexact powers, and 
> 
>> Comments?
> 
> Can you believe I actually agree for once?

Uh oh, I have to mark that date on my calendar. :-P

> If you wanted to stick with just integers that would be fine with me since ^ deals with everything else.

It's useful to have the rational definition as well, because it deals 
with all integer exponents (not just nonnegative ones).

Ok, I committed this now (r561).

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

Re: [pure-lang-users] math.pure

[Albert G. <Dr....@t-...>]

Eddie Rucker wrote:
>  > pow 0 (-1);
>  <stdin>:2.0-13: unhandled exception 'signal 8' while evaluating 'pow 0
> (-1)'

Yeah, that's just 1 div 0 in disguise there, so it's handled the same 
(see below). Note that GMP's mpz_pow_ui actually raises a SIGFPE in this 
case.

> Did you want to leave this unevaluated or throw an error?
> Also, x div 0 throws and error as well?

Yes, all integer divisions by zero throw a 'signal SIGFPE' exception 
now. In previous releases these would just crap out with an unhandled 
SIGFPE signal generated by the cpu, so this is definitely an improvement. :)

In Q, these return a normal form instead, which gives you the 
opportunity to add your own equations to handle division by zero. But 
this is not possible in Pure (at least not without sacrificing most of 
Pure's arithmetic performance), because integer arithmetic compiles to 
actual machine instructions there.

NB: It would be possible to implement this for the bigint operations as 
these are implemented as calls into the runtime, but I'd rather like 
these to work consistently with the machine int operations. Also, this 
is one of the cases where I think it's not really worth the effort, 
because integer division by 0 almost invariably indicates a serious 
program bug. Finally, note that you can still define x div 0 any way you 
want as long as you're doing symbolic calculations (i.e., x is not an 
integer).

> Should we add the following?
> 
> nan^nan = nan;
> nan^inf = nan;

This already works as of r560.

> pow nan nan = nan;
> pow nan inf = nan;

I'm about to remove the definition of pow on double, it just duplicates 
the functionality of the ^ operator anyway.

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

Re: [pure-lang-users] math.pure

[Albert G. <Dr....@t-...>]

Albert Graef wrote:
> Yeah, part of that surely is the same issue as with sqrt et al (missing 
> nanp check). That should be fixed now (r560).

I should mention that r560 also moves inf, nan and the correpsonding 
predicates to primitives.pure, so that they are available without having 
to load math.pure now.

-- 
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

Re: [pure-lang-users] math.pure

[Albert G. <Dr....@t-...>]

Eddie Rucker wrote:
> I've been in faculty meetings all day today

Oh dear, that sucks. This silly ritual called "meetings" must have been 
invented long ago by non-creative people to terrorize the rest of us, or 
to pretend that they are actually doing something. ;-)

> ^ was bombing out somewhere for valid numbers. 

Yeah, part of that surely is the same issue as with sqrt et al (missing 
nanp check). That should be fixed now (r560).

> _^nan = nan;
> nan^_ = nan;
> inf^inf=inf;
> x^inf=inf if x!===nan;
> inf^x=inf if x!==nan

You surely mean inf^x=inf unless x<0 in which case inf^x=0.0. These 
should all work now, also the -inf cases, except that C pow() insists on 
setting 1.0^x = 1.0 no matter what x is. Also, x^0.0 will always be 1.0. 
I guess that's POSIX behavior, so it should be ok.

Not sure about the complex cases x^(+/-inf) where x<0, but I think that 
these will always return nan+:nan right now. I'm open to suggestions 
there. For finite, non-integral y, (-inf)^y gives inf+:inf or 0+:0, 
depending on whether y>0 or y<0, which looks good to me.

> After, faculty meetings I hope to be able to look for the error with ^.

Please do. Your help with this is really appreciated!

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

Re: [pure-lang-users] math.pure

[Eddie R. <er...@bm...>]

On Thu, 2008-08-21 at 22:37 +0200, Albert Graef wrote:
> That's why I think pow should actually be restricted to the exact 
> rational and integer cases, with ^ covering all inexact powers, and 

> Comments?

Can you believe I actually agree for once? If you wanted to stick with just integers that would be fine with me since ^ deals with everything else.

e.r.

Re: [pure-lang-users] math.pure

[Eddie R. <er...@bm...>]

On Thu, 2008-08-21 at 12:51 -0500, Eddie Rucker wrote:

> ^ was bombing out somewhere for valid numbers. 

After the update not bombing anymore :) 

However, pow does:
 > pow 0 (-1);
 <stdin>:2.0-13: unhandled exception 'signal 8' while evaluating 'pow 0
(-1)'

Did you want to leave this unevaluated or throw an error?
Also, x div 0 throws and error as well?

Should we add the following?

nan^nan = nan;
nan^inf = nan;
pow nan nan = nan;
pow nan inf = nan;

e.r.

Re: [pure-lang-users] math.pure

[Albert G. <Dr....@t-...>]

Eddie Rucker wrote:
> What about
> 
> pow (1+2i) 3;

I really shouldn't have opened that can of worms by wrapping the C pow() 
function with Pure's pow. ;-)

I must rethink the purpose of the pow function. It would be silly to 
replicate all functionality we already have with the ^ operator.

In Q pow is just a wrapper for the GMP mpz_pow_ui function, which is 
then extended in rational.q to exact powers of rationals and integers 
with integer exponent. Maybe we should stick to that.

Of course, one can extend that to exact integer powers of complex 
rationals in *polar* notation quite easily, but in rectangular notation 
AFAICS the best you can do is addition-chain exponentiation which only 
works with nonnegative integer exponents and even that needs Theta(log 
n) additions.

That's why I think pow should actually be restricted to the exact 
rational and integer cases, with ^ covering all inexact powers, and 
leave it up to the programmer to extend the former in any manner he 
needs it. At least that was the conclusion we reached when discussing 
this issue in the context of Q.

Comments?

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

Re: [pure-lang-users] math.pure

[Eddie R. <er...@bm...>]

What about

pow (1+2i) 3;

Sorry, cannot finish my email have to go.

e.r.

Re: [pure-lang-users] ln

[Eddie R. <er...@bm...>]

On Thu, 2008-08-21 at 18:17 +0200, Albert Graef wrote:

> Eddie, as I said, I don't think it's useful to battle the established 
> standards, so I'm afraid the we'll have to live with it.

No battle, I just was kind of shocked. Most (All) of my floating point experience was a long time ago
and was all about trying to get a function give a good approximation to some domain with much smaller 
values than inf and -inf. Many of those functions were hard enough without throwing -inf and inf into the mix.

e.r.

Re: [pure-lang-users] math.pure

[Eddie R. <er...@bm...>]

On Thu, 2008-08-21 at 15:54 +0200, Albert Graef wrote:
> BTW, Eddie you make my day. Please keep those bug reports rolling. :)

About Yesterday. I had to give test after test and I didn't have any reference except my calculator (which doesn't do complex numbers) and what I 
got from the emails to go on when I was checking the test.log on the math libraries. During the time I was giving the test I could look at the logs.
I was in such a hurry checking my mail between tests that I thought you and John were both sending them. The Academic Dean and I didn't even get a 
lunch break yesterday.

I've been in faculty meetings all day today so I haven't had any time to look over anything but I see you've got the main things done. I've got another
in about 20 minutes. I did notice one other thing yesterday but I couldn't track it down without being at my computer,

^ was bombing out somewhere for valid numbers. 

I think 

_^nan = nan;
nan^_ = nan;
inf^inf=inf;
x^inf=inf if x!===nan;
inf^x=inf if x!==nan

needs to be implemented. After, faculty meetings I hope to be able to look for the error with ^.

e.r.

Re: [pure-lang-users] ln

[Albert G. <Dr....@t-...>]

John Cowan wrote:
> It does, see
> <http://www.opengroup.org/onlinepubs/000095399/functions/log.html>.

Thanks for that link. And at the end of that page it says:

RATIONALE

     None.

That pretty much sums it up. :)

Ok, so POSIX decided not to follow Goldberg's recommendation there, for 
whatever reason. Well, at least Pure's ln and log are in conformance 
with POSIX then, even though it doesn't make much sense mathematically.

Eddie, as I said, I don't think it's useful to battle the established 
standards, so I'm afraid the we'll have to live with it.

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

Re: [pure-lang-users] ln

[John C. <co...@cc...>]

Albert Graef scripsit:

> Unfortunately, on my Linux system both c_log (1/inf) and c_log (1/-inf) 
> return -inf in Pure, even though Pure correctly displays 1/inf as 0.0 
> and 1/-inf as -0.0. So it seems that the glibc log() function at least 
> does *not* distinguish between positive and negative zero. Maybe that's 
> a non-conformance in glibc, I'll have to check POSIX to see whether it 
> has something to say about log(-0.0).

It does, see
<http://www.opengroup.org/onlinepubs/000095399/functions/log.html>.

    Upon successful completion, these functions shall return the natural
    logarithm of x.

    If x is ±0, a pole error shall occur and log(), logf(), and logl()
    shall return -HUGE_VAL, -HUGE_VALF, and -HUGE_VALL, respectively.

    For finite values of x that are less than 0, or if x is -Inf, a
    domain error shall occur, and either a NaN (if supported), or an
    implementation-defined value shall be returned.

    If x is NaN, a NaN shall be returned.

    If x is 1, +0 shall be returned.

    If x is +Inf, x shall be returned. [Option End]

The talk of HUGE_VAL is to cover non-IEEE-754 systems that don't have Inf,
and have to use the largest representable value as a proxy for it.

-- 
Dream projects long deferred             John Cowan <co...@cc...>
usually bite the wax tadpole.            http://www.ccil.org/~cowan
        --James Lileks

Re: [pure-lang-users] Yet another quirk with MinGW

[John C. <co...@cc...>]

Albert Graef scripsit:

> LOL, I have to file that one in my quotes collection. Where is it from?

That most prolific of all authors, Anonymous.  It appears in several
books that I know of and all over the Internet, with lots of variants.

-- 
Yes, chili in the eye is bad, but so is your    John Cowan
ear.  However, I would suggest you wash your    co...@cc...
hands thoroughly before going to the toilet.    http://www.ccil.org/~cowan
        --gadicath

Re: [pure-lang-users] math.pure

[Albert G. <Dr....@t-...>]

Eddie Rucker wrote:
> While testing, I looked over some of the logs and here are my
> suggestions:

sqrt, ln and the hyp functions should all propely deal with nan and 
+/-inf arguments now. (r557)

> I think cis is broken for complex numbers. I've got to run give another
> test.

cis was never meant to be used with complex arguments. It properly 
checks the type of its argument now (r558).

BTW, Eddie you make my day. Please keep those bug reports rolling. :)

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

Re: [pure-lang-users] Yet another quirk with MinGW

[Albert G. <Dr....@t-...>]

John Cowan wrote:
> Eddie Rucker scripsit:
> 
>> You are right for 0.0. Yep, we have to use the |a-b| < epsilon
>> definition for equality. However, for the integer 0 and the rational 0%
>> 1, shouldn't log 0 be undefined?
> 
> Well, in general all the trig functions first cast their argument to a float;

Exactly.

-- 
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

Re: [pure-lang-users] Yet another quirk with MinGW

[Albert G. <Dr....@t-...>]

John Cowan wrote:
> 9/0 is indeed inf, though 9%0 ought to be an error (in Q it's inf).

Not so in Pure, it raises a 'signal SIGFPE' exception there (as does 9 
div 0).

I agree that the way this case is implemented in Q just doesn't make any 
sense.

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

Re: [pure-lang-users] Yet another quirk with MinGW

[Albert G. <Dr....@t-...>]

John Cowan wrote:
>         There was a young fellow of Trinity
>         Who solved the square root of infinity,
>             But while counting the digits
>             Was seized by the fidgets
>         Dropped maths and took up divinity.
> 
> No wonder!

LOL, I have to file that one in my quotes collection. Where is it from?

>> (3) Shouldn't polar (x<:y) => x<:y ?
>> (4) Shouldn't rect (x+:y) => x+:y ?
> 
> Looks good to me.

Fixed (r556).

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

Re: [pure-lang-users] ln

[Albert G. <Dr....@t-...>]

Eddie Rucker wrote:
> Yes, ln x -> -inf as x -> 0.

Errm, of course I meant that ln x -> -inf as x -> +0.

Oh well. I see no merit in fighting the standard there, it seems to be 
well-thought out after all, and backed up by substantial mathematical 
theory to make sure that it all makes sense, in a twisted way.

> But x aint zero here, it is something close to zero. If you look at Ln x in the complex plain, the y-
> axis is an asymptote and hence Ln 0 has no value at all i.e. undefined.

That's why IEEE 754 distinguishes between positive and negative zero. So 
the C log() function can return -inf for +0.0 and nan for -0.0 (at least 
that's what Goldberg's IEEE 754 paper suggests). Moreover, the C99 
clog() function is supposed to return clog(z) = log(cabs(z)) + i * 
carg(z), and that's exactly how math.pure implements the complex ln 
function as well. So Pure's ln function should work properly to the 
extent that the C log() function does.

Unfortunately, on my Linux system both c_log (1/inf) and c_log (1/-inf) 
return -inf in Pure, even though Pure correctly displays 1/inf as 0.0 
and 1/-inf as -0.0. So it seems that the glibc log() function at least 
does *not* distinguish between positive and negative zero. Maybe that's 
a non-conformance in glibc, I'll have to check POSIX to see whether it 
has something to say about log(-0.0).

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

Re: [pure-lang-users] Bug with list comprehensions

[Albert G. <Dr....@t-...>]

Eddie Rucker wrote:
>  > using math;
>  > let x = [1+:2, 1%4];
>  > [(i,j); i=x; j=x];
>  [(0+:1,1+:2),(0+:1,1L%4L),(0+:1,1+:2),(0+:1,1L%4L)]

Fixed (r555).

-- 
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