you would like to
see covered.
Attendance is free of charge. To register, please contact me, preferably
before December 1st.
--
Marc, for the organizers: Ricardo Buring, Fredrik Johansson,
Pierre Lairez, Marc Mezzarobba
--
You received this message because you are subscribed to the Google
Dima Pasechnik wrote:
> the function 1/n : AA->AA is 1-1 on all AA, and I don't see why this
> property should be broken. Mathematically it makes perfect sense as
> is.
Because the ** operator is part of the coercion system, and AA coerces
into QQbar, CC, etc.
> In fact, it should also work like
Hi Dima,
Dima Pasechnik wrote:
> So this is due to "0 < char <= 2**17 and deg != elim.degree()" - added
> by you - which does not make sense to me.
> Is this "Criterion" no longer applicable?
I don't know. This criterion was suggested to me by Mohab after I
complained that msolve -P 1 often retur
'Peter Mueller' via sage-devel wrote:
> I guess that in your snippet, you manually typed the `enter` key after
> the `cat` command in the console.
Hmm, no, there is a newline at the end:
~$ hexdump -c /tmp/tmprcz_zw9l
000 a , b \n 2 \n a ^ 2 + a , \n b ^ 2
010
'Peter Mueller' via sage-devel wrote:
> R. = GF(2)[]
> L = [a^2+a, b^2+b]
> I = ideal(L)
> V = I.variety(algorithm='msolve', proof=False)
>
> raises a `ValueError: positive-dimensional ideal`, which of course is
> nonsense. Exporting the system to an msolve-readable file and using
> msolve directl
Hi,
At https://github.com/sagemath/sage/pull/35848 I'm trying to make sage
build with flint3. It does build on my laptop, but autoreconf seems to
behave differently locally and on the CI VMs, and I have no idea why.
It would be great if someone with more knowledge of autotools and/or
our CI infras
Marc Mezzarobba wrote:
> Maybe related: search patterns of the form mentions:someone (including
> the default filter 'Everything mentioning you') seem to only return
> issues created after the migration.
...However, involves:@me seems to work.
--
Marc
--
You received this
Marc Mezzarobba wrote:
> Another one (more of a warning to other users actually): apparently
> subscriptions to issues have not been migrated; you need to
> re-subscribe to issues you are interested in.
Maybe related: search patterns of the form mentions:someone (including
the defau
Marc Mezzarobba wrote:
> A minor point: the PR template still says "we are not accepting pull
> requests yet".
Another one (more of a warning to other users actually): apparently
subscriptions to issues have not been migrated; you need to
re-subscribe to issues you are interest
Thank you all for your work!
A minor point: the PR template still says "we are not accepting pull
requests yet".
--
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 e
they see fit, and let new conventions emerge.
--
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.
Nils Bruin wrote:
> Speaking of backups ... do we backup the sage-devel, sage-support news
> groups?
They are on gmane, and presumably some sage developers have more or less
complete archives on their own computers...
> In fact, they are sometimes referred to on trac, via
> super-opaque URLs.
I
John H Palmieri wrote:
> You would think that this would be a solved problem: others in the
> open source community must have be in the practice of backing up their
> GitHub info.
The following tools seem fairly complete:
- https://github-backup.branchable.com/ (but I'm getting timeouts with
it),
Vincent Delecroix wrote:
> Though these are specifications for SR and does
> not apply to the entire library. It is not clear to me what global
> specification we could have for bool(algebraic expression).
Something like "bool(x) iff x is not trivially zero" would make sense to
me, where "not triv
Emmanuel Charpentier wrote:
> +1 for Github
>
> Also wishing for contingency plan for re-migrating to self-hosted
> Gitlab.
Same here.
--
Marc
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving em
William Stein wrote:
> Perhaps this is a bad criteria, e.g.,
> it excludes our webmaster (Harald Schilly), since he's done a lot to
> support Sage, but I don't think he's contributed code to the library
> -- at least I didn't find him in Dima's list from GitHub.
Looks like he has:
~/co/sage:devel
Matthias Koeppe wrote:
> This is great question, thanks for the pointer to this GitLab.com URL.
> I've updated
>
https://github.com/sagemath/sage/wiki/Github-vs-Gitlab-vs-trac#in-favor-of-gitlab
> based on it.
Additionally, here in France at least, many universities and research
institutes already
Samuel Lelièvre wrote:
> a. The company operating GitHub can block access to GitHub,
> block account creation, or terminate accounts for individuals,
> companies or countries without prior notice on discriminatory
> grounds, see links below.
>
> b. Relying on free software tools for essential infr
at
sagemath.org?
> --grep="^Trac #25848" --pretty='%H') --exclude='*beta*'
> --exclude='*rc*' --candidates=0
> fatal: cannot describe '4c9486b75fb02b14a21278bb69e44998c5045ccd'
--
Marc Mezzarobba
--
You received this message because y
David Ayotte wrote:
> I have a question: given a trac ticket number, is there a way of
> recover the "Merge In" field of the ticket with the command line? I'd
> like to automatically add this info to the list.
In case they differ, do you want the contents of this field as it
appears on trac, or th
Dima Pasechnik wrote:
> this script goes for a simpler route - it writes GitHub logins (or
> original trac logins for the cases where there is no match) of users
> who commented, etc. into
> comments text. This does not need authorisation from users, but it's
> arguably less nice looking.
Not just
Dima Pasechnik wrote:
> I've conducted few experiments with a tool to import trac sites to
> github: https://github.com/svigerske/trac-to-github, which in
> particular allows to import trac tickets as github issues; a result of
> running it on few tickets
> may be inspected
> here:
> https://github
Matthias Koeppe wrote:
> OK, good point, and I agree. I'll work that into the wiki page.
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-de
osed change.
--
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 view this discussion on
Matthias Koeppe wrote:
> Yes, of course, and that's what I am documenting
> at https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b
Sorry, apparently I misunderstood your proposal.
I would suggest the following changes then:
"Instead of opening a Trac ticket"
--> "To report a bug,
en the contributions were not
developed on github but simply ended up in a repository mirrored on
github.
--
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 i
be more natural to use issues for, well, issues (that is,
bug reports, as opposed to bug *fixes* or enhancements) and pull
requests for proposed changes?
--
Marc Mezzarobba
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscrib
Matthias Koeppe wrote:
> See
>
https://trac.sagemath.org/wiki/ReleaseTours/sage-9.7#sagesage.ringssage.libs...arenowPEP420namespacepackages
> and https://trac.sagemath.org/ticket/34221
Thanks a lot!
--
Marc
--
You received this message because you are subscribed to the Google Groups
"sage-dev
Hi everyone,
Some external packages that cimport cython modules from sage no
longer build with sage 9.7.beta8. It looks like this is due to
some recent change in Sage, as is reportedly works with sage 9.6.
Two examples:
~/co/sage:develop$ ./sage -pip install sage-flatsurf
Collecting sage-flatsur
William Stein wrote:
> The 3 people who expressed interest in being on the Sage dev prize
> committee are me, John Cremona, and Karl-Dieter Crisman.
Didn't Samuel Lelièvre also volunteer?
--
Marc
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
Dima Pasechnik wrote:
>> The graph clearly shows that there was a critical point between 2012
>> and 2014. I am curious what were major changes of circumstances
>> around then.
>>
> OpenDreamKit grant, obviously.
And the switch to git, I assume. For me at least, the "new" development
workflow has
sage-de...@lists.sourceforge.net is still receiving new messages--99%
spam, but not 100%, see:
https://sourceforge.net/p/sage/mailman/sage-devel/
Does anyone have the necessary permissions to shut it down?
--
Marc
--
You received this message because you are subscribed to the Google Groups
"
Dima Pasechnik wrote:
> hopefully everything needed to fix docker builds will be merged in the
> coming beta.
Ok, thank you!
--
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 i
The most recent Docker image (excluding develop/latest) at
https://hub.docker.com/r/sagemath/sagemath/tags
corresponds to Sage 9.2.beta3. Is that normal?
Thanks,
--
Marc
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this
Nathan Dunfield wrote:
> -1: I don't really care what RealField.__repr__ returns, but cast a
> token no vote to object to the logical next move of breaking backwards
> compatibility by changing the meaning of RealField and/or RR. I see
> the need for a "genuine real field", but it seems a lot simp
Michael Jung wrote:
> Ah, interesting. Do you have some literature/references for me?
Among the standard references, Chapter 5 of *Modern Computer Algebra* by
von zur Gathen & Gerhard discusses the basic evaluation-interpolation
algorithm for computing the determinant of polynomial matrices in s
Hi Simon,
Simon King wrote:
> According to IEEE 754, the default rounding mode for floating-point
> operations is "round half to even". However, in examples it seems that
> the rounding roule in RR is: "round half away from zero if the total
> number of decimal digits in the result is odd and towa
Simon King wrote:
> But when I then go to Sage command line and hit -insert (which
> usually inserts what was previously copied), nothing happens (resp.
> some text was inserted that I have copied previously). This is with
> vim version 8.2.343
>
> What am I doing wrong?
I don't know. Does y in v
Sébastien Labbé wrote:
> But I am not getting errors, maybe my vim is too old (7.4.1689). I
> need to update my machine but I am always postponing this to tomorro
Indeed, it looks like I'm using features that appeared with vim 8.
--
Marc
--
You received this message because you are subscribed
Simon King wrote:
> sorry, I still don't get what *exactly* one needs to do in order to
> achieve *what*.
My post was intended mainly for vim users who would be able to figure
out on their own what the code does and find it useful for their
workflow. I didn't realize anyone else might be interes
Marc Mezzarobba wrote:
> vnoremap Y :call YankSageTest(visualmode(), 1)' missing at the end
--
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 em
Sébastien Labbé wrote:
> Should I understand that it filters out the output? Can you tell how
> you use it?
It only works linewise, and is mapped to Y, which is
probably something like \Y depending on your setup. You can use it
either by selecting some text in visual mode and typing \Y, or typin
Is it expected that ARB_LIBRARY is set to 'arb' (as opposed to
'flint-arb') on a Debian box where Sage links against the system
arb?
The linker complains about not finding -larb when I try to build
an external cython module that uses sage.rings.complex_arb. And
indeed, it should have looked for -l
Just in case it may be useful to somebody else, here is a vim config
snippet for copy-pasting examples and doctests to the sage repl.
(Improvements welcome!)
function! YankSageTest(type, ...)
if a:0
let lines = getline("'<", "'>")
else
let lines = getline("'[", "']")
Michael Orlitzky wrote:
> This is the right way to do it. The user/system already has UMASK set
> to something generally acceptable. When you create a sensitive file,
> you mask more permission bits, create the file, and then revert the
> umask. After that, you leave everything alone.
Ok, thank yo
Hi,
I just noticed that Sage unconditionally changes the permissions of the
DOT_SAGE directory to rwx--- even after the user manually modified them
(sage/misc/misc.py, l. 92ff). It seems to me however that there are
perfectly valid reasons to share one's .sage with other users. Worse,
Sage cras
Nils Bruin wrote:
> I don't think that for any non-trivial applications generic code is
> going to perform properly for both exact and non-exact base rings, but
> actually the equality choice that has been made, allows the heuristic
> approach: start with very high precision or double the precision
Nils Bruin wrote:
> I think the only choice (if any) is to match the occurrence of a name
> in the smallest ring.
>
> If your generic code is relying on coercion in a setting where name
> matching like this is relevant, I suspect it's almost certainly the
> wrong choice.
I think we agree. To clar
[re-posting a reply from a week ago that apparently did not go through
because of the gmane move]
David Roe wrote:
>> So one thing I thought of that could be a problem is this:
>>
>> ZZ['x'] --> ZZ['x,y']['x']
>>
>> or more generally anytime there are repeated variable names.
>> Actually, in this
[re-posting a reply from a week ago that apparently did not go through
because gmane was moving]
Nils Bruin wrote:
> This model has the advantage that (sqrt(1+t)^2 -1)/t == 1 returns
> true, as one would expect mathematically.
Do you mean it has the advantage that cos(sin(tan(t^2)) -
tan(sin(t^
Marc Mezzarobba wrote:
>> sage: def f():
>> : for i in [x]range(1):
>> : a+a
>
> where a = Integer(1).
>
> If a is made local to the function, the very expensive lookups
> disappear, and we still see calls to PyLong_FromLong taking
Marc Mezzarobba wrote:
> Some profiling data (via linux-perf) for
>
> sage: def f():
> : for i in [x]range(1):
> : a+a
where a = Integer(1).
If a is made local to the function, the very expensive lookups
disappear, and we still see calls to PyLong_
Some profiling data (via linux-perf) for
sage: def f():
: for i in [x]range(1):
: a+a
Py2:
Samples: 26K of event 'cycles', Event count (approx.): 17630706503
Children Self Command Shared ObjectSymbol
+ 77,85%47,79% python2 libpython2.7.so.1.0
Vincent Delecroix wrote:
> Then I guess the reason of the slowdown comes from the change in
> the integer types in Python 3 and the way we handle the conversion
> from Python integers to Sage integers
This may be part of it, but I don't think it explains everything:
sage: a = 1
sage: %timeit a+a
Vincent Delecroix wrote:
> @Marc: could you perform some C profiling (it might work directly
> inside Sage via %crun [2]).
Yes, I'll try to investigate a bit more, but I first wanted to ask if it
was a known issue.
--
Marc
--
You received this message because you are subscribed to the Google
Something like object creation, memory allocation, basic arithmetic, or
cython calls seems to have become a lot slower recently.
Overall, my Python code using sage runs about 10% slower with 9.0.beta6
than with 8.9. The slowdown seems to be spread evenly across many
different functions.
But he
Hi,
Maybe a stupid question, but: does Sage really need to build all
these static libraries? Why?
456M./local/lib/libgiac.a
144M./local/lib/libec.a
120M./local/lib/libppl_c.a
107M./local/lib/libpari.a
69M ./local/lib/libppl.a
48M ./local/lib/libsymmetrica.a
31M ./local
Nisoli Isaia wrote:
> I've seen that you wrote a sage interface for sollya, which
> seems to take already take care of Taylor models.
Indeed, though the Taylor models in Sollya may be a bit limited, and (if
I understood right, but I'm really no expert here) have some performance
issues.
> Is So
Nisoli Isaia wrote:
> P.=CBF[]
> x._sin_series(4)
Indeed, I remembered wrong. Only a few of these arb functions are
accessible from sage at this point. It is trivial to add more, though.
The relevant files are
src/sage/libs/arb/acb_poly.pxd
src/sage/rings/polynomial/polynomial_complex_arb.pyx
Nisoli Isaia wrote:
> I was planning in doing a Cython implementation of Forward automatic
> differentiation and
> Taylor arithmetics as in
> https://press.princeton.edu/titles/9488.html
> to use to implement a library for Sage with rigorous quadrature and
> integration of ODE.
This is very inter
Gabriel Frieden wrote:
> I'm trying to run sage from TeXmacs, and I followed the instructions
> here: https://wiki.sagemath.org/TeXmacs. When I click on Insert -->
> Session --> SAGE, I get the message "Busy..." where it should give the
> version information, above the input line with "Sage]." I ca
Erik Bray wrote:
> Personally I'm hesitant to touch that just because I don't want to go
> deleting *anyone*'s branches that aren't my own.
FWIW, I've been deleting my old branches as well as some old public
branches I had worked on for years now, and I don't think anyone ever
complained.
--
M
Hello everyone,
Please allow me to advertise a couple of tickets currently waiting to be
reviewed that deal with fraction field elements, and in particular
rational fractions in several variables:
https://trac.sagemath.org/ticket/25290
https://trac.sagemath.org/ticket/23909
https://trac.sagemat
Travis Scrimshaw wrote:
>> I agree that having x^-1 and 1/x being different is confusing. I will
>> update the branch at #25524 to make them identically return a
>> rational fraction.
>
> I think this is even worse than the confusion.
I agree with that.
>> Though, close to what Nils talked about
Travis Scrimshaw wrote:
> A casual user will almost certainly do
>
> 1 / x^k
>
> and then try to do a method on Laurent polynomials (say, iterate over
> such element). The rational functions code does not have many of the
> methods and features that Laurent polynomials have.
Yes, but is that rea
John Cremona wrote:
> I hope it is not being suggested that we have to add tangent() as an
> alias to tan(), logoarithm() as an alias to log(), etc etc etc
I made the comparison with acos() because ceil() clearly is the usual
notation for me (I didn't know of any language or library calling it
c
Kwankyu Lee wrote:
> I guess, one principle in Sage is to use the full name unless an
> abbreviated form is already firmly rooted in our culture
I consider ceil() about as standard as, say, acos()...
--
Marc
--
You received this message because you are subscribed to the Google Groups
"sage-de
Travis Scrimshaw wrote:
> In terms of surprise, the fast == is clearly worse,
It is not that clear to me! (What I think I'd expect if I didn't know
Sage would be for == to compare the representation of the objects, not
their mathematical semantics, even when that semantics is unambiguous.)
--
Vincent Delecroix wrote:
> That does not prevent us to normalize for let say: __repr__() ,
> numerator(), denominator(). Is there any reasonable rule to choose
> when to and when not to normalize? For QQ itself, GMP does normalize
> all the time.
Just to be certain that we are talking about the sa
John Cremona wrote:
> This is simpler than writing numerator and denominator as a rational
> times a primitive integral polynomial, though that is probably what
> users would prefer.
And (at least in my limited experience), for rational fractions over
general fraction fields (things like ℚ(x)(y),
Matthias Koeppe wrote:
> This is discussed in https://trac.sagemath.org/ticket/16993
...and https://trac.sagemath.org/ticket/16268 (needs review!).
--
Marc
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop
Thierry wrote:
> sudo iptables -A OUTPUT -j ACCEPT -o lo
> sudo iptables -A OUTPUT -j ACCEPT -o 127.0.0.1
> sudo iptables -A OUTPUT -j DROP
>
> But i guess this is not what you want.
I don't know the details, but it looks like nowadays there
are ways to do something a little more fine-grained:
Simon King wrote:
> The reason he gave: In Mathematica, matrices can be defined with a
> graphical tool. Hence, one can input some entries, use arrow keys to
> switch from entry to entry, and can insert (and delete?) rows or
> columns on the fly.
>
> I think it would be nice for SageMath to have s
Dima Pasechnik wrote:
> is_prime() should be restricted to rings in which one can have
> non-trivial prime elements
Well, that's what I'm doubting. If the goal is that the global
is_prime() function doesn't do anything surprising for people who would
have integers in mind, then it may be better
Simon King wrote:
> That makes sense to me.
> Thus I now think, z.is_prime() should roughly work like this:
> def is_prime(self):
> ...
What about keeping the is_prime() *method* unchanged (except perhaps for
adding an optional warning in the default implementation for field
elements), and r
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 avo
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 cod
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
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 coer
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 i
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 em
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
-
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
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 unsu
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
> d
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
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 mig
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
so
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
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_coerc
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 rounde
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
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 a
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 wo
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
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
> (
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 th
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 ar
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 po
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
1 - 100 of 217 matches
Mail list logo
