Re: [sage-devel] Best way to store a database?
2014-09-28 21:01 UTC+02:00, mmarco : > Typically invariants are polynomials with integer coefficients (sometimes > with negative or even rational exponents). I guess they could be converted > to a dictionary (maybe represented by a list), but doesn't sound like the > kind of data structure that fits well on a databse index. > > Maybe storing the hash of the invariants would be a good idea? No. Store the polynomial as a string, it would be much more simple... and much more readable. At some point you might want to access the database without having to guess what is the data inside. The upstream database is only a text file? Do you know how they do in Snappy? There is a huge collection of 3 manifolds inside. It would be cool to have something somehow compatible. Vincent -- 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.
Re: [sage-devel] Best way to store a database?
Typically invariants are polynomials with integer coefficients (sometimes with negative or even rational exponents). I guess they could be converted to a dictionary (maybe represented by a list), but doesn't sound like the kind of data structure that fits well on a databse index. Maybe storing the hash of the invariants would be a good idea? El sábado, 27 de septiembre de 2014 22:22:44 UTC+2, wstein escribió: > > On Sat, Sep 27, 2014 at 12:22 PM, mmarco > > wrote: > >> > >> How long ? > >> > > > > Around five seconds in a very fast SSD disk. > >> > >> > >> > >> What kind of Python/Sage object do you want to store at the end ? > >> Dictionaries of strings (easy to store in a SQL table) or less standard > >> Sage objects ? What takes most processing time, parsing the file or > >> creating Sage adequate objects from well stored strings ? Is the data > in > >> the upstream RDF database organised as a graph and will you use this > >> structure in your queries (in which case relational SQL may not be > >> appropriate, note that python has libs for dealing with RDF instead of > >> parsing it as raw text) ? What kind of queries will the database deal > >> with ? Are the kind of queries already stored on the upstream file or > >> should you preprocess new columns for better performance ? Will the > >> queries involve testing properties on complex Sage objects or looking > >> for existence of string and comparing integers ? > > > > > > The file contains basically lines of the form: > > > > knot name / invariant name /invariant value > > > > Of course the invariant values are stored as strings, but we need to > convert > > them to objects like polynomials. > > > > The main idea i had was to be able to "identify" a knot. That is, given > an > > arbitrary knot by the user, compute the corresponding invariants, and > then > > look at the database for possible candidates (that is, knots with the > same > > invariants). That means that we would need fast comparisons against the > > objects stored in the database. > > Or if the data types are standard (e.g., integers, floats, etc.), > then you can build > an index. This is a 1-liner in SQLite, and makes queries super-fast. > > William > > > > > Of course it could also be used on the opposite direction: to construct > > knots in sage just by their identifier in the database. > > > > > >> > >> > >> Also, the answer may depend on whether the upstream database is > evolving > >> fast and whether you will ensure long-term maintenance of the package. > >> Depending on this, an option could be to have a command within Sage > that > >> fetches, parses/preprocess (if there is a benefit), and store the > >> database on user's demand. This can be compatible with offering a > >> preprocessed package as well if preprocessing takes more time than > >> fetching (like distributing sources vs distributing binaries). > > > > > > I think the upstream datbse is essentially stabilized. Maybe at some > point > > they could add more knots to the database, but doesn't seem likely. > >> > >> > >> Ciao, > >> Thierry > >> > > -- > > 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+...@googlegroups.com . > > To post to this group, send email to sage-...@googlegroups.com > . > > Visit this group at http://groups.google.com/group/sage-devel. > > For more options, visit https://groups.google.com/d/optout. > > > > -- > William Stein > Professor of Mathematics > University of Washington > http://wstein.org > wst...@uw.edu > -- 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.
[sage-devel] sage days 6 video
Hi, I finally made the Sage Days 6 [1] (Bristol, UK) videos available: http://wiki.sagemath.org/days6/videos Some are amusing, especially the developer interviews that Ondrej Certik ran around doing... [1] http://wiki.sagemath.org/days6 -- William -- William Stein Professor of Mathematics University of Washington http://wstein.org wst...@uw.edu -- 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.
Re: [sage-devel] Re: Sage package bash?
On Saturday, September 27, 2014 10:36:14 PM UTC+2, kcrisman wrote: > > If I recall correctly sometimes one needs to use dash instead of bash on > Cygwin, but nonetheless it somehow works, maybe because dash is only > necessary when going "outside" of Sage for rebasing or something? > Yes, (approximately) you only need to use dash to rebase to ensure no system dlls are loaded. In fact with recent cygwin, you can just leave system dlls alone and only rebase Sage's dlls using the "-O" flag. -- 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.
Re: [sage-devel] Trac and sort by lastmod
We do use the milestone to indicate duplicate/invalid/wontfix, at least. Though I agree that we don't really need to update the milestone, if its pointing at an older version then so what? Is anybody making trac queries for specific milestones? If you want to know which tickets were closed then that is more easily extracted from the git commit log. On Sunday, September 28, 2014 3:19:28 PM UTC+1, Ivan Andrus wrote: > > On Sep 26, 2014, at 6:33 AM, kcrisman > > wrote: > > > > After clicking Lastmod-header it got tickets sorted like >> > >> > 1 mins < 23 hours < 32 mins < 8 days >> >> It's not a direct answer to your question, but you might be interested >> in http://trac.sagemath.org/report/92 >> >> > This is nearly useless, though, except for tickets modified since the last > Sage (official) release. Is there any way to get back to the "old" system > where the milestone would change *without* changing the ticket - and hence > the ticket last-mod time? It is very misleading to see ticket #xyz > modified three weeks ago and it turns out that it was last substantively > modified in 2008. > > > Do we really need to change the milestone every time? Why can’t we just > set them all to future, and then when they get merged, we can change the > milestone to the actual version? As it is now, it seems milestone serves > no real purpose. It’s not the version it was originally reported against. > It’s not the version it’s going to be fixed in. It’s just the next > release that will be made. > > -Ivan > -- 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.
Re: [sage-devel] Trac and sort by lastmod
On Sep 26, 2014, at 6:33 AM, kcrisman wrote: > > > After clicking Lastmod-header it got tickets sorted like > > > > 1 mins < 23 hours < 32 mins < 8 days > > It's not a direct answer to your question, but you might be interested > in http://trac.sagemath.org/report/92 > > > This is nearly useless, though, except for tickets modified since the last > Sage (official) release. Is there any way to get back to the "old" system > where the milestone would change *without* changing the ticket - and hence > the ticket last-mod time? It is very misleading to see ticket #xyz modified > three weeks ago and it turns out that it was last substantively modified in > 2008. Do we really need to change the milestone every time? Why can't we just set them all to future, and then when they get merged, we can change the milestone to the actual version? As it is now, it seems milestone serves no real purpose. It's not the version it was originally reported against. It's not the version it's going to be fixed in. It's just the next release that will be made. -Ivan -- 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.
Re: [sage-devel] Re: Why I don't think Sage has "failed" as a replacement for Maple, Mathematica and other Ma*'s
On Sunday, September 28, 2014 1:00:42 AM UTC+2, rjf wrote: > > > > On Saturday, September 27, 2014 1:21:28 PM UTC-7, Volker Braun wrote: >> >> I guess you are really happy about python3, then. >> >> $ python3 >> Python 3.4.1 (default, Sep 7 2014, 11:02:45) >> [GCC 4.9.1 20140813 (Red Hat 4.9.1-7)] on linux >> Type "help", "copyright", "credits" or "license" for more information. >> >>> 1/2 >> 0.5 >> >> I don't know what other new features it might have, but this one, it > seems, would > also interfere with Sage. Why can't it just be 1/2 ? > Python's designers decided that rational numbers are too scary to have as builtins. An unaware user could accidentally write a program that grinds to a halt by doing a computation in which denominators grow without bound. Remember, most users cannot be assumed to know the difference between rational and floating-point arithmetic, and it's almost always better to be fast than correct by default (especially in a language that already takes 100 cycles to compute 1 + 1). As a general principle, in any computing system, it should always be the user's responsibility to go out of their way if they want correct. /s Fredrik -- 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.
Re: [sage-devel] Re: Why I don't think Sage has "failed" as a replacement for Maple, Mathematica and other Ma*'s
On Sunday, September 28, 2014 12:00:42 AM UTC+1, rjf wrote: > > >>> 1/2 >> 0.5 >> > I don't know what other new features it might have, but this one, it > seems, would > also interfere with Sage. Why can't it just be 1/2 ? > Because, like most real-world programming languages (or, for that matter, the x86 CPU series), it has no rationals built-in. It will not interfere with Sage just like C division currently does not interfere: Sage integers are different for Python integers (with suitable type promotions to make it easy to use) -- 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.
Re: [sage-devel] Trac and sort by lastmod
> This is nearly useless, though, except for tickets modified since the last > Sage (official) release. Is there any way to get back to the "old" system > where the milestone would change *without* changing the ticket - and hence > the ticket last-mod time? It is very misleading to see ticket #xyz > modified three weeks ago and it turns out that it was last substantively > modified in 2008. +1 definitely -- 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.
Re: [sage-devel] Trac and sort by lastmod
On 2014-09-26 14:50, kcrisman wrote: I wish I could! I recall that Jeroen had to always ask someone else to change the milestone, even he didn't have access to it as release manager :) Nobody ever told me how it was done, but I assume it was indeed a direct manipulation of the Trac database. -- 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.
