Re: [sage-combinat-devel] Re: StandardTableaux broken
Hi Darij, I still have a sage-5.4.1 with all combinat patches up to december 2012 on another machine, and t.descents() does what I expect. I admit that descents is a bad name for this (these are the descents of the inverse permutation of the row reading in French convention, in French we use reculs ( = recoils, or backsteps), but it is traditional to use descents in English. Btw, the name major index comes from the military rank of McMahon (Foata and Schutzenberger called it the major's index) , so there is only one major index All the best, Jean-Yves Le mercredi 16 octobre 2013 22:07:38 UTC+2, Andrew Mathas a écrit : Hi Darij, I've not yet needed descent sets of tableaux in sage so I don't know what the code did previously or what it does now in this respect. I would hope, however, that a descents method for tableaux would return the descent set of a tableau, so if you have ensured that this is now happening I think that's great! Andrew On Wednesday, 16 October 2013 20:32:11 UTC+2, darijgrinberg wrote: Hello Jean-Yves, hello Andrew, I guess I should have something to say about this but I don't really understand what is happening. When I wrote the #7983 patch, I was being annoyed by the fact that there was no method on the Tableaux class computing what everyone in combinatorics calls the descents, whereas the descents() method on tableaux was computing something rather unrelated (that, moreover, depends only on the shape if the tableau is semistandard). I suspect the descents() method was some kind of helper function for Jack or H-L related code. Anyway, I decided to rename the old descents() method into a less ambiguous name and to make descents() compute the actual descents. But I've quickly got talked out of this, as this would deprecate some userbase code, so instead I added a standard_descents() method and left descents() untouched (only adding the warning to its doc). I was working on sage-main all the time. Now, Jean-Yves (who, as far as I understand, has been using sage-combinat) is saying he has been using descents() all the time and since he is talking about standard tableaux, I assume that function has been computing the actual descents rather than whatever it has been computing on sage-main. Does this mean that the descents() function on sage-combinat has been doing something completely different from that on sage-main all the time before my #7983 patch? That someone had done what I first had in mind (rename the old descents() and reuse the name for the actual descents) long ago, and now that my #7983 got merged in, the roles have switched? Either way, sorry for contributing to this muckup and thanks a lot for any help in understanding it. Best regards, Darij -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Re: StandardTableaux broken
Hi Jean-Yves and everyone, OK, so it seems that some patch on the sage-combinat queue as of sage-5.4.1 solved the descents() problem in a more radical way than my sage-main patch. When my patch got merged into sage-main, the sage-combinat page would no longer apply, and so descents() once again became the old weird faux-descents function, while the correct descents function was now named standard_descents(). I wish I could confirm this but there seems to be no way to see the sage-combinat patches without being on the queue, let alone to see the old patches that are no longer in the queue. Either way, we should think about descents() when we rewrite tableau.py. Best regards, Darij On Thu, Oct 17, 2013 at 2:06 AM, Jean-Yves Thibon jythi...@gmail.com wrote: Hi Darij, I still have a sage-5.4.1 with all combinat patches up to december 2012 on another machine, and t.descents() does what I expect. I admit that descents is a bad name for this (these are the descents of the inverse permutation of the row reading in French convention, in French we use reculs ( = recoils, or backsteps), but it is traditional to use descents in English. Btw, the name major index comes from the military rank of McMahon (Foata and Schutzenberger called it the major's index) , so there is only one major index All the best, Jean-Yves Le mercredi 16 octobre 2013 22:07:38 UTC+2, Andrew Mathas a écrit : Hi Darij, I've not yet needed descent sets of tableaux in sage so I don't know what the code did previously or what it does now in this respect. I would hope, however, that a descents method for tableaux would return the descent set of a tableau, so if you have ensured that this is now happening I think that's great! Andrew On Wednesday, 16 October 2013 20:32:11 UTC+2, darijgrinberg wrote: Hello Jean-Yves, hello Andrew, I guess I should have something to say about this but I don't really understand what is happening. When I wrote the #7983 patch, I was being annoyed by the fact that there was no method on the Tableaux class computing what everyone in combinatorics calls the descents, whereas the descents() method on tableaux was computing something rather unrelated (that, moreover, depends only on the shape if the tableau is semistandard). I suspect the descents() method was some kind of helper function for Jack or H-L related code. Anyway, I decided to rename the old descents() method into a less ambiguous name and to make descents() compute the actual descents. But I've quickly got talked out of this, as this would deprecate some userbase code, so instead I added a standard_descents() method and left descents() untouched (only adding the warning to its doc). I was working on sage-main all the time. Now, Jean-Yves (who, as far as I understand, has been using sage-combinat) is saying he has been using descents() all the time and since he is talking about standard tableaux, I assume that function has been computing the actual descents rather than whatever it has been computing on sage-main. Does this mean that the descents() function on sage-combinat has been doing something completely different from that on sage-main all the time before my #7983 patch? That someone had done what I first had in mind (rename the old descents() and reuse the name for the actual descents) long ago, and now that my #7983 got merged in, the roles have switched? Either way, sorry for contributing to this muckup and thanks a lot for any help in understanding it. Best regards, Darij -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Re: StandardTableaux broken
Perhaps I can add a couple of words to Andrew's answer: I guess that the short (but harsh) answer is that if you have code which relies upon some one else's code which is in the queue, but which is not yet merged into sage, then there is no guarantee that your code will work next year, or even tomorrow. Any code which is merged should still work or, at a minimum, it should provide useful error messages to help you sort out what is going wrong (but this is only guaranteed in the first year after the change). I have certainly had this problem with my own private code and with the code that I have languishing in the queue. It might be a misconception that code related to combinatorics is only in the sage-combinat queue. Most code is merged into sage and distributed with each release of sage. The sage-combinat queue is used to share code that is being developed among researchers and developers. This code can indeed change any time (some code might even be experimental). Hence, if you are interested in reliable code it is better not to apply the sage-combinat queue. To use only code in sage you can do hg qpop -a sage -br or alternatively change to sage-main. Also, since the development flow will soon change to git, the sage-combinat queue will most likely disappear soon and/or will be replaced by a git fork or git branches. This is forced upon us by the move to git, but it is a good opportunity to change part of our work flow that has not worked so well. For example, it might be good that under the git framework the linear queue will change into a much flatter framework (since many patches do not actually depend on each other). As I haven't used (or touched) the methods that you are having issues with I don't know whether they were just in the queue or whether they were already part of the official sage distribution. If these methods were already included in an official release then clearly the review process has not worked properly in this instance and you have a legitimate complaint. Looking at the patch queue, robinson_schensted_inverse was depreciated in trac8392 http://trac.sagemath.org/attachment/ticket/8392. It seems to have been replaced with RSK_inverse which just seems wrong to me: with tab-completion I don't see the need for random acronyms, even relatively common ones like this one. (This probably just reflects my own idiosyncrasies:) Part of the deprecations have been reverted in http://trac.sagemath.org/ticket/15142 Franco, Mike and I had also observed what Andrew just mentioned and asked the authors to revert part of their changes. I think the review process might not have worked so well recently. For big changes like this a discussion should be done before completely revamping the methods that already exist. Returning to the question of the descents method, irrespective of whether it is backwardly compatible, I think it should the descent set of a tableau is what any reasonable algebraic combinatorialist would expect this method to return. Anything else is implementation-bug and it should be fixed. I agree. Best, Anne -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-combinat-devel] Re: StandardTableaux broken
Hey Andrew and Jean-Yves, Looking at the patch queue, robinson_schensted_inverse was depreciated in trac8392 http://trac.sagemath.org/attachment/ticket/8392. It seems to have been replaced with RSK_inverse which just seems wrong to me: with tab-completion I don't see the need for random acronyms, even relatively common ones like this one. (This probably just reflects my own idiosyncrasies:) There is also robinson_schensted_knuth[_inverse] methods in the global namespace with #15142 http://trac.sagemath.org/ticket/15142. And to get an output as a word, use the output='word' option. Note that the output will be an honest word object, not a permutation since non-standard permutations can break some of Permutations methods. If it is indeed a standard permutation, you can use output='permutation'. Well, I have changed descents to standard_descents, but I still have problems with the next two lines of my file. I use robinson_schensted_inverse. I see that it is deprecated (and certainly it should be, it did not even return a correct result one year ago and I had to patch it). So, deprecated, OK, but it still exists, and returns a different type now. Instead of a word (as it should be) it returns a list of two lists. This is bad. I can easily replace w by w[1]. But this is still not a word, and my function had to compute its descent composition. So it fails. I replace w by Word(w[1]). It fails again, as words do not have anymore a descents_composition ... So it is now Word(w[1]).standard_permutation().descents_composition(), and so on ... I see two possibilities to simplify this. The first is we add a descents_composition() method to words which just calls self.standard_permutation().descents_composition() (or perhaps its own optimized computation). The second would be to give RSK_inverse a checkargument which only checks for standardness if True and passes it to permutation if ouput='permutation'. I'm in favor of the former. Best, Travis -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: the __NO_INLINE__ constant in Sage's GCC
Ahahaah. Thaaanks ! ;-) Nathann On Wednesday, October 16, 2013 11:46:54 AM UTC+2, Volker Braun wrote: On Wednesday, October 16, 2013 9:03:38 AM UTC+1, Nathann Cohen wrote: While messing around with #13352, I noticed that there was a preprocessor constant in Sage's GCC named __NO_INLINE__ whose purpose is, I guess, to prevent any function from being inlined. Close, but no cigar. It is defined so your code can find out if gcc is compiling it with -fno-inline (which is implicit in -O0): $ gcc -dM -E - /dev/null | grep NO_INLINE #define __NO_INLINE__ 1 $ gcc -dM -E -O1 - /dev/null | grep NO_INLINE $ gcc -dM -E -O1 -fno-inline - /dev/null | grep NO_INLINE #define __NO_INLINE__ 1 Using it (as any preprocessor that starts with a double underscore) is of course extremely compiler-dependent and best avoided. The main use for __NO_INLINE__ is the glibc headers. -- 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/groups/opt_out.
Re: [sage-devel] Should the Sage manual mention SageMathCloud?
On Wed, Oct 16, 2013 at 1:07 AM, Robert Bradshaw rober...@gmail.com wrote: On Sun, Oct 13, 2013 at 2:26 PM, William Stein wst...@gmail.com wrote: On Sun, Oct 13, 2013 at 1:16 PM, Vincent Delecroix 20100.delecr...@gmail.com wrote: thought was that Sage is a math software, open source, with the aim of being a viable alternative to Ma*. There was no mention of a cloud which is just the incompatible with the open source project (as the FSF defines it). Why do you think that the existence of a cloud that provides an additional way to use Sage is compatible with Sage being an open source project?To me that's no different than claiming that the existence of websites running on servers running Linux is incompatible with Linux being an open source project. My very personal opinion is that the cloud is a bad way of making Sage popular: it makes the users dependent of a service. If good = not dependent and bad = dependent, then indeed it is bad. I do not define good and bad that way. I'm more concerned with providing valuable services to people, making it easier for people to get work done, and providing ways to collaborate. I want to grow the community of users of open source math software, and I'm probably not the first person to realize that a website-based approach is a powerful tool for addressing some of these goals. Up to now, I learned a lot with Sage and I hope that I contributed equivalently on teaching with it, going to Sage days, contributing with my code, etc. Sage was for me part of the public domain. If the cloud really becomes the main way of using Sage it will be for me like a dispossession. The cloud implies - the obligation of using the cloud to share code - no control on the execution of the softwares - no direct access to the source code - no way to use your own editor These are all valid concerns for anybody choosing whether or not to use Sage (or anything else) via any computer that isn't their own personal computer. Even if a large number of people were to someday use Sage via the cloud, this doesn't mean that everybody does. You can -- and will *always* be able to -- use Sage in any way you want (compatible with the GPL). If many more people are using Sage (in any way, cloud or not), then the number of contributions to Sage itself will increase, the quality of Sage goes up, getting support for Sage development gets easier, etc., which will mean that your personal cloud-free use of Sage will be improved. Everybody wins in the Sage community wins. User attention is a zero-sum game (unless there are new markets), so somebody has to loose in this scenario--it isn't us Sage users -- it's the Ma*'s. I actually don't think it's a zero-sum game; I'm hopeful Sage can also be useful to people who otherwise wouldn't even use a computer to do mathematics, and convenient/helpful enough for people to use computers for this kind of work even more. In other words, making the total pie bigger. Being a viable alternative to the Ma*s is at least as important to those who don't/can't have access to them as to those who do. I view it the same way. It's worth pointing out that there is a risk here for cloud-free Sage. What you haven't done is clearly outline what part of the cloud product will be open and what parts won't be. At the one extreme, all the source, configuration, etc. is open and the value-add of the sagemath.com is a professionally-administered hosting with lots of hardware and support (which, yes, anyone could clone and try to compete with, though the original that devotes its profits to the improvement of Sage should attract the best/most devoted employees and, consequently, offer the best support). At the other end is a very closed system where bug-fixes and improvements to core Sage itself are withheld from the public version (which could be legal according to the GPL, if you're just distributing results, not code). My understanding is that the sagemath cloud won't live at either of these extremes, but I would consider it sad if peripheral things like the UI or better 3d graphics and interacts never made it out to the open source project. There's also the concern of lock-in. Ideally, a notebook could be created on the cloud, downloaded and run in a cloud-free way (say, on an airplane w/o internet, or on your department's latest hardware dedicated to your research, or over data to sensitive to trust to the cloud), then even re-uploaded. Delineating a concrete goal here would be good. Cloud.sage now supports the IPython notebook, which has zero lock-in. You can run exactly the same notebook locally, without internet access (assuming of course that you have all the dependencies installed). Before sage.cloud and ipython notebook a few years ago, even though I really liked the Sage notebook, it was only used for Sage, and so the community didn't grow beyond it. I tried to disentangle it (with
Re: [sage-devel] Transitivity of coercion discovery
On Monday, October 14, 2013 9:38:02 PM UTC-7, Robert Bradshaw wrote: This is definitely a bug, This is now http://trac.sagemath.org/ticket/15303 -- 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/groups/opt_out.
Re: [sage-devel] Should the Sage manual mention SageMathCloud?
On 12 October 2013 18:21, William Stein wst...@gmail.com wrote: Maybe. One important fact is that -- measured by downloads or website hits -- usage of Sage (the free software) has *not* grown at all in the last 3 years. For example, if you define number of active users as at http://trac.sagemath.org/ticket/1000, then the number of users has floated between 10,000 and 15,000 for several years.This suggests perhaps Sage is not fully succeeding at the mission statement I set for the project at the beginning, which is to provide a viable alternative to the Ma's, since they claim much larger active usage numbers. I do wonder where they get their numbers from some times. Wolfram Research claimed over a million users more than a decade ago, but why do I see so few jobs wanting Mathematica skills? Search on a job site for jobs needing MATLAB and there are tons of them. Do the same for Mathematica, and there are very very few indeed. I do wonder how large the user base of Mathematica really is. Dave -- 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/groups/opt_out.
Re: [sage-devel] Re: Transitivity of coercion discovery
The only primary embeddings are stored on the domain is for lifetime implications. If we can detangle these two (which I've always wanted to do) then we could always store them on the codomain. It is, however, useful to be able to query a parent for embeddings (e.g. AA - RR for any particular precision). Maybe this can always be handled with an intermediate field that all the codomains know about. As long as the coercion graph is constructed lazily, I don't know that it's possible to respect the digraph model. For example, if we have X - Y - Z, the mere creation of Y induces a coercion from X to Z that might not have existed (or be easily detected) previously, and it's hard to disallow this (though perhaps we can, I can't think of a valid usecase right now). On Tue, Oct 15, 2013 at 1:00 AM, Nils Bruin nbr...@sfu.ca wrote: On Tuesday, October 15, 2013 12:10:15 AM UTC-7, Simon King wrote: Ultimately, the coercion system is asking the involved parents which coercions they know of. There is no other location that would store coercions. That's how we implement it. If that's insufficient then we fail to properly implement the digraph model. We'll have to change at least one of our implementation or our model. For the purpose of path discovery, it is just a complication to have to consider both embedding and coerce_from. We'd be better off with only one. Then it's just a single backtrack process rather than a mixed Of course there are other reasons why we have both. After #14711, there are lifetime implications: A coercion registered as embedding ensures that domain keeps codomain alive, whereas one registered on coerce_from_list ensures that codomain keeps domain alive. I'd think it's better to not blur the two functions: Simply make the path discovery system have as little lifetime implications as possible (i.e., store coercions weakened [this means: having only a weak reference to the domain if possible] on the codomain, a la coerce_from_hash) and in addition store separately, references domains_to_keep_alive and codomains_to_keep_alive to impose the correct lifetime implications. To a large extent, this could be done in the current model if the current coerce_from_list gets turned into a MonoDict, just as coerce_from_hash. The routine register_embedding would simply have to put the embedding in there, and perhaps keep putting it in other places too. Both `register_coercion` and `register_embedding` should probably adjust domains_to_keep_alive resp. codomains_to_keep_alive. -- 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/groups/opt_out. -- 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/groups/opt_out.
Re: [sage-devel] Should the Sage manual mention SageMathCloud?
On Thu, Oct 17, 2013 at 3:18 PM, Dr. David Kirkby drkir...@gmail.com wrote: On 12 October 2013 18:21, William Stein wst...@gmail.com wrote: Maybe. One important fact is that -- measured by downloads or website hits -- usage of Sage (the free software) has *not* grown at all in the last 3 years. For example, if you define number of active users as at http://trac.sagemath.org/ticket/1000, then the number of users has floated between 10,000 and 15,000 for several years.This suggests perhaps Sage is not fully succeeding at the mission statement I set for the project at the beginning, which is to provide a viable alternative to the Ma's, since they claim much larger active usage numbers. I do wonder where they get their numbers from some times. Wolfram Research claimed over a million users more than a decade ago, but why do I see so few jobs wanting Mathematica skills? Search on a job site for jobs needing MATLAB and there are tons of them. Do the same for Mathematica, and there are very very few indeed. I do wonder how large the user base of Mathematica really is. I think (jobs needing Mathematica) (jobs where Mathematica is/could be used). In my (limited) experience, Matlab lends itself more to being part of a full infrastructure/system which increases its necessity to do a job vs. use whatever tool you're comfortable with. The numeric vs. symbolic emphasis naturally biases it towards the industry (jobs) vs. academia too. (I can't imagine an Math Prof. listing that requires familiarity with Mathematica, outside of perhaps teaching.) Also, don't discount the (millions?) of college freshmen that use it once a week in their calculus lab :). - Robert -- 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/groups/opt_out.
Re: [sage-devel] Should the Sage manual mention SageMathCloud?
On Thu, Oct 17, 2013 at 3:18 PM, Dr. David Kirkby drkir...@gmail.com wrote: On 12 October 2013 18:21, William Stein wst...@gmail.com wrote: Maybe. One important fact is that -- measured by downloads or website hits -- usage of Sage (the free software) has *not* grown at all in the last 3 years. For example, if you define number of active users as at http://trac.sagemath.org/ticket/1000, then the number of users has floated between 10,000 and 15,000 for several years.This suggests perhaps Sage is not fully succeeding at the mission statement I set for the project at the beginning, which is to provide a viable alternative to the Ma's, since they claim much larger active usage numbers. I do wonder where they get their numbers from some times. Wolfram Research claimed over a million users more than a decade ago, but why do I see so few jobs wanting Mathematica skills? Search on a job site for jobs needing MATLAB and there are tons of them. Do the same for Mathematica, and there are very very few indeed. I do wonder how large the user base of Mathematica really is. We can make a very, very rough estimate of the Mathematica revenue based on the number of employees. For example, to get a low-ball lower bound, let's say 500 employees (*), which each cost $100K/year on average; that's $50million/year in revenue. If a Mathematica seat costs on average $50/year, then that's 1 million seats. There are other revenue sources, such as Wolfram|Alpha... Conclusion: Mathematica probably sells more than 10,000 seats of licenses a year, since selling only 10,000 seats wouldn't generate enough revenue to sustain their employee base, unless they have many other revenue streams. With webapps (of all kinds -- gmail, cloud.sagemath, whatever) it';s striking because the vendor knows exactly how many people use their service, for how long each day, with what frequency, etc. There is no guesswork at all in deducing usage. WRI has enough control to know how many legal copies of Mathematica get *installed*, but they know little about how often they are used (unless Mathematica secretly phones home, of course). For example, I installed mathematica on my laptop for a year, and didn't use it at all -- the first time I tried to use it, was during a talk, and it failed due to the license running out and me not noticing... :-) -- William (*) http://en.wikipedia.org/wiki/Wolfram_Research says 400+ employees. In 2008, their website said 650+ and Eric Weistein told me (in person) that they were expanding a lot then. Dave -- 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/groups/opt_out. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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/groups/opt_out.
Re: [sage-devel] Should the Sage manual mention SageMathCloud?
On Thu, Oct 17, 2013 at 3:42 PM, Robert Bradshaw rober...@math.washington.edu wrote: On Thu, Oct 17, 2013 at 3:18 PM, Dr. David Kirkby drkir...@gmail.com wrote: On 12 October 2013 18:21, William Stein wst...@gmail.com wrote: Maybe. One important fact is that -- measured by downloads or website hits -- usage of Sage (the free software) has *not* grown at all in the last 3 years. For example, if you define number of active users as at http://trac.sagemath.org/ticket/1000, then the number of users has floated between 10,000 and 15,000 for several years.This suggests perhaps Sage is not fully succeeding at the mission statement I set for the project at the beginning, which is to provide a viable alternative to the Ma's, since they claim much larger active usage numbers. I do wonder where they get their numbers from some times. Wolfram Research claimed over a million users more than a decade ago, but why do I see so few jobs wanting Mathematica skills? Search on a job site for jobs needing MATLAB and there are tons of them. Do the same for Mathematica, and there are very very few indeed. I do wonder how large the user base of Mathematica really is. I think (jobs needing Mathematica) (jobs where Mathematica is/could be used). In my (limited) experience, Matlab lends itself more to being part of a full infrastructure/system which increases its necessity to do a job vs. use whatever tool you're comfortable with. The numeric vs. symbolic emphasis naturally biases it towards the industry (jobs) vs. academia too. (I can't imagine an Math Prof. listing that requires familiarity with Mathematica, outside of perhaps teaching.) Also, don't discount the (millions?) of college freshmen that use it once a week in their calculus lab :). In fall 2013, a record 21.8 million students are expected to attend American colleges and universities, constituting an increase of about 6.5 million since fall 2000 (source). [1] That's just in the US. So worldwide there are likely well over a million people taking collage math classes (for which Mathematica is useful) right now. Anecdotally, a substantial fraction use Wolfram (alpha) to help with their homework... [1] http://nces.ed.gov/fastfacts/display.asp?id=372 - Robert -- 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/groups/opt_out. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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/groups/opt_out.
Re: [sage-devel] Re: Transitivity of coercion discovery
On Thursday, October 17, 2013 3:33:33 PM UTC-7, Robert Bradshaw wrote: As long as the coercion graph is constructed lazily, I don't know that it's possible to respect the digraph model. For example, if we have X - Y - Z, the mere creation of Y induces a coercion from X to Z that might not have existed (or be easily detected) previously, and it's hard to disallow this (though perhaps we can, I can't think of a valid usecase right now). It seems to me that the digraph can certainly not be expected to be independent of time. So indeed, if X, Z are first created, they are not related. Only when Y gets created with an embedding into Z and a coercion from X do we get a path. Presently I think the absence of a coercion between X and Z also gets cached, so if this absence was discovered before the creation of Y then even after the creation of Y one would find no coercion. It's pretty obvious that to get strict conformance, one would have to scrub caches for possibly invalidated data when the graph gets modified. One wouldn't just want to invalidate all of the cache, though. So finding a workable balance (perhaps not invalidating any cache?) would be preferable. Considering a real-world (but probably ill-advised) example: K.a=NumberField(x^2-2) Kt.t=K[] L.b=NumberField(t^2-a,embedding=RR(2^(1/4))) It doesn't actually work, because the embedding argument to L is silently ignored, but the example would imply (after the fact) an embedding of K into R via L. One shouldn't allow this, because one could easily imply multiple embeddings for number fields via extensions that would not agree. -- 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/groups/opt_out.
Re: [sage-devel] Re: how to run doctests?
See http://trac.sagemath.org/ticket/14582 :) Still on my todo list...but I'm now waiting until we switch to the git workflow, which should make the patchbomb easier to swallow... Best, Travis -- 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/groups/opt_out.
