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 y
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, Op
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 sag
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...@googlegr
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 exp
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
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 exactl
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 de
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
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 )
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 t
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
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 exis
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/1
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?
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 subsc
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 indetermi
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
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:
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
>
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--
whi
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-a
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/sof
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 e
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
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
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 *&.
Ac
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.
Y
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
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
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 "
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 p
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
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
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
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) instea
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
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
> requir
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)
Tru
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
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, thoug
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
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" g
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_coerc
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 w
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 subscri
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 ar
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 unsu
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
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 o
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:
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 th
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
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
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 int
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
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
>
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 s
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 co
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
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
--
Yo
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 a
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
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
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
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
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
> (
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
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
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
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
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
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
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
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,
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
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
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
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
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:
> 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:
> 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:
> 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
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
[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
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 ne
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 underg
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.
--
Ma
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
--
M
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)
⎛
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 beca
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 m
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 G
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 librarie
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_tes
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 doub
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
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
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
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
1 - 100 of 221 matches
Mail list logo
