Re: [Avail] Avail Community Page

[Mark van Gulik]

On Jun 1, 2014, at 11:11 PM, David Brown wrote: [...] Well, the first problem is that there seem to be different Unicode characters that look like a greek letter sigma.  There is a greek letter sigma, but Avail wants the "N-ary summation" character, which makes sense. Ok. Beyond that, I'm not getting a compilation error that I've run into before.  It seems that summation wants to make sure the array isn't empty, but I'm not sure how to handle this situation.  I've attached the two files.  Also, this runs very slowly. A week or two ago Todd identified an issue with "∑_".  It appears to be very useful to have the ability to sum an empty tuple to get the integer 0, despite the potential type problems that forcing an integer return type in this case might have.  So he updated the method and its semantic restriction to allow summation for the empty tuple. Unfortunately, during that change a bug was introduced.  If the default type of the tuple type can occur as few as zero times, and if the least value possible in the default type is -∞, then when the semantic restriction is computing the lower bound of the sum, it tries to compute the minimum contribution of as few as zero occurrences of -∞ as 0 × -∞, which is undefined.  However, in this case we know that summing zero occurrences of something will always be zero, so I'm patching the code to compensate... Ok, it's committed.  *Your* code worked perfectly once the library was fixed.  I also added a "Timed Solve" entry point and discovered that on my MacBook Air ("13-inch, Mid 2011") it took 180.1s to run.  The updated Pr010.avail is attached. This is clearly not competitive performance, but there's nothing but our time and effort keeping us from making Avail much, much faster.  Just to compare, I Googled a few other run times.  For this wildly varying "benchmark", I have no problem comparing apples and oranges from multiple unspecified platforms by a variety of authors: Avail 180.1s Sage 0.05s Python 0.838s Cython 0.278s Cython optimized: 0.044s C# 0.031s Haskell "a few seconds" C 0.028s Java, naive >300s Java, naive, tweaked 156s Java up to sqrt(n) 2.4s So we're running almost four orders of magnitude slower than C.  However, something important to note is that several people were getting the wrong answers in C and C++ and C# (and others, I'm sure), due to internal integer overflow.  And worse, they're using memory arrays without bounds checks – I'm sure at least some of these programs segfaulted during development, not just returned wrong answers. And again, I apologize for dropping the ball with this by taking so long to address this problem.  It should have been handled the first day or so.

Pr010.avail
Description: Binary data

signature.asc
Description: Message signed with OpenPGP using GPGMail