[sage-devel] Re: Re: slow arithmetic in number fields
David Roe a écrit : > More documentation is always good, but I would argue that the right > solution is to change the behavior of power series rings to line up with > p-adics. Would there be any difference left between A[[x]] and A[x]/(x^n), then? -- Marc -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Re: New Trac Server
R. Andrew Ohana a écrit : > To push the git branch > > 1) go into your preferences in trac; there is a new tab for adding ssh keys > - add an ssh key I don't seem to manage to authenticate with the ssh key I uploaded. Here is the log I get by running ssh -v manually: OpenSSH_6.2p2 Debian-6, OpenSSL 1.0.1e 11 Feb 2013 [...] debug1: Connecting to trac.sagemath.org [128.95.242.139] port . debug1: Connection established. debug1: identity file /home/marc/.ssh/sage_trac type 1 [...] debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1 debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH_5* [...] debug1: Authentications that can continue: publickey,password debug1: Offering RSA public key: /home/marc/.ssh/sage_trac debug1: Authentications that can continue: publickey,password debug1: Offering RSA public key: /home/marc/.ssh/id_rsa debug1: Authentications that can continue: publickey,password debug1: Next authentication method: password g...@trac.sagemath.org's password: Am I doing something wrong? Thanks, -- Marc -- 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.
[sage-devel] Re: New Trac Server
R. Andrew Ohana wrote: > It's like github in that there is no shell access and everyone is under the > same username 'git'. > > If you do > > ssh -v -p g...@trac.sagemath.org > > It should display the repositories you have read and/or write access to (in > this case it should just be the sage repository), and then dump you back > into your previous shell. Thanks for your reply! I think I understand that much. But it doesn't work for me: when I do that, ssh fails at the authentication stage, and asks me for the password of the git user, even though it also says it offered the private key (/home/marc/.ssh/sage_trac in my previous message) corresponding to the public key I pasted into the input field at http://trac.sagemath.org/prefs/sshkeys. Is the relevant authorized_keys (or whatever plays that role) updated immediately when one adds a key using the web interface, or is there a delay? Does anyone manage to connect with a public key they added that way? -- Marc -- 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.
[sage-devel] Re: New Trac Server
R. Andrew Ohana wrote: > Ok, this should be fixed now. It works, thanks! -- Marc -- 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.
[sage-devel] Re: Re: New Trac Server
R. Andrew Ohana a écrit : > 1) go into your preferences in trac; there is a new tab for adding ssh keys > - add an ssh key > 2) then do > > git remote add trac ssh://g...@trac.sagemath.org:/sage.git > git push trac local/branch/name:u/TracUsername/remote/branch/name If anyone likes to experiment with the new features, I just submitted a simple patch as a git branch. The ticket is up for review: http://trac.sagemath.org/ticket/14908 (My branch is based off 'working', is that the correct thing to do?) -- Marc -- 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.
[sage-devel] Re: WYSIWYG gui
Jason Grout wrote: > You might be interested in TeXMacs: > > http://www.texmacs.org/tmweb/home/welcome.en.html > > There once was a plugin for Sage that Mike Hansen wrote that let you do > Sage computations. I don't know if the plugin still works. Yes, it does, although it is not as powerful as some of the other plugins. -- Marc -- 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.
[sage-devel] Re: Notations for actions
Simon King wrote: > I think quite often one is in a situation that one has two different > sets (rings, groups, ...) S1, S2, such that there is only one action of > S1 on S2 from the left, and thus if one has s1 from S1 and s2 from S2, > then s1*s2 is not ambiguous. I guess it depends what exactly you mean by "only one action of S1 on S2": think of S1 = K[x][d/dx] and S2 = K[x]. Differential operators act on polynomials (e.g., d/dx(x) = 1), but there is also an embedding of K[x] into K[x][d/dx] under which d/dx*x = x*d/dx+1. The internal multiplication of K[x][d/dx] applied in this context is not a left action of K[x][d/dx] _on K[x]_, but I would definitely expect (d/dx)*x to coerce x to K[x][d/dx] and multiply there. -- Marc -- 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.
[sage-devel] Re: Notations for actions
Hi, Simon King wrote: >>> I think quite often one is in a situation that one has two different >>> sets (rings, groups, ...) S1, S2, such that there is only one action >>> of S1 on S2 from the left, and thus if one has s1 from S1 and s2 >>> from S2, then s1*s2 is not ambiguous. >> >> I guess it depends what exactly you mean by "only one action of S1 on >> S2": > > I wrote: "quite often one is in a situation that...". Sorry, apparently I misinterpreted your "thus...". >>think of S1 = K[x][d/dx] and S2 = K[x]. Differential operators act >> on polynomials (e.g., d/dx(x) = 1), but there is also an embedding of >> K[x] into K[x][d/dx] under which d/dx*x = x*d/dx+1. > > Do you see what you just did? You use "call notation" for one action, > i.e., d/dx(x), but use multiplicative notation for the other action, > i.w., d/dx*x. Yes, except that the second one is not an action of S1 on S2 from the left, but an action of S2 on S1 from the right, isn't it? That's all I wanted to point out: when trying to decide whether there is a single action that makes sense, one has to be careful to take into account actions from both sides and/or actions on larger sets to which the elements coerce. Apologies if I'm stating the obvious :-) >> The internal >> multiplication of K[x][d/dx] applied in this context is not a left >> action of K[x][d/dx] _on K[x]_, but I would definitely expect >> (d/dx)*x to coerce x to K[x][d/dx] and multiply there. > > No, I'd rather expect to coerce x into a *non-commutative* version of > the polynomial ring K[x][d/dx]. Yes, what I denoted K[x][d/dx] was the ring of differential operators with polynomial coefficients. Or do you have something else in mind? Best wishes, -- Marc -- 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.
[sage-devel] Re: Notations for actions
Simon King a écrit :
> Sage has both left and right actions. I would need to look up the
> details, but it is no problem to implement a right action of S2 on S1
> rather than a left action of S1 on S2. Since the mathematical property
> of "being an action" is not relevant in the implementation, you could
> actually still tell Sage that there is a left action of S1 on S2, even
> though mathematically it is the other way around.
Okay, so you were speaking of actions in the sense of the coercion
model, and I thought you meant actions in the mathematical sense. Sorry
again for the misunderstanding.
>>> No, I'd rather expect to coerce x into a *non-commutative* version
>>> of the polynomial ring K[x][d/dx].
>>
>> Yes, what I denoted K[x][d/dx] was the ring of differential operators
>> with polynomial coefficients. Or do you have something else in mind?
>
> Well, I thought you use the usual notation in Sage. And there, square
> brackets denote (commutative) polynomial rings.
(On a side note, ticket #13215 proposes to change that in some cases.)
> I would do
> sage: F. = FreeAlgebra(QQ)
> sage: D. = F.g_algebra({d*X:X*d+1})
> sage: dx*x
> x*dx + 1
>
> to create the ring in question. But this is because I am algebraist,
> and I guess "proper" differential operators are implemented somewhere
> else in Sage (dunno where/how/why), and do *not* live in this ring.
As far as I know, rings of differential operators are not yet
implemented in the Sage library, and currently the best way to define a
differential operator is the one you mention. (I think that's also more
or less what you told me in Orsay a few weeks ago.) The external package
ore_algebra[1] that Fredrik Johansson announced a few weeks ago[2]
provides "proper" differential operators, though.
[1]
http://www.risc.jku.at/research/combinat/software/ore_algebra/
[2]
https://groups.google.com/forum/#!topic/sage-devel/S7Wv67C6DvE
Best wishes,
--
Marc
--
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.
[sage-devel] Should RR coerce into RIF?
Hi, Sage happily coerces floating-point numbers (e.g., elements of RR) into intervals (e.g., elements of RIF), subject to some conditions on the precision of the source and destination rings. The relevant portion of the coercion graph looks like this: ( +---> RDF ) || Exact v real---> RLF ---> RR fields | |v +---> RIF The coercions RLF --> RIF and RLF --> RR --> RIF violate the requirement that coercions should form a commutative diagram. Right now, it is not too much of an issue in practice, because coercions X --> RIF are constructed based on the existing coercions X --> RR and direct coercions like RLF --> RIF always(?) end up being preferred to variants going through RR. But this is of course pretty fragile to changes in the coercion system. If a coercion path of the form X --> RR --> RIF is ever chosen for some exact ring X (whose elements are not exactly representable by elements of RR!), arithmetic operations between elements of X and intervals will yield mathematically incorrect results. Besides, things like sage: iv = 1 + 2^(-55) + 0. + RIF(1) sage: iv.lower(), iv.upper() (2.00, 2.00) can already make for subtle bugs in the current situation. The same issue exists for CC, CIF and friends. I see little value in having mixed operations between floating-point numbers and intervals work automatically, so I would be in favor of removing the coercions from floating-point rings to interval rings altogether. What do you think? -- Marc -- 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.
[sage-devel] Re: Should RR coerce into RIF?
Vincent Delecroix a écrit : > This is clearly what we want. If you have an operation involving > several real numbers with different precisions then you want that the > result has the least precision. And in analogous situations where each precision corresponds to a well- defined ring, the idea that the result should live in the ring with the lowest precision agrees with the definition in terms of homomorphisms. For instance, K[[x]] is the projective limit of K[[x]]/x^n, n \in N. -- Marc -- 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.
[sage-devel] Re: compilation error on debian
Hi, Jan Groenewald wrote: > It might be the é in your path, though \xc3 is something else: > In [1]: print u'\xc3' > Ã 0xC3 is the first byte of the UTF-8 encoding of 'é'. -- Marc -- 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.
[sage-devel] Re: Funny problem : implementing a "if and only if" result in Sage
Hi Nathann, Nathann Cohen wrote: > def TD(k,n) > 1) does there exist a OA(k,n,2) ? If so, return it > 2) does there exist a MOLS(n, k-2) ? If so, return it > 3) Otherwise, try to see if some TD-specific construction is available > for this set of parameters. > > def OA(k,n): > 1) does there exist a TD(k,n) ? If so, return it [...] > The problem is obvious. TD calls OA which call TD which call OA which > calls TD, which calls ... Why do you need (say) OA to call TD and not only the third step of TD? -- Marc -- 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.
[sage-devel] %edit does not work
Hello everyone, The very convenient magic function %edit has been broken more or less since sage-5.8. A trivial fix is available in the git branch trac:u/mmezzarobba/fix_percent_edit It would be nice if someone could review it before sage-6.0 is released! See http://trac.sagemath.org/ticket/15005 -- Marc -- 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.
[sage-devel] Polynomials over non-commutative rings
According to the docstring of PolynomialRing(), the base ring of a polynomial ring has to be commutative. However, it is clearly possible to create _univariate_ polynomial rings over non-commutative rings. Do you know of any code that relies on the assumption that the base ring is commutative? (There is certainly code that goes out of its way to work with polynomials over non-commutative rings.) -- Marc -- 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.
[sage-devel] Sage 6.x documentation
As noticed by Paul Zimmermann, http://www.sagemath.org/doc/ still points to the documentation of Sage 5.13. For regular manuals, it shouldn't make any difference until sage-6.1 is released, however the developer guide is out of date. -- Marc -- 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.
[sage-devel] Re: Polynomials over non-commutative rings
Vincent Delecroix wrote:
> Does polynomial over non-commutative ring make sense ? Because in that
> context axbx is not abx^2. Depending on what you call polynomial, they
> may or may not form a ring.
Just to clarify, I'm asking about polynomials over a non-commutative
rings but with an indeterminate that commutes with the coefficients. And
yes, this makes sense--you only have to be careful that p \mapsto p(a)
is not necessarily a ring homomorphism.
("Noncommutative polynomials", where the coefficients do not commute
with the indeterminate make sense, see for instance
sage.rings.polynomial.plural in Sage.)
--
Marc
--
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.
[sage-devel] Re: Re: Reviewing without dependencies
Jeroen Demeyer wrote: > OK, thanks, at least I understand the issue now. Somehow I couldn't > find this very simple explanation on the other long thread about > dependencies. I'm not sure which of the threads about dependencies you are referring to, but Volker gave the same example (and more) in the thread starting at . See in particular . Btw, I'm still not convinced by Volker's explanations, and the policy I was suggesting at the beginning of that thread still makes more sense to me. In summary, here's what I was suggesting: 1. The default diff/commits view of a ticket T linked from its trac page should be something like git log --graph commit ^trac/develop ^dep1 ^dep2 ... where commit is the contents of T's Commit field and dep1, dep2... are the contents of the Commit fields of the tickets D1, D2... listed in T's Dependencies field. Setting T to positive_review means that the set of commits described by the above "git log" command has been reviewed. 2. Any change to that set of commits (any change to T's Commit field, any change to one of the D's Commit fields that modifies its most recent common ancestor with T's Commit) automatically reverts T to needs_review. 3. It is allowed, though discouraged, to review T without reviewing D1, D2... If anyone can explain why "Volker's model" is safer than that, I'm very interested. In particular, Volker has given a number of examples of how mathematically incorrect code can end up in the mainline despite the reviewers having done their job. But the simple fact of reviewing several branches in parallel is enough to have kind of problems, even if there are no dependencies between the branches! And I'm still looking for an situation where the way of handling dependencies outlined above, specifically, would cause a problem. Thanks! -- Marc -- 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.
[sage-devel] Re: real literals and IEEE-754
Nils Bruin wrote: > Here is something I think is really a bug: > > sage: parent(RealField(200)(1) + 1e-20) > Real Field with 53 bits of precision Yes. And I'd say the behavior of RealField(200)(RR(1e-20))) is a bug as well (the same bug in fact). So I think there are two different issues here: 1. Real literals are elements of RR. IMO this is a bug that needs to be fixed. However, Jeroen disagreed in the ticket where this discussion originated[1], so I would like to hear other people's opinion. In my view, literals such as 1e-20 could be preparsed to Python floating- point decimals, rationals, elements of CLF... but certainly not elements of RR. [1] http://trac.sagemath.org/ticket/15542 2. Should real literals exist in the first place? I personally agree with Paul that they do more harm than good (they add a gratuitous difference between Sage and most languages, including Python, and they do not fit too well in Sage's floating-point arithmetic model). But having them in Sage is not an unreasonable design choice either. And of course getting rid of them entirely would break compatibility with earlier versions of Sage. -- Marc -- 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.
[sage-devel] Re: Re: real literals and IEEE-754
Robert Bradshaw wrote: > FWIW, the problem with putting literals in another field, like > RealLazyField, is what to do when doing arithmetic like 1.2 + 1.7 one > wants arithmetic with reals of unspecified parent to be "fast." The > literalness of floating point literals is supposed to just affect > constructors. What about putting them in some ad hoc parent in which all arithmetic operations (except perhaps unary -) would automatically convert their operands to 53-bits floating-point numbers--and return elements of RR? (I'm not saying I'm in favor of this solution: I would prefer real literals to disappear entirely, or to become decimal floating point numbers if really needs be.) -- Marc -- 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.
[sage-devel] Re: class LinearRecurrence
Ralf Stephan wrote: > Please make your comments on the design while it's baking. > > http://trac.sagemath.org/ticket/15714 Just some quick thoughts. To me most of the features you suggest look like a special case of what is already implemented in Manuel Kauers et al.'s ore_algebra package-- which uses Sage, but is not part of it or even submitted for inclusion yet. Note that even though ore_algebra is mostly about recurrences with polynomial coefficients, it also provides specific parents for operators with constant coefficients. (I don't remember if they implement any features specific to constant coefficients, though.) It would probably be a good idea to use and/or extend it as much as possible, and strive to be compatible with it in any case. That being said, in ore_algebra, the main objects are recurrence *operators* (among other kinds of linear operators), without initial values. I think there is also room in Sage for *recurrence sequences* that really behave like sequences. (In fact, I was planning to implement recurrence sequences with polynomial coefficients myself, based on ore_algebra.) Your interface goes in that direction, but it also contains things such as guess() and random_object() that do not belong there if the mathematical object you are trying to model is a sequence. IMO it is useful to distinguish between recurrence operators and *solutions* of recurrences (and possibly inhomogeneous recurrence equations in between). And in general, a given class should model only one kind of mathematical object! Best wishes, -- Marc -- 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.
[sage-devel] git-annex (was: Git reviewing help needed)
R. Andrew Ohana wrote: > The Sage repository should not contain binary files nor non-sage > specific source code, so naturally cloning the sage repository would > not include compressed tarballs of upstream code. Just an idea, but what you you think of embedding pointers to the tarballs via git-annex? -- Marc -- 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.
[sage-devel] Re: Re: class LinearRecurrence
Ralf Stephan wrote: > Looking forward to ore_algebra. If that package link were available > now I would start using it immediately, but the page was under > construction. The direct link that was posted to sage-devel a few month ago still seems valid: http://www.risc.jku.at/research/combinat/software/ore_algebra/ -- Marc -- 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.
[sage-devel] Re: git-annex (was: Git reviewing help needed)
Volker Braun wrote: > Also, git annex is written in Haskell... want to make that a Sage > dependency? No, I don't! I'm certainly not saying that git-annex should be required by Sage. I do believe it could be convenient for developers, and I thought the idea was worth mentioning in case someone else is interested, but I won't push for it. -- Marc -- 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.
[sage-devel] Re: Re: class LinearRecurrence
Ralf Stephan wrote: > I'm leaning towards the operator kind of recurrence because I > definitely don't think about it as a sequence with specific length. > But the core object really is the ogf, i.e. the polynomial fraction > which defines everything in the same sense special function > expressions are sufficient to define all D-finite sequences. So, the > object is a fraction, everything else an alternative interface, and > other values are only cached for programming convenience. > For this reason, without having looked at ore algebra, I would have > trouble understanding why the operator would be a core concept of all > holonomic function expressions or sequences. > Can you point at my error in thinking, please? I think I don't understand what you mean, sorry. But let me try to clarify what I was trying to say: * Despite the name of your class, it looks like you intend its instances to represent solutions of recurrences with constant coefficients, not recurrences themselves. * That's fine, but then the interface should be consistent with that choice. In particular, I find the name LinearRecurrence misleading, and I think methods like guess() and random_object() should go elsewhere (for instance, in the parent to which your sequences will belong). [#] * It would be useful to have both recurrence operators (as implemented in ore_algebra) and recurrence sequences. The design that makes the most sense to me is to implement recurrence sequences on top of recurrence operators, but I didn't really give it a lot of thought. In any case, we need to avoid code duplication and make the interfaces as consistent as possible. [#] More about the name: IMO we should reserve LinearRecurrenceSequence to for solutions of linear recurrences with arbitrary coefficients. What about CFiniteSequence (and CFiniteSequenceRing or CFiniteSequenceAlgebra for the parent) ? -- Marc -- 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.
[sage-devel] Re: class LinearRecurrence
One more remark: there is also a basic implementation of linear recurrences with constant coefficients in sage.crypto.lfsr... -- Marc -- 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.
[sage-devel] Re: Re: RFC: draft PEP for adding @ as a matrix multiplication operator to Python
William Stein wrote: >> IIRC Maple used to have something like *& to denote matrix >> multiplication, don't know if this is still the case, > > Hey, you're right-ish: > > http://kb.iu.edu/data/afbm.html > > They don't use * either, they use "." (like in Mathematica). They > deprecated *&. Actually Maple has no real matrix multiplication operator. They use "*" to denote "commutative multiplication", and "." for "non-commutative multiplication" (and "*~" for elementwise multiplication, "@" for composition, "&*" for user-defined multiplication). Both "*" and "." can be used as part of symbolic expressions (a*b-b*a is immediately simplified to 0, while a.b-b.a is not), and are interpreted as multiplication of more concrete objects where it makes sense. -- Marc -- 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: Re: How to define a new ring class ? [We need a class representing genuine real field]
Thierry wrote: > - rename RR as RFF (for "real floating field"), so that this > representation is not preferred than the others (especially RDF which > is faster and allows using more libraries, with the same 53 bits of > precision). The current name RR suggests it is the right default > choice. Yes, there seems to be a lot of confusion due to the set of 53-bit floating-point numbers being called "real field". See #11506 for a few examples. -- Marc -- 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: Should RR coerce into RIF?
Marco Streng wrote: > So the choices are: > > 1) explicit conversion RR --> RIF: allow / disallow > 2) explicit conversion RIF --> RR: allow / disallow > 3) automatic coercisions: disallow / (RR-->RIF) / (RIF-->RR) [...] > My vote is: > 1) allow > 2) allow > 3) from RIF to RR Mine is: 1) allow 2) allow for point intervals, require the use of explicit method calls (e.g., center()) for general intervals 3) disallow (but see below) Regarding 3), and in response to Thomas Coffee's arguments, I would be in favor of also having "non-rigorous intervals", living in a separate parent, with a coercion from RR. In fact, one also needs intervals with integer, rational or even symbolic endpoints from time to time. So unless I'm missing something, these "non-rigorous interval" could simply be the elements of Intervals(RR), where Intervals(C) would work for more or less arbitrary C. (And there could perhaps be a coercion from RIF to Intervals(RR), but certainly not in the other direction.) -- Marc -- 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: Should RR coerce into RIF?
Thierry wrote: > - How do you plan to convert > - from RealIntervalField(2) to RealField(100) ? Promote both endpoints. > - from RealIntervalField(100) to RealField(2) ? Round each endpoint in the appropriate direction. > - from RealField(100) to RealIntervalField(2) ? Round the input in both directions. > - from RealField(2) to RealIntervalField(100) ? Promote the input, return a point interval. (I.e.: The precision of a floating point number does not imply anything about its "accuracy", whatever that really means.) > - How do you mix both (do you plan to deal with possible compensations > between number of bits of precision of the field and the diameter of > the intervals) ? I don't think there is an issue here. > For example, in which case do you allow (silent) coercion, and what > should be the result of the (explicit) conversion: > > - RIF(-1,1) -> RR > - RealIntervalField(100)(1.1,1.2)) -> RealField(2) No coercion, no conversion. It is not much harder to write iv.lower(), iv.center(), Reals(2)(iv.center())... or whatever you really want. > - RealField(2)(pi) -> RIF [which diameter, which endpoints ?] Point interval. > - it is clear that RIF(pi) should be coerced to RR(pi) I beg to differ. > - i agree with coercing from x in RealIntervalField(a) to RealField(b) > when the endpoints of x are the same in RealField(b) As far as I understand, coercion maps are supposed to be total. > - i have no problem for explicit conversion from RIF(-1,1) to RR, but > it should be well specified in the doc, since there is no canonical > way. ...and IMHO in the code too, since there is also no single reasonable choice, and hence not be a conversion. > - i am not sure wether RIF(-1,1) should coerce to RR Definitely not. > BUT, i find the second example of tcoffee quite convincing (i am also > doing some RIF stuff to understand the loss of precision along a > computation), so perhaps could there be an easy way to let the user > tune such a convenient coercion easily at her own risks, and a way to > learn about this. Or perhaps could there be a special parent for this > kind of experiments. Besides the fact that it is cleaner than a "special mode" in which RIF would support coercion from RR, I think a hint that you want a separate parent is that the requirements in this kind of scenarios are not those of interval arithmetic. For example, if I understand correctly, you do not need the (otherwise fundamental!) property that the endpoints are rounded in the right direction after each arithmetic operation. -- Marc -- 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: A "# bug" tag for doctests
Nathann Cohen wrote: > The following code does not return what it should:: > > sage: Z3 = IntegerModRing(3) > sage: C = cartesian_product([Z3,Z3]) > sage: C([2,2])^2 # bug > (1, 1) You can already write something like "# bug - not tested"... > And of course we could get the list of them with a "sage -t > -optional=bug", as well as report them where the users can see them > --> the doc. ...though you'd have to use grep for that part. -- Marc -- 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: Re: charpoly of sparse matrix
Paul Mercat wrote: > OK, thank you, I see. > It's an efficient method to compute a approximation of the spectral > radius. It's good but I still want to have the exact value. You can use the same idea to compute the minimal polynomial of your matrix (with high probability). This is the starting point of Wiedemann's algorithm for the solution of black-box linear systems, see the first section of http://en.wikipedia.org/wiki/Block_Wiedemann_algorithm And I think Linbox indeed implements this algorithm as well as various more sophisticated variants. -- Marc -- 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: cached_function: cache a(n) only when n is *not* a prime power
Nathann Cohen wrote: > I have a function named "a" which takes an integer as input. > Unfortunately when 'n' is a prime power, a(n) returns a very large > matrix (but quick to compute). Thus, I would love to cache only the > answers of a(n) when n is NOT a prime power, which are smaller and > take more time to compute. [...] > 1) Is there a way to obtain this behaviour with @cached_function ? Perhaps not the most elegant solution ;-), but I guess you could use an auxiliary cached function that throws its result instead of returning it in cases where you don't want to cache it... -- Marc -- 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: Subclassing an Element class
Eric Gourgoulhon wrote: > - Technically, it would be desirable to create a subclass, > ConstScalarField say, of the Element class of C^oo(U) (ScalarField) to > implement constant fields, in order to take advantage of their > specific properities [...] > - Mathematically, the set of constant scalar fields is a subalgebra of > C^oo(U), so it would be natural to implement it as such. Is there any > way to do this in the Parent/Element scheme ? [...] > In particular, CU(0).parent() would no longer be CU but CCU, which may > result in some undesired effects... How about defining two parents (CU and CCU, with a coercion CCU --> CU and a partial conversion CU --> CCU), and two element classes (SF and a subclass CSF), and having CU(0) create an instance of CSF, but set the instance's parent to CU? -- Marc -- 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: Re: hash for algebraic field
Nils Bruin wrote: > The consistent solution, and one that is mathematically defendable, > would be to have a != GF(p)(a) for integers a (i.e., always force > explicit coercion for equality to hold). So that is making "==" strict > enough to allow hash to meet its requirements, but this turns out to > be too problematic for new users and for casual/interactive use [for > more serious programming this is fine -- it's what Magma does and > users there can live with it, after an adjustment period] This has probably been discussed about 1000 times before, but why not introduce a separate equals() function to denote "mathematical" equality, and keep = for "syntactic" equality(*)? I for one find the behavior of = both pretty surprising and very inconvenient since my first contact with sage. Besides, supporting both flavors of equality is useful in any case. (*) a = b if a naive deep comparison of a and b, possibly after normalization, finds that they are identical -- Marc -- 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: Re: Re: hash for algebraic field
Robert Bradshaw wrote:
> So you would prefer
>
> sage: 4/2 == 2
> False
> sage: 4/2 + 0/1 == 2 + 0/1
> True
Definitely.
> sage: R. == ZZ[]
> sage: (x-1) * (x+1) - x^2 + 1 == 0
> False
I certainly agree that being able to use "== 0" here is convenient.
But having to write, say, eq(pol, 0) instead does not seem too high a
price for consistency with the assumptions Python makes on equality. (Do
not misunderstand me: if Sage had its own language, I would prefer to
use == for the richest form of equality, and some other notation for the
version consistent with hashing.)
And IMHO your examples are not worse than
sage: x = SR.var('x')
sage: bool(arctan(1+abs(x)) == pi/2 - arctan(1/(1+abs(x
False
sage: R. = QQ[]
sage: R(0) == GF(2)(0)
False
sage: R(0) == 0 and 0 == GF(2)(0)
True
sage: {t.parent() for t in {R(42), 42}}
{Integer Ring}
sage: sage: {t.parent() for t in {42, R(42)}}
{Univariate Polynomial Ring in y over Rational Field}
sage: {42, QQbar(42)}
{42, 42}
sage: {42, SR(42)}
{42}
sage: {2^100, SR(2^100)}
{1267650600228229401496703205376, 1267650600228229401496703205376}
sage: eq = SR(GF(2)(0)) == SR(2); eq
0 == 2
sage: bool(eq)
True
> Note also that if GF(p)(1) != 1 !=
> int(1) and is not an error then trivial looking code like
>
> def order(a, p):
> """ return x such that a^x == p, naively """
> if a == 0:
> return infinity
> else:
> x = GF(p)(a)
> count = 1
> while x != 1:
> x *= a
> count += 1
> return count
>
> has a really bad bug in it.
Not that bad if x != 1 throws an exception. Besides, Java programmers
have had a similar problem forever and can apparently live with it...
--
Marc
--
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: Re: Re: hash for algebraic field
Volker Braun wrote:
> Comparisons in Java are probably one of the #1 traps for the unwary
> (and inconsistent between primitives and objects). But at least for
> objects, Java "==" is just the Python "is". And ".equals()" is Python
> "==". So there you have your two comparisons already. Really, you are
> asking for a third.
Yes. Or, to be precise, Sage is asking for a third ("mathematical"
equality without implications on hash values), and I'm arguing that it
should be separate from the first two.
--
Marc
--
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: hash for algebraic field
Nils Bruin wrote: > It isn't for explicit equality checks, but the wide use of > @cachedmethod means that many objects that are passed as arguments (so > that's almost all sage objects at some point) can end up as (part of) > dictionary keys, without the user explicitly asking for it. This > requires hash to do a reasonable job on very hard to predict > collections of sage objects and requires "==" to not cause an > exception Good point, I didn't think of that. Though of course it also adds another "nice" example to my list :-/ sage: @cached_function : def my_parent(o): : return o.parent() : sage: my_parent(2) Integer Ring sage: my_parent(SR(2)) Integer Ring -- Marc -- 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: hash for algebraic field
Robert Bradshaw wrote:
>> sage: x = SR.var('x')
>> sage: bool(arctan(1+abs(x)) == pi/2 - arctan(1/(1+abs(x
>> False
>
> Better returning True when the CAS isn't strong enough to prove
> equality (which may well be most of the time).
Sure. But why not have
sage: bool(sin(x)^2+cos(x)^2==1)
True
return False as well, and let the user test that
(rhs-lhs).simplify_full() == 0
or whatever else they really have in mind?
(I don't even know if there is a method to test that two symbolic
expressions are syntactically identical!)
I'm only trying to say that
1. the behavior of == is already full of subtleties (and bugs),
so I don't think arguments such as "4/2==2 is surprising for
new users" are very strong;
2. I'd vastly prefer the first version of equality people will try
to be something as simple as possible, whose limitations are
easy to discover and understand.
Yes, it is great to have a rich equality predicate that automatically
does the right thing in many cases. The only problem is, I know I cannot
trust its output, and I am convinced that I never will because the
issues discussed in this thread are basically unfixable. As I (sort of)
understand what is going on, I can live with it and only use == when I
know beforehand what coercions may happen. But trying to put myself in
the shoes of a new user discovering the pitfalls of the existing ==, I
think I would lose all confidence in Sage (which may not be such a bad
thing, after all).
>> sage: {t.parent() for t in {R(42), 42}}
>> {Integer Ring}
>> sage: {t.parent() for t in {42, R(42)}}
>> {Univariate Polynomial Ring in y over Rational Field}
>
> Totally, just like Python's
>
> {type(t) for t in {0, 0.0}} == {float}
Fair enough, Python is even more broken than I thought! ;-/
> Can you think of any reason you'd want to do this?
No, that was just another case where the consequences of how == works
may not be that easy to understand.
But here is a similar example right from the Sage library (adapted from
http://wiki.sagemath.org/EqualityCoercion):
sage: FiniteEnumeratedSet(GF(3))
{0, 1, 2}
sage: add(FiniteEnumeratedSet([0,1,2]))
0
>> sage: {42, QQbar(42)}
>> {42, 42}
>> sage: {42, SR(42)}
>> {42}
>> sage: {2^100, SR(2^100)}
>> {1267650600228229401496703205376, 1267650600228229401496703205376}
>
> Hash is not as good as it could/should be for large symbolic integers.
> And for AA/QQbar.
And do you honestly think this will ever be fixed for all sage objects?
Or that unexpected inconsistencies such as the above are better than
"4/2!=2"? (After all, 4/2 and 2 *are not* equal. Otherwise
2.is_invertible() would be True.)
>> sage: eq = SR(GF(2)(0)) == SR(2); eq
>> 0 == 2
>> sage: bool(eq)
>> True
>
> Yeah, SR is weird. Especially with elements that don't embed into CC.
Actually this example is the only one that is not a bug in my eyes--just
yet another pitfall of ==.
Anyway, thank you very much for your comments. I now understand these
design choices a bit better, though I'm still very far from convinced.
--
Marc
--
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: speed regression testing
William A Stein wrote: > What's the situation with speed regression testing in Sage? A couple > of years ago I think people wrote a regression testing framework > (maybe David Roe or Robert Bradshaw?) FWIW I started a little bit of work aiming to make the existing benchmarking code more useful a while ago, but I never went very far... http://trac.sagemath.org/ticket/16510 -- Marc -- 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: SPKGs that installs Python code
Bart S wrote: > Most SPKGs seem to install binaries that are then called from existing > Sage code. Are there also examples of SPKGs that installs Python code > that integrates with Sage (like adding a new module)? The ore_algebra spkg adds a Python module ore_algebra (NOT sage.ore_algebra, though, if that's what you have in mind) that uses sage--and could be used by sage, though it is not afaik. -- Marc -- 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: Where to put a tutorial to draw polytopes in Tikz?
Volker Braun wrote: > I would put it in src/doc/en/tutorial as REsT. For example, there is > already src/doc/en/tutorial/sagetex.rst Wouldn't thematic_tutorials/ be a better location? I thought tutorial/ was for the main tutorial that everyone trying to use sage should skim through... -- Marc -- 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: sign() and comparison in AA
Jonas Jermann wrote: > What would you suggest I do to get a fast exact sign/comparison? Just a wild guess, but you may want to see if the patch at http://trac.sagemath.org/ticket/15600 helps. -- Marc -- 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: Re: How to check that something is a real number?
Thierry wrote: > My favourite is "in RealField(2)" just in case you fall into something > with smaller precision. But if you prefer to work with coercion, then > you should first remove SR(2.3) and 2*pi from your first list, and you > could do something like: > > is_real = lambda self: > get_coercion_model().common_parent(self.parent(),RealField(2)) is > RealField(2) In this case, I think that RealField(mpfr_prec_min()).has_coerce_map_from(parent(foo)) should be enough. (And I think that's the most reasonable thing to do: in doubt, prefer coercion over conversion!) -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: AlgebraicReal.minpoly slow
Clemens Heuberger wrote: > x = polygen(QQ) > equation = -96000*x^7 + 41600*x^6 - 6640*x^5 + 560*x^4 > - 28*x^3 + 8400*x^2 - 140*x + 1 roots = equation.roots(QQbar) > a_root = roots[-1][0] > abs_root = abs(a_root) [...] > Is this expected behaviour? Well, QQbar has a number of well-known but not yet fixed efficiency problems... > I am intersted in the smallest root(s) in > absolute value only, any suggestions for achieving that in less time? You could perhaps compute a polynomial whose roots include the z·conj(z) for all roots z of equation (e.g., with a resultant), factor that polynomial, and sort its root numerically while increasing the precision until you can tell which of the factors correspond to dominant roots. Or something like that :-/ -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: doctesting external file: import troubles
Daniel Krenn wrote: > How to deal with this import problem, so that it works in the jupyter > notebook and with doctesting? Perhaps try something like SAGE_PATH=$PWD sage -t something.py ? There may be a better way, I don't know. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Cross-type comparisons
Hi, Does Element.__richcmp__() (via CoercionModel_cache_maps.richcmp()) really need to fall back on comparing by type/id when no common parent is found? Since comparison operators are part of the coercion framework, it would seem more sensible to raise an error. Moreover, having an essentially arbitrary return value is dangerous, because the user can easily mistake it for a mathematical result. My immediate reason for asking this question is an example of this kind. I'm trying to finally remove the coercions from floating-point parents to interval parents (as discussed here long ago). But doing so would cause comparisons such as RIF(-1,1) < RR(2) to return nonsensical results, while they currently give the correct answer at least when the floating-point operand is a constant (as opposed to the result of a floating-point computation). (Now, I can perhaps think of ad-hoc fixes that might be enough in this particular case, but I believe the issue is more general.) In contrast, the only reason I can see for this code path to exist in the first place is that--if I understand right--Python calls a.__richcmp__(), not a.__cmp__(), when cmp() is applied to objects a and b whose common superclass does not implement __cmp__. Therefore, one can end up in Element.__richcmp__() while comparing an Element to a non-Element via cmp(). And unfortunately, there does not seem to be any simple way to distinguish between this situation and calls to __richcmp__() coming from comparison operators. Is this correct? Did I miss another reason? If that's really the main reason, I'd argue that having cmp() fail in some cases is not as bad as having comparison operators return nonsense on Elements. (Besides, all cases where this could be a problem will have to be fixed anyway to port Sage to Python3, won't they?) What do you think? Note that as a middle ground, we could raise an error when coercion fails with both operands being Elements, while still returning a result at all costs when comparing an Element with a non-Element. However, this wouldn't help in cases like RIF(-1, 1) < float(2). It would also be safe--though not ideal--to keep returning False for comparisons using ==, and sort-of-okay to return True when comparing with !=. And, for example, the following patch, which also whitelists comparisons with strings (because there are typically safe and seem to be in wide use in combinat/) only leaves us with about 40 test failures (many of which trivial). @@ -1870,8 +1871,6 @@ cdef class CoercionModel_cache_maps(CoercionModel): (x)._parent.get_flag(Parent_richcmp_element_without_coercion)) return PyObject_RichCompare(x, y, op) -# Comparing with coercion didn't work, try something else. - # Try y.__richcmp__(x, revop) where revop is the reversed # operation (<= becomes >=). # This only makes sense when y is not a Sage Element, otherwise @@ -1883,18 +1882,23 @@ cdef class CoercionModel_cache_maps(CoercionModel): if res is not NotImplemented: return res -# Final attempt: compare by id() -if (x) >= (y): -# It cannot happen that x is y, since they don't -# have the same parent. -return rich_to_bool(op, 1) +if op == Py_EQ: +return False +elif op == Py_NE: +return True +elif type(y) is str: +return rich_to_bool(op, cmp(type(x), type(y))) else: -return rich_to_bool(op, -1) +raise bin_op_exception(operator_object(op), x, y) def _coercion_error(self, x, x_map, x_elt, y, y_map, y_elt): """ @@ -1924,3 +1928,18 @@ Original elements %r (parent %s) and %r (parent %s) and maps %s %r""" % (x_elt, y_elt, parent_c(x_elt), parent_c(y_elt), x, parent_c(x), y, parent_c(y), type(x_map), x_map, type(y_map), y_map)) + +cdef object operator_object(int op): +if op == Py_LT: +return operator.lt +elif op == Py_LE: +return operator.le +elif op == Py_EQ: +return operator.eq +elif op == Py_NE: +return operator.ne +elif op == Py_GE: +return operator.ge +elif op == Py_GT: +return operator.gt (By the way, does operator_object already exist somewhere?) Thanks for your input, -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Cross-type comparisons
Frédéric Chapoton wrote: > richcmp, when not knowing what to do, should most probably return > NotImplemented In the case of Element.__richcmp__: not when both operands are Elements, IMO, but perhaps indeed when the other one is a non-Element. > I do not think we should whitelist comparison with strings. That was just an example of a temporary kludge that could make things simpler :-) > What do the mostly-trivial 40 test failures look like ? I didn't keep the list, sorry. Quite a few duplicates from all the translations of the part of the tutorial that explains comparisons with coercions. Probably a lot of mixed-type lists to be sorted and the like. And a few that might actually have been bugs, but I didn't look closely. -- Marc Mezzarobba -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Cross-type comparisons
Travis Scrimshaw wrote: > We need to be very careful about defining "not knowing". I (stongly) > believe when the objects/types are incomparable (say the rings ZZ and > QQ), then == should return False and != should return True. Sorry, I don't understand your example: I think everyone agrees that ZZ == QQ should be False, but many people think that ZZ(1) == QQ(1) should be True (though I personally disagree), and my post only was about Elements. > Subsequently, when there is no coercion between the parents, they > should not raise an error. Regarding ==, I believe it is a matter of convenience and consistency. Raising an error makes it easier to catch bugs, while returning False when there is no coercion allows things like [a for a in [1, "banana"] if a == 1]. Regarding !=, I am less convinced. Returning True would imply that the objects are known to be different (as opposed to: not known to be equal, in the case of ==), while the coercion may not be implemented but otherwise make perfect sense. And in any case, I don't see what else than raising an error we could do in the case of <, <=, >, >=. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Cross-type comparisons
Frédéric Chapoton wrote: > There is currently an effort being made (by me and a few referees) to > get rid of cmp() in all pyx files. Is there already a replacement for cmp() in Sage (i.e., something that allows one to sort arbitrary objects--say, for printing them--and calls _cmp_() in the case of Elements)? If not, is there a plan to add one? Thanks, -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Cross-type comparisons
Thierry wrote:
> Note that there are not only "mathemathical" orderings, but also
> "algorithmic" ones. It is useful (and i bet assumed in various Sage
> algorithms) to be able to totally order any pair of Python objects,
> e.g. when you want to traverse a graph, or even identify edges:
>
> sage: Graph({2:['a']}).edges(labels=False)
> [(2, 'a')]
> sage: Graph({'a':[2]}).edges(labels=False)
> [(2, 'a')]
> sage: 2 < 'a'
> True
Yes, but that's essentially the difference between comparison and cmp()
(at least in the current best practice as I understand it).
And indeed, when the order is not going to be presented to the user, it
is probably better to compare id()s in this case.
--
Marc
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Cross-type comparisons
Nils Bruin wrote: > Yes, there is one in python in general. With > > sort(, key=str) > > you'll be able to sort lists of all kinds of stuff. Well, sort(key=str) and sort(key=id) certainly help in many cases, but they clearly don't suffice in general. Neither is able to use an order defined by the common class when it exists, and key=str may be very costly. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Cross-type comparisons
Travis Scrimshaw wrote: >> Sorry, I don't understand your example: I think everyone agrees that >> ZZ == QQ should be False, but many people think that ZZ(1) == QQ(1) >> should be True (though I personally disagree), and my post only was >> about Elements. > > One potential side effect of what you're proposing is that ZZ == QQ > should raise an error. No, my suggestion is strictly about Elements. (And if we'll have lots of deeper changes to make if we want objects that are both Parents and Elements!) >> > Subsequently, when there is no coercion between the parents, they >> > should not raise an error. >> >> Regarding ==, I believe it is a matter of convenience and >> consistency. Raising an error makes it easier to catch bugs, while >> returning False when there is no coercion allows things like [a for a >> in [1, "banana"] if a == 1]. > > It also makes it *significantly* harder to work with heterogeneous > data and really doesn't do too much to catch bugs. You end up with > more complicated code that has to often consider more cases. Suppose > ZZ(1) == QQ(1) raises an error. Then you have to manually do coercions > and make extra sure about your data types in a weakly typed language, > which is really hard from my experience. >From my POV, the two most consistent options would be: - either comparison operators that don't perform any coercions (except perhaps in an ad-hoc way between closely cooperating parents), respect Python semantics (wrt hash() & co), and return False for Elements that don't have the same parent, - or operators that are part of the coercion framework, and raise an error when they don't find a common parent. In the case of equality, I think it is pretty clear that both variants are useful and should exist in some form. The main question is which of the two should correspond to the Python comparison operators. Compatibility with Python collections and other non-Sage objects is a strong argument in favor of the former. Ease of use in interactive usage and backward compatibility are strong arguments in favor of the latter. That being said, I think it would be acceptable to special-case equality even if it does use coercion and make it return False when coercion fails. > If the coercion is not implemented, then I would say that is a bug > that would need to be fixed. In easy cases, yes, but in some cases it may very well correspond to an undecidable problem... > However, that is a good point about != > being not known to be == vs truly distinct. Although I would argue > that not known to be equal is an equivalent problem to knowing to be > distinct, and so the desire for an unknown result is good. Although it > should not be an error. Wait. To make sure we understand each other: I'm not saying that the error is here to indicate an unknown result. Since it is not possible to implement a reasonable three-valued logic for programming in Python, I think we should stick as much as possible to the convention that "True means true, False means false or unknown" (that already is the dominant one in Sage as far as I can tell), and that's why I'm saying that having == return False when it should actually fail is more acceptable that having != return True in the same situation. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Re: Cross-type comparisons
Thierry wrote: > However, mixing the internal order of a common class when it exists > together with id() would loose the transitivity property, so i guess > those two kind of tests should remain separate. I'm not sure I follow you: doesn't what cmp() does (if I understand right: use the internal order when possible, otherwise sort by type and refine by id) do the job? But then, of course, this behavior cannot be implemented as a key function, only as a comparison function... -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Re: Cross-type comparisons
Nils Bruin wrote: > There's a transform that allows you to implement any comparison via a > key: [...] > (of course this all doesn't solve the fundamental difficulty that > there isn't an ordering that is both total and > intuitive/mathematically meaningful) Indeed--and regarding this, I'd be interested in your opinion about https://trac.sagemath.org/ticket/22029#comment:5 -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Cross-type comparisons
Jeroen Demeyer wrote: >> Does Element.__richcmp__() (via CoercionModel_cache_maps.richcmp()) >> really need to fall back on comparing by type/id when no common >> parent is found? > > No. As far as I know, It does so for historical reasons only. I am in > favour of making elements without a common parent uncomparable. Okay, here is an attempt at doing so: https://trac.sagemath.org/ticket/22029 I had to touch corners of Sage I'm far for comfortable with; if people more familiar with them can have a look at the changes and perhaps help with cleaner fixes, that would be more than welcome! src/doc/de/tutorial/programming.rst | 12 -- src/doc/en/reference/graphs/index.rst | 1 + src/doc/en/tutorial/programming.rst | 10 - src/doc/en/tutorial/tour_coercion.rst | 2 - src/doc/fr/tutorial/programming.rst | 10 - src/doc/fr/tutorial/tour_coercion.rst | 2 - src/doc/ja/tutorial/programming.rst | 11 - src/doc/ja/tutorial/tour_coercion.rst | 2 - src/doc/pt/tutorial/programming.rst | 10 - src/doc/pt/tutorial/tour_coercion.rst | 2 - src/doc/ru/tutorial/programming.rst | 9 - src/module_list.py | 3 ++ src/sage/algebras/group_algebra.py | 4 +- src/sage/categories/finite_posets.py| 4 +- src/sage/categories/sets_cat.py | 2 +- src/sage/combinat/crystals/alcove_path.py | 2 +- src/sage/combinat/crystals/fast_crystals.py | 6 ++- src/sage/combinat/designs/incidence_structures.py | 8 +++- src/sage/combinat/finite_state_machine.py | 19 +++-- src/sage/combinat/misc.py | 2 +- src/sage/combinat/posets/posets.py | 9 +++-- src/sage/combinat/rigged_configurations/bij_type_A2_even.py | 13 +++--- src/sage/combinat/sf/sfa.py | 2 +- src/sage/combinat/species/product_species.py| 2 +- src/sage/combinat/species/recursive_species.py | 2 +- src/sage/combinat/species/series_order.py | 49 +++ src/sage/combinat/species/species.py| 7 ++-- src/sage/combinat/subset.py | 3 +- src/sage/combinat/words/abstract_word.py| 5 ++- src/sage/combinat/words/finite_word.py | 6 +-- src/sage/combinat/words/morphism.py | 8 ++-- src/sage/combinat/words/words.py| 16 ++-- src/sage/geometry/cone.py | 4 -- src/sage/geometry/fan.py| 2 - src/sage/geometry/polyhedron/base.py| 7 src/sage/geometry/toric_lattice.py | 2 - src/sage/geometry/triangulation/element.py | 2 - src/sage/graphs/base/c_graph.pyx| 30 -- src/sage/graphs/base/label_cmp.pxd | 4 ++ src/sage/graphs/base/label_cmp.pyx | 84 +++ src/sage/graphs/base/sparse_graph.pyx | 21 ++ src/sage/graphs/generic_graph.py| 46 + src/sage/graphs/graph_plot.py | 29 +- src/sage/graphs/schnyder.py | 6 +-- src/sage/groups/affine_gps/group_element.py | 2 - src/sage/homology/chain_complex.py | 17 src/sage/homology/simplicial_complex.py | 25 ++-- src/sage/interfaces/ecm.py | 2 +- src/sage/libs/ntl/ntl_mat_ZZ.pyx| 4 -- src/sage/misc/misc.py | 12 +++--- src/sage/modular/abvar/abvar.py | 2 +- src/sage/modular/abvar/finite_subgroup.py | 4 -- src/sage/modular/abvar/torsion_subgroup.py | 2 - src/sage/modular/hecke/ambient_module.py| 9 - src/sage/modules/multi_filtered_vector_space.py | 6 ++- src/sage/modules/quotient_module.py | 2 - src/sage/plot/graphics.py | 4 +- src/sage/plot/plot3d/base.pyx | 4 +- src/sage/plot/plot3d/platonic.py| 2 +- src/sage/quivers/representation.py | 4 +- src/sage/rings/number_field/number_field.py | 2 +- src/sage/rings/
[sage-devel] Re: Cross-type comparisons
Travis Scrimshaw wrote:
> We need to be very careful about defining "not knowing". I (stongly)
> believe when the objects/types are incomparable (say the rings ZZ and
> QQ), then == should return False and != should return True.
> Subsequently, when there is no coercion between the parents, they
> should not raise an error.
Does anyone else have comments on this issue? Specifically, what should
x != y do in your opinion when
- x is a Sage Element,
- y is
(i) another Element, or
(ii) a non-Element that does not implement rich comparison
with Elements,
- and the coercion framework finds no common parent for x and y?
The main options are to:
(a) return True,
(b) raise a TypeError.
Note that this is not equivalent to asking what == should do in a
similar situation.
I guess the main argument in favor of (a) is that it makes it possible
to say things like
if x != "foo":
x.frobnicate()
more or less whatever x is. Forbidding it may lead to problems in
existing external code, and the alternative version
if not (x == "foo"):
x.frobnicate()
(which would still work) is uglier and counter-intuitive.
The main argument I see for (b) is consistency with how coercion works
in general. When y is a string as above, or even when y is an Element
that has nothing to do with x, choosing (b) over (a) might help catch
some bugs, but I don't think there is much that can go wrong with (a).
The situation is more complicated when there is a common parent where
the comparison could be performed but the coercion framework is not
powerful enough to find it, like
sage: K. = QQ[sqrt(2)]
sage: sqrt2 != QQbar(sqrt(2)) # mathematically wrong result!
True
or when the user (being used to Sage trying to make sense of comparisons
between elements of different parents) could mistake the output for more
than what it is, e.g.,
sage: QQ['x'].one() != QQ['y'].one()
True
sage: QQ['x'].one() != GF(2).one() # False with ZZ['x']
True
sage: RLF(pi) != pi
True
sage: RIF(-1, 1) != RBF(0) # are [-1,1] and {0} disjoint?
True
Incidentally, forcing people to change x != y to not(x == y) in some
cases may not be such a bad thing. Indeed, the two are not always
equivalent (the archetypal examples being intervals and domains where
equality is mathematically well-defined but undecidable), and situations
where option (b) would make x != y fail often are cases where the
programmer actually means not(x == y).
--
Marc
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Re: Cross-type comparisons
Jeroen Demeyer wrote: > Don't forget the option > > (c) return NotImplemented > > I would say: > > Case (i): (b) > Case (ii): (c) Yes, I kept that out because my current patches don't change that part of the logic, but I think I agree. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Cross-type comparisons
Marc Mezzarobba wrote: > I had to touch corners of Sage I'm far for comfortable with; if people > more familiar with them can have a look at the changes and perhaps > help with cleaner fixes, that would be more than welcome! In particular, Nathann sent me a private e-mail to complain that my patches would likely slow down important use cases of the graph code. Does anyone have benchmark problems handy that I could use to check? Thanks, -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Re: Cross-type comparisons
Marc Mezzarobba wrote: > Jeroen Demeyer wrote: >> Don't forget the option >> >> (c) return NotImplemented >> >> I would say: >> >> Case (i): (b) >> Case (ii): (c) > > Yes, I kept that out because my current patches don't change that part > of the logic, but I think I agree. What about making a finer distinction, like - (b), i.e. fail, when y is a SageObject or can be converted using py_scalar_to_element(), - (c), i.e. return NotImplemented, otherwise? -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Re: Re: Cross-type comparisons
Jeroen Demeyer wrote: > I would prefer to treat these as any other non-Element. I see no > reason for the special case. It would catch cases like QQ(1) != ZZ or (going back to the case of general rich comparison) float(1) < RIF(pi) where Python2 would compare by type otherwise. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Cross-type comparisons
Thank you for you comments.
Kwankyu Lee wrote:
> (1) "x != y" should behave always and exactly as "not (x == y)"
This is difficult to achieve.
For example, in interval arithmetic, one usually expects a == b to
return True iff a and b are equal point intervals, and a != b to return
True iff a and b are disjoint intervals. Also, for lots of objects
coming up in computer algebra (e.g., symbolic expressions in one
variable), the equality test is either undecidable or at least not known
to be decidable.
In all these cases, there are at least three possible outcomes for the
comparison a == b:
- a and b can be determined to be equal,
- a and b can be determined to be different,
- a and b are neither known to be equal nor known to be different
(and perhaps, sometimes, variants like "a and b are known to be
neither equal nor different": e.g., the IEEE standard for floating-
point arithmetic says that NaN == NaN and NaN != NaN should both
return False, and it is not clear that this can be considered a case
where the "actual" result is unknown, as with interval arithmetic).
Then, the questions "are a and b known to be equal" and "are a and b
known to be different" are not the same. For example, if you are trying
to make sure that a matrix is nonsingular, you will usually want to test
that its determinant is known to be nonzero. If, however, you are trying
to decide whether a term can be dropped from the representation of a
polynomial, you'll usually want to test if it is known to be zero.
A partial solution to these problems is to allow comparisons to return
"Unknown" instead of just "True" or "False". This is in fact possible;
however (as discussed at length on sage-devel in the past), Python will
need to convert the "Unknown" result to a boolean as soon as it is used
as part of a conditional expression, so that we essentially are back to
the previous problem.
(I guess one could implement a more explicit, if essentially equivalent,
way of handling that, e.g. have comparisons themselves return Unknown,
conversions from Unknown objects to boolean raise an exception, and
introduce "modality" operators for the various possible conversions from
{True,False,Unknown} to {True,False}. But that's not how things are done
in Sage for now.)
> (2) When parents of x and y are different after coercion, "x != y" ("x
> == y") returns True (False) for both (i) and (ii)
Why only "after coercion"? I would understand that x != y return False
as soon as x and y have different parents--that would actually be the
best convention from my POV, but many people disagree, and that would be
a major break of compatibility. But I don't like the idea that a
comparison that makes sense mathematically returns True or False
depending whether the coercion system finds a common parent or not.
Besides, it is not hard to find cases where the user could *expect* the
system to make sense of the comparison, even though x and y actually
have good reasons not to have a common parent.
In other words: the choice has been made, long ago, to have ==/!= in
Sage stand for "semantic" comparison of mathematical objects rather than
"syntactic" comparison of data structures. I don't think it was the
right choice, but as long as we stick to it, it seems to me that
comparisons that don't have a well-defined mathematical result should
fail whenever practical, and return False (under the above asymmetric
interpretation) if they really need to return a boolean result.
> (3) "x != y" and "x == y" never raise an exception.
Why? We are not talking about raising exceptions all the time, only in
cases where it is likely that there is a bug...
--
Marc
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Cross-type comparisons
Simon King wrote: > I didn't closely follow the discussion here. Have there been > suggestions how Sage should in future distinguish the two meanings of > comparison (maths vs programming)? Not in this thread. However, if I understood right, several people who worked on getting rid of cmp() came to the conclusion that having a total order on all objects like cmp() used to (sort of!) promise wasn't that useful. Yet, it would be nice to standardize a few additional comparison functions with well-specified semantics. (That's not what I'm trying to do at the moment, however.) > It would obviously be rather awkward to have to do "A.is_equal(B)" for > a mathematical equality test. It would nevertheless be the best option, IMO, if we were starting from scratch. But that's not the case. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Cross-type comparisons
Kwankyu Lee wrote: > Do we have such cases in Python proper? I mean a case that disobeys > (1). I can't think of any example for base types(*). But this is explicitly allowed by PEP207: |3 The == and != operators are not assumed to be each other's | complement (e.g. IEEE 754 floating point numbers do not satisfy | this). It is up to the type to implement this if desired. and I guess there are a number of other libraries that use this option. (*) What I said about NaNs earlier in the thread was incorrect: I think the rule is actually that NaN < a, NaN > a, NaN == a are all false for all a (even when a is [the same] NaN), but NaN != a is true for all a. And that's, of course, assuming a particular mapping of the language's comparison operators to IEEE754 comparison predicates, which is the job of the language specification. And hence I don't understand what the remark about IEEE754 in the above quotation refers to. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Cross-type comparisons
Kwankyu Lee wrote: > I expect that the comparison operators try to return mathematically > sensible result as far as it is practical (one systematic way is to > use coercion), and do something else (but still True or False) that is > clearly documented as soon as any difficulty you mentioned can arise. What about <, <=, etc.? Do you agree that they should fail when rather than return a result with no mathematical meaning, even if the result is clearly documented? >> (3) "x != y" and "x == y" never raise an exception. >> >> Why? We are not talking about raising exceptions all the time, only >> in cases where it is likely that there is a bug... > > Because you mentioned TypeError as an option. Yes, sorry if I wasn't clear: what I'm aksing is what benefit you see of returning False instead of raising an error (in the case of !=). Thanks again, -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: coercions from (quadratic) NumberFields to AA
Daniel Krenn wrote: > In the doc of sage.rings.qqbar.AlgebraicRealField._coerce_map_from_ > there is the following test: > > sage: K. = QuadraticField(7, embedding=AA(7).sqrt()) > sage: AA.has_coerce_map_from(K) > True > > Why does this return (correctly) True, although the code of this > method is simply > > def _coerce_map_from_(self, from_par): > return (from_par is ZZ or from_par is QQ > or from_par is AA) > > ? Probably because NumberField_generic.__init__() does: self._populate_coercion_lists_(embedding=embedding) -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: coercions from (quadratic) NumberFields to AA
Travis Scrimshaw wrote: > That is not true. Note that Foo.has_coerce_map_from() is not > Foo._coerce_map_from_(). The method has_coerce_map_from() calls > _coerce_map_from_, which should either return a coercion map or True, > and in the latter case, then it uses Foo(bar) to define the coercion > (which really uses _element_constructor_). What has_coerce_map_from() > does is it checks to see if _coerce_map_from_() returns something that > is not False (or perhaps None, I forget off-hand). Sorry, I don't understand what you mean. As far as I can see, has_coerce_map_from() calls _internal_coerce_map_from(), which first looks in _coerce_from_hash and only then, if nothing is found, calls discover_coerce_map_from() which eventually calls _coerce_map_from_(). But _coerce_from_hash is also affected by _populate_coercion_lists_(), via register_coercion(). -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: coercions from (quadratic) NumberFields to AA
Travis Scrimshaw wrote: > If no coercion is currently known, then coerce_map_from() calls > _coerce_map_from_(). If _coerce_map_from_() returns a map, then that > map becomes the coercion map. If it simply returns True, then the > coercion map is constructed by using _element_constructor_() as the > definition of the map. In either case, a coercion map is constructed > and stored. Sure, but I still don't see how that's relevant. Perhaps I didn't understand what you said wasn't true in your previous message. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: symbolics: is_real versus conversion to RR
Emmanuel Charpentier wrote: > Should this be discussed again, with a call for *VOTE* ? I don't think this is something that can be decided independently of other conventions (such as the semantics of equality and comparisons and the handling of inexactness). At the very least, I think someone would have to dig through the archive of sage-devel and summarize the arguments brought up in previous discussions before it would make sense to vote. But I agree that there is a strong need for clarifying and documenting this kind of general conventions. I find it really frustrating, both as a user and an occasional contributor, to see the developer guide discuss at length things like the use of git, trac and cython (that are not specific to sage) and say so little about sage conventions on things that need to be handled consistently over the whole codebase (to name but a few: "unknown" results and comparisons again, current vs deprecated best practices, coercions involving "special" parents like SR, InfinityRing or interfaces, branches of analytic functions, semantics of real and complex parents, of variable names [wrt comparison and coercion], of methods like is_field() or is_exact(), when to use conversion and when to use coercion in library code...). -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Names of special methods like _pari_
Jeroen Demeyer wrote: > (4) __pari__(): consistent with Python (__int__, __str__) and NumPy > (__array__). However, creating such names possibly goes against the > Python documentation [2]. Why "possibly"? The way I understand [2] is that __names__ are reserved for use by the Python interpreter and standard library, period. In this particular case, it is unlikely that Python ever specifies a __pari__() magic method. But if you want to do the same with all conversion methods, there could well be a conflict with some future standard python module. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: algdep (PARI) with clang on FreeBSD
Thierry wrote: > I do not remember where i read that (correct me if i am wrong, or > provide a reference if you know where it is), but RDF is supposed to > round towards the nearest floating-point number. RR is, but I think RDF may or may not provide correct rounding depending what the underlying libm does. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Re: algdep (PARI) with clang on FreeBSD
Thierry wrote: > I found the reference i was looking for : > http://doc.sagemath.org/html/en/reference/rings_numerical/sage/rings/real_double.html#sage.rings.real_double.RealDoubleElement.ulp That the default rounding mode is round-to-nearest means that correctly rounded results should be rounded to the nearest floating-point number (as opposed to upwards, towards zero...), not necessarily that all operations return correctly rounded results. But you are right that in the particular case of sqrt(3), one would expect the result to be correctly rounded, since the IEEE-754 standard requires correct rounding for square roots, and processors usually follow it... -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: RR, coercion of numpy.float32() and clang - coercion experts needed
Dima Pasechnik wrote:
> but it looks as if it might be a coercion problem.
> Any ideas where to look?
Not really, but it does look like the common parent
discovered by the coercion system is incorrect:
sage: import numpy as np
sage: a = np.float('1.5')
sage: b = np.float32('1.5')
sage: get_coercion_model().common_parent(b, polygen(RR))
Univariate Polynomial Ring in x over Real Field with 53 bits of
precision
sage: RR.coerce(a)
1.50
sage: RR.coerce(b)
...
TypeError: no canonical coercion from to Real
Field with 53 bits of precision
sage: get_coercion_model().common_parent(b, RR)
--
Marc
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Inconsistencies in comparing
Hi, Ralf Stephan wrote: > This though seems buggy: > sage: BF = RealBallField(precision=2) > sage: BF(1.002)>BF(1.001) > True > sage: BF(1.002)-BF(1.001) > [+/- 1.20e-7] I don't think there is a bug here. The difference prints as an interval containing zero, but this is a correct over-approximation, so no problem here. And note that we have: sage: d = BF(1.002)-BF(1.001) sage: d.mid(), d.rad() (8.9e-8, 2.9802322e-8) sage: d > 0 True Under the hood, what happens is that a ball field of precision p can contain elements represented with more than p bits of mantissa. (Subsequent *operations* on those elements will be done with a precision of p, though.) This is convenient in combination with automatic coercion. In particular, it is possible to coerce both operands of an operation between elements of different ball fields to the less precise one without information loss. > But then I would expect CC to raise exceptions for this: > sage: CC(I+1)>CC(I) > True > sage: CC(I-1)>CC(2*I) > False [...] > This should IMO raise exceptions: > sage: RealInterval(1,upper=2) False > sage: > ComplexIntervalFieldElement(1,1)>ComplexIntervalFieldElement(0,2) True I agree. Unfortunately, due to the confusion between cmp and richcmp in many parts of sage, and to existing code that depends on this confusion, making it happen still requires a bit of work. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Inconsistencies in comparing
Ralf Stephan wrote: > Do I understand it right that then I can coerce a real to a complex > ball and always back to a real without raising an exception? Coerce, no; convert, yes, I think (assuming that by "a real" you mean "an element of a RealField"), but that's an implementation detail, not something you should rely on. > It does not work with interval fields: > sage: RR(CIF(1)) > 1.00 > sage: RR(CIF(1/7)) > ... > TypeError: unable to convert '0.1428571428571429?' to a real number But here, you aren't converting back something that was obtained by converting a floating-point number. Is isn't going to work in this case, even with ball fields. And unlike ball fields, interval fields do round floating-point numbers to the interval field precision, so that converting back is not possible in general. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Should RLF/CLF be exact ?
Hi, Thierry wrote: > I opened https://trac.sagemath.org/ticket/22960 but i am not sure > whether RLF should stop claiming it is exact or whether we should > forbid things like RLF(0.1), what do you think (the first is easier to > implement) ? The latter option sounds better to me. A third way might be to "exactify" elements of inexact real fields (using x.exact_rational() for instance) when converting to RLF. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Sage policy question: require docstrings and doctests?
Jeroen Demeyer wrote: >>- random seeds are always the same > > That can easily be fixed by explicitly changing the random seed in the > doctest (probably some helper context should be provided for this) Or, in the case of complicated tests done by a dedicated function, by using sage.misc.random_testing. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Sage policy question: require docstrings and doctests?
Jeroen Demeyer wrote: > For functions which are meant to be called directly by end users, > doctests are essential because they should show examples of how the > function should actually be used. However, for internal functions or > things like __init__, it is often not easy to write meaningful > docstrings. I suspect the policy of doctesting every function also discourages people from breaking their code into simpler functions. And it is not clear that it improves the documentation (or testing) even of the helper functions themselves, because pretty often it would make more sense to describe and test, say, a number of private methods of a class at once, in the class docstring. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Poll for issue G1 a specific guideline for writing docstrings
Kwankyu Lee wrote: > G1. Write > > Return True if something is true. > > but do not write > > Return ``True`` if something is true. > > The same applies to `False` and `None` X -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Poll for issue G4 a specific guideline for writing docstrings
Kwankyu Lee wrote: > G4. OUTPUT block is optional +1 -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Poll for issue G3 a specific guideline for writing docstrings
Kwankyu Lee wrote: > G3. Write (1) > > Return True if the lattice is reflexive. > > but do not write (2) > > Return True if the lattice is reflexive and False otherwise. > > nor (3) > > Return whether the lattice is reflexive. > > nor (4) > > Test if the lattice is reflexive. X -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Poll for issue G5 a specific guideline for writing docstrings
Kwankyu Lee wrote: > G5. Write > > OUTPUT: > > - lattice > > > but do not write > > OUTPUT: > > lattice X -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Poll for issue G2 a specific guideline for writing docstrings
Kwankyu Lee wrote: > G2. Write > > if the lattice is reflexive ... > > but don't write > > if ``self`` is reflexive ... X -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Re: should "foo?" print TESTS: blocks or omit them?
Jori Mäntysalo wrote: >> And those edge cases should be documented. > > Maybe. But something like Graph().is_connected() is easy to check, if > the user wants to know if empty graph is defined to be connected. When there is no ambiguity in the method that will be called, yes. But as soon as you have multiple implementations or some level of genericity, things are less clear, and it is better if the expected behaviour is *documented*. -- Marc -- 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: should "foo?" print TESTS: blocks or omit them?
[X] 'foo?' should NOT display TESTS blocks. [ ] 'foo?' should display TESTS block. -- Marc -- 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 Warnings/Tips
Nathann Cohen wrote: > All I can come up with is something like a 'warning', a message that > would show up once per session, when triggered by a computation. I'm > all ears for any way to tell users things they didn't know they > needed. I'd simply use the Python logging module and introduce a new semi- standard level HINT (that could be on by default in interactive Sage sessions) somewhere between WARNING and INFO. -- Marc -- 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: domain:complex
William Stein wrote: > I think we should revisit our decision -- from long ago -- to make > domain:complex the default for Sage. Paul Zimmerman argued for it a > long time ago. However, my impression is that symbolic integration is > used mainly by people who are doing purely real-variable undergraduate > education, and for them domain:complex is **very** confusing. Are you talking about symbolic integration only, or are you suggesting to make all symbolic variables real? In any case, I seriously doubt it will solve anything. Making a symbolic calculation engine work consistently looks harder to me with real than with complex variables! What I think Sage's symbolics badly need is a more powerful assumption system (similar to what you find in Maple), and improved high-level commands such as integrate() that would make use of this system. -- Marc -- 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-edu] Re: Article with beautiful math and pictures by SageMath in Notices
William Stein wrote:
>> Copy&paste from pdf is generally troublesome, anything thats not just
>> letter+number is likely to cough up unicode stuff.
>
> Yes. Is there any solution to this, at least is one is created your
> own pdf's using latex?
\usepackage{cmap} is a good starting point.
--
Marc
(replying to sage-devel only as it seems I can't post to sage-edu via
gmane...)
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Re: gamma function enhancement proposal
Fredrik Johansson wrote: > Arb (which is now in Sage) permits computing incomplete gamma > functions with rigorous error bounds over arbitrary-precision > real/complex (interval) fields. Incidentally, the sage bindings (over complex balls) need review: http://trac.sagemath.org/ticket/19082 -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Matrix unicode output
Vincent Delecroix wrote: > At least you can do > > sage: from sage.repl.rich_output import get_display_manager > sage: dm = get_display_manager() > sage: dm.text = 'unicode_art' ...or sage: %display unicode_art sage: matrix.block(3,3,[matrix.ones(2)]*9) ⎛1 1│1 1│1 1⎞ ⎜1 1│1 1│1 1⎟ ⎜───┼───┼───⎟ ⎜1 1│1 1│1 1⎟ ⎜1 1│1 1│1 1⎟ ⎜───┼───┼───⎟ ⎜1 1│1 1│1 1⎟ ⎝1 1│1 1│1 1⎠ -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Unitary divisors
mmarco wrote: > I have also > missed something like .squarefree_part() or something like that. I've had a branch lying around for some time with exactly that; I just pushed it to trac: http://trac.sagemath.org/ticket/20368 -- Marc Mezzarobba -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Heavy-computation @property in Matrix class
Johan S. R. Nielsen wrote: > 1) This is a property that can throw an exception. Isn't that a > problem? > > 2) This is a property that runs a heavy computation when called. Isn't > that a problem? My two cents: both are problems, and matrix.I is problematic for this reason. However, things like matrix.T that don't have these problems(?) are fine with me (though I think ideally matrix.T should return a *view* on the transpose). A lazy variant of matrix.I that wouldn't compute the inverse right away would be okay too. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Deprecate the use of properties in all public API (was: Heavy-computation @property in Matrix class)
Johan S. R. Nielsen wrote: > [X] Phase out properties that might (expectedly) throw exceptions, such > as Matrix.I. Condone the use of properties as "getters" of derived > information, such as Matrix.T (transpose). -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: [gdr-im] Announcing Sollya 5.0
saad khalid wrote: > I don't know much about this so I thought I would just ask, how would > using this benefit Sage? Is it comparable to mpmath and MPFR? If so, > how does it compare? Sorry for my ignorance. Also, what is the target? Sollya is mainly aimed at developers of floating-point libraries, and in particular at people who need to implement elementary functions with accuracy guarantees. It is a rather specialized tool, and I doubt it would be of much use to Sage. Some features, e.g. the Remez exchange algorithm, would definitely be nice to have, but I'm not convinced they are worth the effort of interfacing enough of Sollya to make them usable from Sage. Sollya-Sage bindings, however, would be useful for *Sollya* users, who sometimes need more in terms of computer algebra features than Sollya can reasonably provide. Nicolas Brunie and myself already wrote Cython bindings for Sollya for a research project we are involved in. The code is a bit on the quick'n dirty side, but it is available at https://scm.gforge.inria.fr/anonscm/git/metalibm/pythonsollya.git in case someone wants to play with it. I'd like to add a Sage-specific extension at some point in order to make it possible to convert things like multiple-precision numbers, polynomials, and perhaps symbolic expressions between Sollya and Sage. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: more tests in sage (not doctests)
Michael Orlitzky wrote: > It's a little dangerous, our doctest framework uses the XKCD random > number generator. If you run ZZ.random_element() in a doctest it will > always output the same number. You have to work around it by calling > set_random_seed() before every test. There is a @random_testing decorator that is supposed to help with that. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Dealing with libc math differences
Jeroen Demeyer wrote: > If the error is 1 ulp or more for a basic function (like log) on a > reasonable non-pathological input (like 3.0), I would consider that > an upstream bug. Quite a few implementations only provide accuracies of 3-4 ulp for speed reasons (it may make it possible to use double precision internally for intermediate operations that would otherwise require some kind of extended precision). -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Sage's handling of complex I
Ralf Stephan wrote: > Now, in an existing doctest `sin(QQbar(I))` gives an error > because number field I and QQbar I are in the same arithmetic > operation. If one expects something non-crashing resulting from > `sin(QQbar(I))`, what should we do? IMO, fix embedded number fields so that they coerce into QQbar. There have been tickets towards that goal for a long time, but it still requires some work. > Try to return `I*sinh(1)` where `I` is what? `QQbar` or number field? As long as it is embedded in a symbolic expression, I don't think it matters much. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Faster way to load python code
Hi Simon, Simon King wrote: > Is there a faster way to read and evaluate a large python code > block than sage.repl.load.load? I think %runfile is somewhat faster, though not exactly fast. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Re: How much do we support the casual user
John Cremona wrote: > However pedantic you are it is very hard indeed to justify this for a > package which is intended for a wide class of users: > > sage: a = 300/100 > sage: a > 3 > sage: a in ZZ > True > sage: a.is_prime() > False Yes, but having a.is_prime() return True may break generic code written for arbitrary commutative rings that needs to specialize gracefully to fields. This looks less likely with Vincent's examples, though factor() may be a borderline case. -- Marc -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Re: How much do we support the casual user
William Stein wrote:
> If we are going to change something in this case, probably Simon's
> suggestion to have a warning (that can be turned off) be printed by
> the top-level globalsI() is_prime when confronted with a field element
> seems best... It definitely won't break anybody's code, and avoids
> Ralf's confusion.
FWIW, Maple has a specific message type ("hint") for things that aren't
really warnings but may help the interactive user do what they want.
These messages are on by default but can be disabled globally.
There may be a use for something similar in Sage (based on the standard
python logging module, for instance).
--
Marc
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
