Re: [sage-devel] Bug in abs(I*x).diff(x)
possibly related to http://trac.sagemath.org/ticket/12588 ?
Regards, CH
Am 2014-11-13 um 06:19 schrieb Ondřej Čertík:
> Hi,
>
> With Sage 6.3, I am getting:
>
> sage: abs(x).diff(x)
> x/abs(x)
> sage: abs(I*x).diff(x)
> -x/abs(I*x)
>
> But abs(I*x) == abs(x). So also abs(x).diff(x) and abs(I*x).diff(x)
> must be the same. But in the first case we get x/abs(x), and in the
> second we got -x/abs(x).
>
> In SymPy, the answer is:
>
> In [1]: abs(x).diff(x)
> Out[1]:
> d d
> re(x)⋅──(re(x)) + im(x)⋅──(im(x))
> dxdx
> ─
>│x│
>
>
> In [2]: x = Symbol("x", real=True)
>
> In [3]: abs(x).diff(x)
> Out[3]: sign(x)
>
> In [4]: abs(I*x).diff(x)
> Out[4]: sign(x)
>
> In [26]: var("x")
> Out[26]: x
>
> Which seems all correct --- in the complex case [1] we get a little
> messy expression, but a correct one. For a real case, we get the
> correct answer.
>
> In Wolfram Alpha, the answer of abs(I*x).diff(x) is x/abs(x):
>
> http://www.wolframalpha.com/input/?i=Diff%5BAbs%5Bi*x%5D%2C+x%5D
>
> Which is only correct for real "x", but at least it is correct for
> this special case.
>
> The Sage result seems wrong for any "x".
>
> Ondrej
>
--
Univ.-Prof. Dr. Clemens HeubergerAlpen-Adria-Universität Klagenfurt
Institut für Mathematik, Universitätsstraße 65-67, 9020 Klagenfurt, Austria
Tel: +43 463 2700 3121Fax: +43 463 2700 99 3121
clemens.heuber...@aau.athttp://wwwu.aau.at/cheuberg
--
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] Bug in abs(I*x).diff(x)
Hi,
With Sage 6.3, I am getting:
sage: abs(x).diff(x)
x/abs(x)
sage: abs(I*x).diff(x)
-x/abs(I*x)
But abs(I*x) == abs(x). So also abs(x).diff(x) and abs(I*x).diff(x)
must be the same. But in the first case we get x/abs(x), and in the
second we got -x/abs(x).
In SymPy, the answer is:
In [1]: abs(x).diff(x)
Out[1]:
d d
re(x)⋅──(re(x)) + im(x)⋅──(im(x))
dxdx
─
│x│
In [2]: x = Symbol("x", real=True)
In [3]: abs(x).diff(x)
Out[3]: sign(x)
In [4]: abs(I*x).diff(x)
Out[4]: sign(x)
In [26]: var("x")
Out[26]: x
Which seems all correct --- in the complex case [1] we get a little
messy expression, but a correct one. For a real case, we get the
correct answer.
In Wolfram Alpha, the answer of abs(I*x).diff(x) is x/abs(x):
http://www.wolframalpha.com/input/?i=Diff%5BAbs%5Bi*x%5D%2C+x%5D
Which is only correct for real "x", but at least it is correct for
this special case.
The Sage result seems wrong for any "x".
Ondrej
--
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: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
Hi, On Tue, Nov 04, 2014 at 08:15:32AM -0500, Jason Grout wrote: > > I agree with both of you. Given that a significant part of this > article dwelt on the closed-source bug-reporting frustration, it > might be even more interesting if the user was taken through an > actual bug found in Sage, and the bug-reporting and bug-fixing > process was described, emphasizing the open approach and the role > the authors could play. May i witness that claiming "Sage has bugs" in an oral presentation about Sage usually has a good impact. Not hiding problems is an important feature of free software and it is important to advocate it. Four years ago, i was asked to present Sage during a workshop about analytic combinatorics. This community really feels locked with Maple (on which their historical code depends) since most bug they report are not fixed (and they can not fix themselves). I wanted to show the resolution of a problem i had for my own research http://trac.sagemath.org/ticket/10063 but during the presentation i wanted to show a simple integral, so i picked a random one which turned out to be clearly false http://trac.sagemath.org/ticket/10923 this was somehow even greater since now when i meet someone from there, i can show how it has been fixed (especially in this case it was about discussing with upstream, thanks to kcrisman). They are still Maple-addict but we are working on that ;) More recently, i gave a talk about Sage in a lab where some people are working on braid groups. In the train, i was preparing a slide about that and fell into the bug which is now http://trac.sagemath.org/ticket/16059 Instead of avoiding it, i showed how the Cayley graph was looking like a tree, and discussed about bug reporting. Now the bug is fixed and it is clear that i will introduce my forthcoming seminar (not about Sage) there by showing the progress made on this (as well as the remaining problem about general groups defined with relations that still have inconsistent hash functions). So, do not fear with improvising computations during demos, the blue screen of death is a good way to ask for help in the assembly, speak about free software, and so on, we are not just selling a product. 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+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: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
Sadly, from a computer science perspective there are more questions raised than answered. Like how was it shown that this complicated system of algorithms was fast and accurate? (Requires testing). Is Sage better than the other open source programs on this task for usual (small?) cases or large. What is the relationship of exact and floating-point determinant calcs. How relevant is the Hadamard bound in actuality? Can floats or bigfloats be used to refine the bound? And I don't think you want to go down a road that suggests that only one program's results is OK (somehow implicitly checked??) if the program is open-source .. On Friday, October 24, 2014 5:55:39 PM UTC-7, jason wrote: > > The AMS Notices has a column about using computers to do math, dwelling > on some problems they had with Mathematica: > > http://www.ams.org/notices/201410/rnoti-p1249.pdf > > The HackerNews discussion immediately brings up Sage, of course: > https://news.ycombinator.com/item?id=8505665 > > Funny quote (that I don't necessarily agree with): "This resembles the > well- known Pentium division bug discovered by Thomas Nicely in 1994, > which only affected certain kinds of numbers. But it seems Mathematica > is a black box even darker that the internals of a microprocessor, so it > is difficult to try to understand what kinds of numbers are affected by > the Mathematica bug that we are describing." > > Interestingly, throughout the article, they emphasize what a hard time > they had when the found MMA and Maple conflicting, and the problems with > having MMA be closed-source. You'd think they'd end with a resounding > recommendation to use open-source software whereever possible, and fund > and motivate it's development. However, their final recommendation > backpedals quite a bit and is just "However, for the time being, when > dealing with a problem whose answer cannot be easily verified without a > computer, it is highly advisable to perform the computations with at > least two computer algebra systems." > > Thanks, > > Jason > > P.S. It would be interesting to see if Sage can do the calculation they > identified as buggy in mathematica. That would make for a cool > follow-up editorial. > -- 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: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
On Wed, Nov 12, 2014 at 12:35 PM, Ursula Whitcher wrote: >> On Mon, Nov 10, 2014 at 3:08 PM, Ursula Whitcher >> wrote: >>> >>> On 11/5/2014 8:24 AM, William Stein wrote: >>> * By "we write up" above, I mean you write up something very, very rough, post it here, and get feedback. >>> >>> >>> >>> Done! >>> >>> http://people.uwec.edu/whitchua/notes/sagebugprocess.pdf > > > Article at > > http://people.uwec.edu/whitchua/notes/sagebugprocess.pdf > > has been updated based on feedback. Regarding "Automatic testing provides Sage with resilience and makes it easier for multiple developers to contribute to different parts of the code base.", I wonder if adding a number might be useful, to give a sense of the scope of automated testing? I guess there are "well over 150,000" separate inputs that are regularly automatically tested, since: /scratch/wstein/sage-6.4.rc1/src/sage$ grep -r "sage:" *.py */*.py */*/*.py */*/*/*.py */*/*/*/*.py|wc -l grep: */*/*/*/*.py: No such file or directory 168537 There's also maybe 5000+ (??) lines of examples in other documentation In addition, something we worked very very hard on was increasing the percentage of functions that have tests in their docstring. /scratch/wstein/sage-6.4.rc1$ ./sage -coverageall Overall weighted coverage score: 94.2% Total number of functions: 37036 We need 304 more functions to get to 95% coverage. We need 1786 more functions to get to 99% coverage. Heh, wouldn't it be awesome to get to 95%? We only need 304 more functions to get doctests. That said, I'm very happy to see that number solidly over 90%, especially because this includes methods starting with underscores. William > > UAW > > > -- > 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. -- 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/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
On Wed, Nov 12, 2014 at 12:18 PM, Ursula Whitcher wrote: > On 11/11/2014 3:41 AM, Dr. David Kirkby (Kirkby Microwave Ltd) wrote: > >> If I am honest, I am not that convinced it is a good follow up comment, > > > OK, I won't put your name on it ;) > >> but ignoring that, if this was to be the basis of an article, I can >> think of some improvements. > > > Thanks for the comments! > >> 1) Add a time line. How long it took from the reporting of the bug, to >> the bug fixed, peer reviewed, then to release of a new >> alpha/beta/release candidate and finally to the release of a stable >> version with the bug fixed. >> >> I suspect it was faster than the year or so the bug has remained in >> Mathematica. > > > All I can see from trac is that everything happened 22 months ago. How do I > find how long it took to go from positive review to stable release? > >> 2) Take out the early reference to Sage getting the determinate correct >> that Mathematica gets right. Apart from boasting rights, I am not >> convinced it adds anything useful. > > > It gives us an excuse to show off the public worksheet. I could relegate > this to a footnote, though. When that article appeared, tons of people who uses Sage *immediately* asked "Does Sage have that bug?" Even before they heard what the bug is. And several people quickly got to work behind the scenes figuring out what the bug was exactly and whether or not Sage could do the computation (note several posts by Jason Grout). And when Rob Dodier heard about this, he was immediately working out whether or not Maxima has that bug. It's the obvious question to answer right off. To say it adds nothing is incorrect. > >> 3) The initial priority is stated to be major, but the priority can be >> changed by others, and most obviously by the release manager. So not >> every "blocker" bug gets fixed by the next release of Sage. > > > But the ones that aren't fixed are no longer blockers, right? The definition of a blocker is that we do not release Sage until all blockers are either closed or we decide they should be changed to a lower priority. So just reword your statement to say that we do not make an official release with any open blocker tickets. It's (subtly) different from what you had written. > > UAW > > > -- > 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. -- 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/d/optout.
Re: [sage-devel] Re: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
On Mon, Nov 10, 2014 at 3:08 PM, Ursula Whitcher wrote: On 11/5/2014 8:24 AM, William Stein wrote: * By "we write up" above, I mean you write up something very, very rough, post it here, and get feedback. Done! http://people.uwec.edu/whitchua/notes/sagebugprocess.pdf Article at http://people.uwec.edu/whitchua/notes/sagebugprocess.pdf has been updated based on feedback. UAW -- 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: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
On 11/11/2014 4:46 AM, Jeroen Demeyer wrote: * The sentence "A recent tweak of another part of Sage’s matrix code had changed the definition of “small n” to n <= 63." is wrong: what had changed is the bound on p to compute the determinant over GF(p) using LinBox (for larger p, we compute determinants over GF(p) by lifting to ZZ): it used to be the case that the bound in LinBox depended on n, this was changed to a fixed bound for p which was less than the old value for n <= 63. What's the fixed bound? UAW -- 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: The Misfortunes of a Trio of Mathematicians Using Computer Algebra Systems
On 11/11/2014 3:41 AM, Dr. David Kirkby (Kirkby Microwave Ltd) wrote: If I am honest, I am not that convinced it is a good follow up comment, OK, I won't put your name on it ;) but ignoring that, if this was to be the basis of an article, I can think of some improvements. Thanks for the comments! 1) Add a time line. How long it took from the reporting of the bug, to the bug fixed, peer reviewed, then to release of a new alpha/beta/release candidate and finally to the release of a stable version with the bug fixed. I suspect it was faster than the year or so the bug has remained in Mathematica. All I can see from trac is that everything happened 22 months ago. How do I find how long it took to go from positive review to stable release? 2) Take out the early reference to Sage getting the determinate correct that Mathematica gets right. Apart from boasting rights, I am not convinced it adds anything useful. It gives us an excuse to show off the public worksheet. I could relegate this to a footnote, though. 3) The initial priority is stated to be major, but the priority can be changed by others, and most obviously by the release manager. So not every "blocker" bug gets fixed by the next release of Sage. But the ones that aren't fixed are no longer blockers, right? UAW -- 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: Posets: interval/closed_interval
That's exactly what I'm saying. With this change, that may not occur if someone had overwritten interval() with some slightly different behavior in a subclass and was calling closed_interval(), they would experience an unexpected change (or, perhaps more likely, a major slow-down). It would be calling the interval() of FinitePoset rather than the subclass. Best, Travis On Tuesday, November 11, 2014 10:33:26 PM UTC-8, Nathann Cohen wrote: > > This would check against code within Sage, but anyone who has private code >>> could experience unexpected changes (granted it's unlikely, but it is >>> visible by the user that is not fixing a bug). I'd just leave this alone as >>> it doesn't hurt anyone. >> >> > Travis, don't you think that everybody, on the contrary, EXPECTS that > interval return the same thing as closed_interval in subclasses, exactly as > it does for the main one ? > > Nathann > -- 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: tab completion for list of associated objects
The Sage code style is that methods are preferred over properties if in doubt. And even in plain Python I would really recommend to only use properties for static accessors. If you need to make a computation, use a method. This makes it clear to the user that there is a computation involved, even if it is just enumerating the possible representations for future use. It might be a minor inconvenience to have to write sage: A=MyFavouriteAlgebra() sage. A.representations() sage: _. but its much more annoying to have A.representations. hang for a long time and then potentially raise an out of memory error etc. Also your UI might automatically collect tab completions before you even press tab. On Monday, November 10, 2014 1:05:54 AM UTC, Andrew wrote: > > Hi Travis, > > Sure this is one way of doing this but the whole point of my question is > that I want tab-completion to produce a discoverable list of possible > representations -- and tab-completion can't work for function arguments. > Of course the documentation for a "representation" method could list the > possible choices but I would like a more direct interface than this. > > I mentioned namedtuple() in the question. Another option, that is already > used quite a bit, is the "catalog" mechanism behind groups. and > codes., but this creates a static list of methods so it's not ideal. > > Andrew > > On Monday, 10 November 2014 11:38:22 UTC+11, Travis Scrimshaw wrote: >> >> I would think the closest thing we have to this currently is having >> "representation" accept a string input which redirects to the appropriate >> class. AFAIK, we have any "official" convention about this. IMO, the single >> method approach is best. >> >> 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.
