Re: [sage-devel] Re: Sage code "for educational purposes only"?
I would say such a function belongs in the documentation only, and we should have an easy way of testing (and perhaps importing) code defined there. On Thu, Feb 26, 2015 at 12:19 PM, Travis Scrimshaw wrote: > >> > Should there be code in Sage which is extremely slow and for educational >> > purposes only? >> >> I believe such code is valuable. > > > I believe so as well. As Michael said, at the very least it's useful as a > testing tool. (Also we have done something similar by having an "algorithm" > keyword for various methods.) I also agree with Karl-Dieter that we should > spend much more time documenting the functions than moving them to a > separate folder (much less deciding on which functions should go into such a > folder). > > 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/d/optout. -- 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: Trac * hangs
All right: trac is globally incredibly slow... there is definitely something wrong... 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.
[sage-devel] Re: Sage code "for educational purposes only"?
> > Should there be code in Sage which is extremely slow and for educational > > purposes only? > > I believe such code is valuable. > I believe so as well. As Michael said, at the very least it's useful as a testing tool. (Also we have done something similar by having an "algorithm" keyword for various methods.) I also agree with Karl-Dieter that we should spend much more time documenting the functions than moving them to a separate folder (much less deciding on which functions should go into such a folder). 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/d/optout.
Re: [sage-devel] Re: should bool(x > 0) be False or an exception?
>I changed the code to return an exception if the truth value is unknown and ran `sage -testall`. Did you upload the patch to somewhere? Where this change has to be made? > I might be willing to fix these tests when I have time. It seems that nothing happens for more than a year, so maybe someone else has time to fix this? I opened a ticket : http://trac.sagemath.org/ticket/17700 Jakob Am Samstag, 10. August 2013 00:04:32 UTC+2 schrieb Eviatar: > > I changed the code to return an exception if the truth value is unknown > and ran `sage -testall`. Here are the results: > > sage -t devel/sage/sage/tensor/differential_form_element.py # 43 doctests > failed > sage -t devel/sage/sage/tensor/differential_forms.py # 1 doctest failed > > sage -t devel/sage/sage/calculus/tests.py # 4 doctests failed > > sage -t devel/sage/sage/calculus/calculus.py # 10 doctests failed > > sage -t devel/sage/sage/calculus/desolvers.py # 8 doctests failed > > sage -t devel/sage/sage/calculus/wester.py # 3 doctests failed > > sage -t devel/sage/sage/symbolic/assumptions.py # 8 doctests failed > > sage -t devel/sage/sage/symbolic/expression.pyx # Killed due to > segmentation fault > sage -t devel/sage/sage/symbolic/units.py # Killed due to segmentation > fault > sage -t devel/sage/sage/symbolic/relation.py # 2 doctests failed > > sage -t devel/sage/sage/matrix/matrix_symbolic_dense.pyx # 2 doctests > failed > sage -t devel/sage/sage/doctest/forker.py # 1 doctest failed > > sage -t devel/sage/sage/misc/functional.py # 2 doctests failed > > sage -t devel/sage/sage/misc/cachefunc.pyx # 1 doctest failed > > sage -t devel/sage/sage/combinat/tutorial.py # 9 doctests failed > > sage -t devel/sage/sage/tests/french_book/recequadiff.py # 25 doctests > failed > > Many of the failed tests are due to dependence on variables which would > have been assigned in previous tests, but failed due to the exception. I > might be willing to fix these tests when I have time. > > On Friday, 2 August 2013 07:04:42 UTC-7, Volker Braun wrote: >> >> I tend to be in favor of the True/False/raise Exception model for testing >> equality, but has anybody looked into what would be involved to transition >> the Sage ilbrary? I imagine we would have to adapt a lot of code. >> >> >> >> On Wednesday, July 31, 2013 5:33:30 AM UTC-4, kro...@uni-math.gwdg.de >> wrote: >>> >>> Am Sonntag, 13. April 2008 02:39:24 UTC+2 schrieb William Stein: >>> > On Sat, Apr 12, 2008 at 5:33 PM, Carl Witty >>> wrote: >>> > > >>> > > On Apr 12, 8:58 am, Jason Grout >>> wrote: >>> > > > Carl Witty wrote: >>> > > > > On Apr 10, 1:41 am, Simon King >>> wrote: >>> > > > >> On Apr 10, 4:18 am, Carl Witty wrote: >>> > > > >>> > > > >>> I like the "raise an exception" behavior, because it would >>> eliminate >>> > > > >>> questions asking why form1 and form2 below are different >>> (from this >>> > > > >>> sage-support threadhttp:// >>> groups.google.com/group/sage-support/browse_thread/thread/79d0...). >>> > > > >>> (I have seen this exact problem at least twice on >>> sage-support.) What >>> > > > >>> do you think? >>> > > > >> I guess what i suggest wouldn't solve the plot-issue. However, >>> i think >>> > > > >> if one doesn't know whether an inequality holds, or if the >>> inequality >>> > > > >> simply makes no sense (such as in the case of an unordered >>> field) then >>> > > > >> bool() should neither raise an exception nor return False but >>> return >>> > > > >> None. I think it is much simpler to have >>> > > >>> > > > The reason why I eventually decided that throwing an exception was >>> > > > unpythonic was that I could not find a single case of current >>> python >>> > > > code which did that. Actually, the one reference I did find was a >>> > > > bugfix to a project (I think SQLAlchemy), in which they changed >>> > > > __nonzero__ to not raise an exception since it was inconsistent >>> with >>> > > > other behavior. >>> > > > >>> > > > That, and the fact that Python by default returns True for objects >>> > > > instead of raising exceptions, tells me that raising exceptions >>> would >>> > > > also raise an exceptional number of eyebrows and probably voices >>> too. >>> > > >>> > > I agree that raising an exception is somewhat unpythonic, but I >>> don't >>> > > think that's an automatic veto on the idea. Sage does lots of >>> > > unpythonic stuff already, and I think we should at least consider >>> > > adding one more unpytho
[sage-devel] Re: Sage code "for educational purposes only"?
In general, I think it is FAR more useful to spend our time on making the documentation for any "educational"/"toy" functions very clear than to creating some huge change of a new directory that no one will know about, deprecation, broken links, ... Unless people feel that Sage is *only* a research tool, there is no reason not to have such functions, as long as it is very clear what they do and don't do. Anyone who is looking for speed will presumably be able to bother to read documentation that starts "The function easy_squirrel() is only to demonstrate the existence of a squirrel; for various algorithms used in actually finding squirrels, please see sage.squirrel.blazing_fast()". -- 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] sqrt(n) conversion/comparison
Assuming fp values cannot be equal, would it make more sense to test elementship in CC by implementing ComplexField.__contains__() instead of trusting Python or Maxima == ? -- 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] Re: Sage code "for educational purposes only"?
I don't like the "educational" name, since it can be misleading. Some could think that they are functions that are useful for teaching (in this case, for teaching basic concepts about prime numbers), whereas what we would be meaning is that its educational value would be in looking at the code itself and learning how to code. It is not the case of the Erathostenes sieve, but in some other cases (like buchberger), these toy methods are not only there for people to learn about them, but also can be used as a fallback for the cases where no fast implementation is available (yes, they can be horribly slow, but horribly slow is sometimes better than nothing). El miércoles, 25 de febrero de 2015, 18:55:17 (UTC+1), Jeroen Demeyer escribió: > > Hello, > > Should there be code in Sage which is extremely slow and for educational > purposes only? I am talking about eratosthenes() which is just a very > slow alternative to prime_range(). > > I would just remove that code, but maybe people have other opinions... > > Jeroen. > -- 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] Sage code "for educational purposes only"?
I really do not see the point of an educational-library if the code will not appear in the documentation. It is precisely the code which is interesting! 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] Sage code "for educational purposes only"?
I'm in favor of moving such toys to an educational-library. -- 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: Trac #17852 hangs
Still have some trouble with #17852. As soon as the Submit changes is more than just switching the ticket status. It hangs a lot! 2015-02-25 19:31 UTC+01:00, Vincent Delecroix <20100.delecr...@gmail.com>: > 2015-02-25 19:24 UTC+01:00, Volker Braun : >> Is the number correct? It works for me, but is a closed ticket. > > It is correct in the object but not in the body: it is #17852 > -- 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] Re: [Debian] Strange crash in ECL
On 2015-02-25, Jean-Pierre Flori wrote: > Not really related but it seems ECL saw an update! > they've just restarting - someone finally volunteered to become the maintainer of ECL... Hopefully it will presist, and we will see a new version soon. -- 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] [Debian] Strange crash in ECL
Le 26/02/2015 10:15, Julien Puydt a écrit : Le 26/02/2015 10:08, Francois Bissey a écrit : So I think we can say there is something going with gmp 6.0.0. I think that should narrow things down considerably. I'll report our findings to upstream -- that should definitely interest them, and help pinpoint the issue. I set ECL_OPT_SET_GMP_MEMORY_FUNCTIONS to 0 in src/c/main.d, and that made the crash disappear! Snark on #sagemath -- 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] [Debian] Strange crash in ECL
Le 26/02/2015 10:08, Francois Bissey a écrit : So I think we can say there is something going with gmp 6.0.0. I think that should narrow things down considerably. I'll report our findings to upstream -- that should definitely interest them, and help pinpoint the issue. Thanks! Snark on #sagemath -- 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] sqrt(n) conversion/comparison
We also have sage: RR(tan(pi/20)) == CC(tan(pi/20)) False But it seems right for cos, sin, exp, atan, cosh, sinh. Is there a way to test all symbolic functions? 2015-02-26 10:02 UTC+01:00, Ralf Stephan : > On Thursday, February 26, 2015 at 9:50:40 AM UTC+1, vdelecroix wrote: >> >> sage: bool(RR(sqrt(2)) == sqrt(2)) >> False >> sage: sqrt(2).n() == RR(sqrt(2)) >> True >> > These two come from bool(sqrt(2)==sqrt(2).n()) being False I think > (because Maxima is involved here) but this is different than > > sage: bool(sqrt(2).n()==CC(sqrt(2))) > False > > -- > 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. > -- 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] Sage code "for educational purposes only"?
On Thu, 26 Feb 2015, Pedro Cruz wrote: +1 for the package "educational-algorithms" but called "educational-packages" or "educational-library". Yes, '-packages' or '-library' is better name. Hmmm... actually there could be, in principle, three kind of algorithms: 1) Fast ones, that we normally use. 2) Educational, algorithms that made it easy to see some computational proof etc. 3) Most basic and directly from formal definition made algorithms to cross-check fast ones. Usually type 2 and 3 are same thing. Always? -- Jori Mäntysalo
Re: [sage-devel] [Debian] Strange crash in ECL
On 26/02/2015, at 21:47, Julien Puydt wrote: > > Le 26/02/2015 09:05, Francois Bissey a écrit : >> Ok what version of gmp? 5.1.3 here. > > I have 6.0.0. OK upgraded to 6.0.0a (the one I have available in the tree): > (setq b (expt a 600)) Condition of type: SEGMENTATION-VIOLATION Detected access to an invalid or protected memory address. Available restarts: 1. (CONTINUE) Ignore signal 2. (RESTART-TOPLEVEL) Go back to Top-Level REPL. Broken at SI:BYTECODES. [Evaluation of: (SETQ B …)] So I think we can say there is something going with gmp 6.0.0. I think that should narrow things down considerably. François -- 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] Sage code "for educational purposes only"?
Le mercredi 25 février 2015 20:56:06 UTC+1, kcrisman a écrit : > > Who on earth thinks that the Sieve of Eratosthenes is designed for modern > production work??? > Me. I´m using it for the ithprime function in Giac. ithprime(70) returns 10570841 in 0.07 second while in sage prime_range(1,10570841) takes about the same time (0.08s) to compute (much more to display). -- 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] Sage code "for educational purposes only"?
+1 for the package "educational-algorithms" but called "educational-packages" or "educational-library". MathSciNet catalog has the category "Mathematics education" http://www.ams.org/mathscinet/msc/msc2010.html?t=97-XX being the last topic after all the mathematical edge cutting works. This could inspire an "educational-library" (this name is maybe more general than just "algorithms"). Pedro On Thursday, February 26, 2015 at 6:23:36 AM UTC, Jori Mantysalo wrote: > > On Wed, 25 Feb 2015, Jeroen Demeyer wrote: > > > Should there be code in Sage which is extremely slow and for educational > > purposes only? > > As an additional package "educational-algorithms"? > > -- > Jori Mäntysalo > -- 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] sqrt(n) conversion/comparison
On Thursday, February 26, 2015 at 9:50:40 AM UTC+1, vdelecroix wrote: > > sage: bool(RR(sqrt(2)) == sqrt(2)) > False > sage: sqrt(2).n() == RR(sqrt(2)) > True > These two come from bool(sqrt(2)==sqrt(2).n()) being False I think (because Maxima is involved here) but this is different than sage: bool(sqrt(2).n()==CC(sqrt(2))) False -- 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] sqrt(n) conversion/comparison
Hello, There is something wrong sage: bool(RR(pi) == pi) True sage: bool(RR(golden_ratio) == golden_ratio) True which is fine to me. You coerce to the field with less precision. But sage: bool(RR(sqrt(2)) == sqrt(2)) False sage: sqrt(2).n() == RR(sqrt(2)) True sage: RR(sqrt(2)) == CC(sqrt(2)) False which is very wrong. Vincent 2015-02-26 9:41 UTC+01:00, Ralf Stephan : > Hi, > > with current Sage, > sage: bool(sqrt(2)==CC(sqrt(2))) > False > > You would expect that this leads to > sage: sqrt(2) in CC > False > but due to a bug I'm fixing atm in #12967 this returns True. > However, now that it's fixed I'm faced with the question if > answer to both really should be False. If one doctest in parent.py > is right both should be True. But how could Sage see that equation > holds if > sage: CC(sqrt(2)) > 1.41421356237309 > sage: sqrt(2).n() > 1.41421356237310 > so either there is a bug in SR+CC or the abovementioned doctest > is wromg. > > What do you think? > > Regards, > > -- > 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. > -- 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] [Debian] Strange crash in ECL
Le 26/02/2015 09:05, Francois Bissey a écrit : Ok what version of gmp? 5.1.3 here. I have 6.0.0. Snark -- 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] sqrt(n) conversion/comparison
Hi, with current Sage, sage: bool(sqrt(2)==CC(sqrt(2))) False You would expect that this leads to sage: sqrt(2) in CC False but due to a bug I'm fixing atm in #12967 this returns True. However, now that it's fixed I'm faced with the question if answer to both really should be False. If one doctest in parent.py is right both should be True. But how could Sage see that equation holds if sage: CC(sqrt(2)) 1.41421356237309 sage: sqrt(2).n() 1.41421356237310 so either there is a bug in SR+CC or the abovementioned doctest is wromg. What do you think? Regards, -- 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] [Debian] Strange crash in ECL
> On 26/02/2015, at 20:57, Julien Puydt wrote: > > Le 26/02/2015 08:20, Francois Bissey a écrit : >>> On 26/02/2015, at 20:12, Julien Puydt wrote: >>> >>> Le 25/02/2015 22:43, François Bissey a écrit : >>> That's fun, on Gentoo my ecl from the system just chew it without crashing. What options are you using to build ecl I currently have --enable-unicode -with-x and the rest turned off. Would it be thread related by any chance? >>> >>> Sage is using mpir and doesn't have the problem. >>> Debian is using gmp and does have the problem. >>> >>> What are you using? >> >> Oh, gmp just as you do. Using mpir is hard on sage-on-distro as >> you would know. > > Snif. The gmp vs mpir difference was my favored explanation after I ruled out > : > - disable-threads for ecl > - enable-large-config for Boehm's gc > > Debian and upstream-on-debian have the crash. I don't know what the upstream > developer was using when he reproduced it. > > Gentoo doesn't have the crash, and I had a report ubuntu didn't either. > Ok what version of gmp? 5.1.3 here. François -- 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.
