> Does findstat relly on a big database that is enhanced with the new queries? 
> Or does it compute every query from scratch?

I start with answering here since this the crucial point.

We want to use Sage in FindStat only in the background, a user
interacting with FindStat (by searching for statistics, or by
contributing statistics) should not see what's happening in the
background.

By a combinatorial statistic I mean a map from some combinatorial
collection to the integers. FindStat does not store combinatorial
statistics as maps, but only as finite explicit data sets (and finite
should be flexible in the sense that it can be very few or quite some,
say 10-2000).

    Reasons:

    - this gives anyone the chance to contribute to FindStat: it might
be that you computed some statistic by hand for a few values without
having any written code (think of the dimension some variety attached
to a permutation and not of something you can code super easily), or
it might be that you prefer to work in one of the Ma's and still want
to contribute your statistic.

    - it is *impossible* to compute statistics on the fly. Even if you
had code to compute the statistic: what if it takes 13sec to compute
your statistic for the permutation [6,5,4,3,1,2] (just checked with
the number of decompositions into simple transpositions). In a single
database search, there are 10000th if not millions of statistics
values tested. These cannot be computed on the fly, even if you store
them temporarily.

> Just to clarify, i wasn't thinking on sage sending a query to findstat

But that will be the only possible way to go. Your question here is as
asking the same for the OEIS, see above.

> but performing the search locally (i.e. having findstat software included in 
> Sage).

I don't know if that's maybe as well what you thought of: it might be
possible to query FindStat for the plain statistics data and do the
remaining computations within Sage. I would actually very much
appreciate if we were doing that at some point simply because I would
expect this to result in strong improvements of the search engine we
have written for FindStat so far.

BUT: this would result in code in Sage that is not useful purely
within Sage. And there are people, loud people, that say there should
not be such code in Sage.

Another problem that would need to be solved would be: Such code would
always need to interact with FindStat and would thus need to follow
predefined specifications for that interaction.

Cheers,

    Christian

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to