On Oct 30, 11:05 pm, Jan Groenewald wrote:
[...]
> Can sage safely delete older copies before making a new 70M copy?
> I can symlink to local scratch space, not hundreds of stuidents who move
> between machines though.
>
> Can this go in /tmp instead?
See http://common-lisp.net/project/asdf/asdf/
On Sep 15, 6:02 am, Stan Schymanski wrote:
> Would it be possible to formalise
> this somehow, so that I could then type the name of the variable
> further down in the document followed by a question mark to see that
> information again?
One way of establishing this feature is by having "custom d
Hi Simon,
Reasonable options. For me, "...?" is an *introspection* tool, so it
helps me seeing what things look like to sage. Making its output
configurable would detract from its use in that sense (now I have to
worry about the fact that the particular object I'm viewing might be
distorting my vi
On Sep 18, 8:29 am, Marco Streng wrote:
> ps 1 (offtopic). I found this out by trying a few cusom trac queries
> and trac searches and reading quite a few of the search results. Is
> there a more automated way of finding out in which ticket a piece of
> code was changed?
Using "hg annotate" (or,
On Sep 20, 12:36 am, Stan Schymanski wrote:
> That's awesome, thanks a lot, William!
>
> Since this is done in the units package already, is there a way to
> formally save the units of e.g. T_a as units.temperature.Kelvin and then
> have something like:
> sage: T_a = 300
> sage: T_a
> 300 Kelvin
>
On Sep 20, 12:36 am, Stan Schymanski wrote:
> Since this is done in the units package already, is there a way to
> formally save the units of e.g. T_a as units.temperature.Kelvin and then
> have something like:
> sage: T_a = 300
> sage: T_a
> 300 Kelvin
You can of course write T_a=300*units.tempe
On Sep 20, 10:20 am, jireva wrote:
> Hello everyone,
>
> The following creates three variables ``a``, ``b``, and ``c``::
>
> sage: var('a, b, c')
> (a, b, c)
>
> I would expect this to do the same thing::
>
> sage: var(('a', 'b', 'c'))
> (('a', 'b', 'c'))
>
> It doe
On Sep 21, 7:09 am, Stan Schymanski wrote:
> sage: var('T_a')
> or
> sage: T_a = var('T_a')
>
> but William's example does not work if I do
> sage: var2('T_a', 'Air temperature (K)')
> ??
You're well underway with the question-marks, but instead of writing
them on a separate line in an email you
On Sep 24, 11:14 am, Simon King wrote:
> It shows that there are ways to pickle a code object, using the
> marshal and the types modules:
> Question: Should Sage's save/dumps and load/loads use the trick above
> to pickle functions that can't be pickled otherwise?
Very interesting! Look at the bi
On Sep 24, 12:04 pm, Nils Bruin wrote:
> Does it properly recreate a function that resulted from a closure?
It doesn't but with a little extra work it can. There is a bit of
trouble that closures require "cell" objects which one cannot create
normally. However, they're cre
On Sep 24, 1:02 pm, Simon King wrote:
> Yes, that's not good. Unless it is possible to keep an old marshal
> version around even after upgrading python?
It's not the version of marshal, it's the underlying data. CPython
VM's bytecode can change between versions. For improving the language
impleme
On Sep 24, 11:14 am, Simon King wrote:
> Question: Should Sage's save/dumps and load/loads use the trick above
> to pickle functions that can't be pickled otherwise?
I still think the answer should be "by default no", but at the same
time I think the ability to pickle code is incredibly useful whe
On Sep 26, 1:17 am, Volker Braun wrote:
> Python pickles are not long-term data storage formats.
That's one interpretation, but I'm not sure Sage presently does a very
good job at propagating that view. Granted, I would not store data I
really care about in pickles, but that is because for me it's
On Oct 27, 3:27 am, Burcin Erocal wrote:
> I don't think we can use omalloc in Sage since it is not thread safe.
> Using GMP with two different memory allocators is not an option either.
> So I am not sure if this problem can be solved easily.
A similar issue arises in ECL. By default, it plugs
On Oct 30, 10:12 am, Francois Bissey
wrote:
> There is also the fact that a number of packages check:
> sys.platform == 'linux2'
One quick data point: on FC 15 they are shipping linux 3.* kernels
with a fake 2.* version number exactly for compatibility reasons (I
don't think it's just python). I
On Nov 6, 4:40 am, Jeroen Demeyer wrote:
> I just tried to do this for sage-4.8.alpha1 and the problem is reviewer
> patches. If a ticket has a "main" patch adding new trailing whitespace
> and a "reviewer" ticket changing those lines, then removing new trailing
> whitespace from patches creates
The documentation of find_maximum_on_interval shows this is a
numerical function that is not prepared to take symbolic expressions.
However, the error message is deplorable. Ticket:
http://trac.sagemath.org/sage_trac/ticket/12032
--
To post to this group, send an email to sage-devel@googlegroups
On Nov 24, 10:53 pm, Dima Pasechnik wrote:
> It's a good question how to make this capability used in Sage.
This capability is already perfectly usable in Sage:
sage: M=sage.calculus.calculus.maxima
sage: M.eval("g(x):=block([s:0],for i thru x do s:s+i^2,s);")
'g(x):=block([s:0],forithruxdos:s+i
On Nov 27, 11:59 pm, Dima Pasechnik wrote:
> I just checked, and saw that under Sage's ECL lisp (i.e. sage -lisp),
> (pathname "")
> produces an error (illegal seek) on Cygwin, while on MacOSX and Linux it's
> perfectly OK.
I'd say that's a bug for ECL/Cygwin (which of the two is at fault I do
n
On Nov 28, 1:29 am, Dima Pasechnik wrote:
> I guess the root of the problem is here:
> here is another weirdness, which might explain the PATHNAME error message
> On Cygwin, ECL gives
>
> > (directory "")
>
> NIL
>
>
>
> while on supported systems (MacOSX, Linux) you get the current directory:
>
>
My apologies for the last message. That didn't tell you anything you
didn't already know. A little digging in the source got me to:
http://ecls.git.sourceforge.net/git/gitweb.cgi?p=ecls/ecl;a=blob;f=src/c/pathname.d;h=d35bcc58eeeb1f3766b8fc25140253852d94e216;hb=HEAD#l736
which tries to define the
On Nov 28, 11:12 am, Dima Pasechnik wrote:
> I also tried to set the argument of :move-to to an absolute path, but
> this did not help.
And just removing the ":move-here ..."? The normal behaviour of ASDF
should just place the result somewhere in a local tree. The variable
asdf::*user-cache* spe
On Dec 11, 7:11 pm, Rob Beezer wrote:
> sage: Z36 = Integers(36)
> sage: U = [x for x in Z36 if gcd(Integer(x), 36) == 1]
Don't you think the use of the very similar looking "Integers" and
"Integer" might be confusing? If you stick with "conversion by calling
the target parent on it", i.e.,
sag
The bug can be triggered via the pexpect interface to maxima, so it
probably has something to do with the things that sage preloads in
maxima:
sage: maxima("integrate(sin(t)^2/(1*cos(t) + 1.5)^2,t,0,2*%pi)")
TypeError: Error executing code in Maxima
CODE:
sage1 : integrate(sin(t)^2/(1*cos(
On Dec 13, 11:07 am, kcrisman wrote:
> Yes, we try to turn it off as much as possible -
> seehttp://hg.sagemath.org/sage-main/file/9e29a3d84c48/sage/interfaces/ma...
> and the keepfloat:true. What an unhelpful error message, then!
I think the error is triggered by an actual bug in "rationalize"
I recall reading something about that in the Python documentation and
indeed, quoting from
http://docs.python.org/library/timeit.html
we find:
"""
Note
It’s tempting to calculate mean and standard deviation from the result
vector and report these. However, this is not very useful. In a
typical
On Dec 13, 4:09 pm, Dan Drake wrote:
> ...especially when the float is 1.5, which can be represented exactly as
> a binary float!
Actually, I think it is by design that "integrate" does not work right
when "keepfloat: true;".
The routine "crecip" (reciprocal modulo "modulus") relies one
dynamical
On Dec 13, 11:27 pm, William Stein wrote:
> At least since we're mathematically savvy, we know that there's a lot
> more to statistics than the normal distribution.
>
> Having never seen any timing distributions (since they are hidden by
> timeit), I don't even know anything about how timings are
On Dec 13, 6:38 pm, kcrisman wrote:
> Yikes! So we wouldn't want
>
> sage: integrate(1.0*x,x,0,2)
> 2
>
> to work any more? (Pace the error messages below.)
>
> Could we not instead try to catch this kind of error and recommend to
> the user that they use rationals? Or something...
well, we *
ffect its use
with Sage, easing our upgrades of ECL. I'm willing to do some work on
this, but as I said, I don't know anything about Sage's buildbots.
Kind regards,
Nils
Nils
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an
On Dec 26, 11:16 am, Michael Orlitzky wrote:
> RuntimeError: unknown function 'f' in archive
>
> Anyone hit this before?
It sounds familiar to me. I think it was discussed, but I cannot find
a reference. I ran into it via
sage: f=function('f')
sage: E=f(x)
sage: loads(E.dumps())
RuntimeError:
On Dec 26, 11:51 am, Nils Bruin wrote:
> It sounds familiar to me. I think it was discussed, but I cannot find
> a reference.
Found: http://trac.sagemath.org/sage_trac/ticket/11919
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, s
Just a ping that a long-standing wart on the ecllib interface has been
fixed: a patch so that GMP integers can now be quickly converted to/
from ECL is waiting for review:
http://trac.sagemath.org/sage_trac/ticket/12239
It's trivial and probably rarely of practical value, given what Sage
uses ECL
On Jan 9, 8:39 am, William Stein wrote:
> When I originally pushed to have secure=True easily available by
> default in Sage for all users, I
> (1) didn't understand that secure=False is safe on localhost,
Via the absolutely zero-configuration one-time certificate opening of
the notebook, I agree
On Jan 17, 2:54 am, Keshav Kini wrote:
[...]
> How does it make anything easier
> or clearer or better for the interactive user that var() injects things
> into global scope? We found ourselves trying in vain to explain this to
> students several times when teaching our Sage-based undergraduate co
On Jan 17, 9:53 am, Burcin Erocal wrote:
> Are we also going to prevent people from defining callable expressions
> using the f(x) = x+1 syntax within functions?
That would be a corollary given how that gets preparsed. That might
have to change because the error message generated by "var" will be
On Jan 20, 10:12 am, "Nicolas M. Thiery"
wrote:
> On Fri, Jul 01, 2011 at 01:04:46PM +0200, Nicolas M. Thiery wrote:
> > Ok, let's not waste more time discussing this. Unless someone
> > complains loud immediately, I consider that there is a consensus on
> > making lrcalc a standard spkg, after a
On Jan 21, 2:15 pm, Ivan Andrus wrote:
> Georg S Weber found a problem with the Mac app [1] which is caused by running
> sage via an applescript via sage-native-execute after having sourced
> sage-env. What happens is the variable SAGE_ENV_SOURCED is set to 1 and then
> the applescript runs op
On Jan 23, 11:39 am, Ivan Andrus wrote:
> Or perhaps your question was why am I running it after sage-env has been
> sourced? Well that could probably be changed but I was running it after I
> checked to make sure the location hasn't changed.
That's probably what Volker meant. So it's probabl
On Jan 25, 7:05 am, Christopher Swenson wrote:
> If we have possible confusions about the numberiung, we should give them
> complex number identifier. So, 37, 37 + i, 37 - i, etc.
>
> Who knows which one comes first then?
Python doesn't:
sage: complex(37,1) 37 -i)
True
--
To post to this group,
On Jan 25, 9:22 am, Volker Braun wrote:
> On Wednesday, January 25, 2012 8:58:15 AM UTC-8, Nils Bruin wrote:
>
> > sage: bool(37 +i < 37 -i)
> > False
>
> False meaning that Sage cannot affirm that it is true; IMHO the correct
> answer.
>
> > sage: bool
A comment on python-ideas made me realize that the sage preparsing of
integer literals and ".." invalidates otherwise valid syntax:
sage: preparser(False)
sage: 1..conjugate()
1.0
sage: preparser(True)
sage: 1..conjugate()
...
SyntaxError: invalid syntax
sage: preparse("1..conjugate()")
'Integer(1
On Feb 22, 1:46 pm, William Stein wrote:
> I would think this is an obvious serious bug... but since it seems so
> blatant, maybe I'm missing something.
See #12580. It looks like it was Witty's design to wrap python's
random rather than set global state immediately. He probably had good
reasons t
On Feb 24, 3:17 pm, William Stein wrote:
[reason for current design]
> But what was it? Since he is MIA, we might not ever know...
When you look a little at how Python's random.Random is designed, his
design seems a fairly clean solution. Whether it leads to a convenient
interface is another q
On Feb 27, 5:37 pm, Dima Pasechnik wrote:
> In Maxima 5.26, one gets
>
> sage: from sage.libs.ecl import *
> sage: ecl_eval('(with-output-to-string (*standard-output*) (maxima-eval
> #$disp(1+1)$))')
>
> ">
Yes, this is apparently just what maxima 5.26 does:
Maxima 5.26.0 http://maxima.sourcefor
On Mar 11, 8:46 pm, Starx wrote:
> The patchbot is reporting a doctest failure in a patch of
> mine:http://trac.sagemath.org/sage_trac/ticket/12630#comment:10
>
> The failure itself is completely benign, "a + b" is being returned
> when "b + a" is expected, but the addition is commutative anyway.
On Mar 13, 11:18 am, Dima Pasechnik wrote:
> I wish GAP worked with MPIR, but the latter does not provide all the GMP
> calls used by GAP.
> It would be good if these were added...
It would probably be *essential* that these get added if GAP is to
ever run in library mode. I doubt that one can ha
On Mar 15, 12:21 am, "syd.lavas...@gmail.com"
wrote:
> The problem is that my home directory is:
>
> /files3/home/sahosse/
>
> but I only have execution permission to the directory "home":
I confirm:
$ mkdir /tmp/test
$ chmod a-r /tmp/test
$ mkdir /tmp/test/a
$ touch /tmp/test/a/b
$ ls /tmp/test
On Mar 15, 3:42 pm, Harald Schilly wrote:
> On Thursday, March 15, 2012 3:55:34 PM UTC+1, William wrote:
>
> > "sage.media.wav"
>
> ah, i wasn't even aware of that. good idea to remove it if it is just dead
> code.
>
> i actually reply because i was thinking about some more general "audio
> proces
On Mar 25, 6:52 pm, Ben Hutz wrote:
> The resultant of two homogeneous polynomials can return an incorrect
> value:
> R.=PolynomialRing(ZZ)
> f=6*x^2 + x*y + y^2
> g=y^2
> print f.resultant(g)
> m=matrix([[6,1,1,0],[0,6,1,1],[0,0,1,0],[0,0,0,1]])
> m.determinant()
>
> notice that the coefficient o
On Mar 31, 5:14 pm, "john.hoebing" wrote:
> sage: a=diff(f,x,x)+diff(f,x)/x
> sage: str(a)
> 'D[0](f)(x, y)/x + D[0, 0](f)(x, y)'
If I understand correctly, you would like to be able to put the above
string into sage and get the expression back? That is of course a very
reasonable goal. The class
On Apr 1, 4:56 am, Harald Schilly wrote:
> > sage: D[0](f)(x, y)/x + D[0, 1](f)(x, y)
>
> For me, this just looks quite awkward.
OK, some reasons *for* the notation then.
1) It's how sage prints the expression. It's very desirable to ensure
that output is also valid input.
2) If you read the sq
On Apr 1, 2:34 pm, Michael Orlitzky wrote:
> If you think you want derivatives right now, you're probably better off
> using aptly-named symbolic variables, and performing the differentiation
> later on once you're done manipulating the "derivatives."
>
> sage: f = function('f', x)
> sage: f
On Apr 2, 12:25 am, Nils Bruin wrote:
> Removing these restrictions is probably a nice student project (you'll
> get to see the internals of quite some parts of sage, but I don't
> think it will ever be overly complicated)
Turns out there is a nasty complicat
On Apr 2, 8:56 pm, Nils Bruin wrote:
> In short, the problem is that
>
> at( f(x,y,z), [x=u,y=v,z=w])
>
> is valid in maxima but cannot be handled because of the list embedded
> in an expression.
Problem solved by extending the grammar accepted by
sage.misc.parser.Parser. Now
On Apr 1, 2:34 pm, Michael Orlitzky wrote:
> Substitution doesn't even work pre-evaluation:
>
>sage: f = function('f', x)
>sage: f_prime = f.diff(x)
> sage: g = function('g', x)
> sage: f_prime.substitute_function(f,g)
> D[0](f)(x)
That's because you're trying to substitute expr
On Apr 6, 12:03 pm, Michael Orlitzky wrote:
> I sort of buy that, but if,
>
> sage: f = function('f', x)
>
> doesn't make `f` a function, that's a user-interface WTF =)
I would tend to agree, but it's a fact of life that function('f',x)
returns the symbolic function f evaluated at x. The docstr
On Apr 6, 3:55 pm, William Stein wrote:
> It does suggest we may want to consider reseting Maxima's counter for
> dummy variables before calling solve. RJF, how does one do that in
> Maxima?
I'm fairly sure that would lead to bugs. If a user constructs new
equations from the results of an earli
On Apr 6, 2:15 pm, Michael Orlitzky wrote:
> That was a too-simple example. You can't create e.g. a cubic spline
> because of the evaluated derivatives. In general the form over [-1,1]
> would look like,
>
> s(f;x) = a(x)*f(-1) + b(x)*f'(-1) + c(x)*f(1) + d(x)*f'(1)
>
Doesn't this do what you w
Yes, that's a bug. Something goes wrong in what gets fed to the
function:
def f(z):
v = sin(x)(x=z)
print "evaluating sin(%s)=%s"%(z,v)
return vsage: find_maximum_on_interval(f,0,2)
evaluating sin(0.7639320225)=0.691766183638
evaluating sin(1.2360679775)=0.944499585162
evaluating sin(1
> ...
> si = numpy.sign(xm-xf) + ((xm-xf)==0)
> ...
> si = numpy.sign(rat) + (rat == 0)
> x = xf + si*max([abs(rat), tol1])
> ...
Ah shoot. That code is quite understandable. What they need is:
si = numpy.sign(xm-xf)
if si == 0:
Excellent initiative! Just make sure that animate(...) accepts general
iterables and only keeps one frame at a time in memory. We won't get
past the requirement that at one point, all frames must exist together
on disk in a directory, but it would be nice to avoid having a full
description of all f
On Apr 14, 7:21 am, John Cremona wrote:
> This issue comes up periodically, but no-one (as far as I know) has
> come up with a good algorithm. The obvious one here is what you get
> if you work in the fraction field of Z[X] instead of Q[X]. Are there
> other special cases which should be handle
If it helps, I am not experiencing this slowdown with 5.0.beta7
(meaning, the example takes about the same time to complete on 4.8 as
on 5.0.b7)
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegr
On Apr 17, 6:26 pm, kcrisman wrote:
> The 4.8 stuff is probably due to a previous Maxima.
>
> In the 5.0 betas, I suspect this particular one is related to things
> like
>
> http://trac.sagemath.org/sage_trac/ticket/8321
Some of the comments on that ticket also point out that in sage there
doesn'
See
http://trac.cython.org/cython_trac/ticket/561#comment:2
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-d
On Apr 29, 7:35 am, David Kirkby wrote:
> The fact there are functions in Sage untested is worrying,
Indeed, it would be nice if all code in Sage would be covered by
tests. Having doctests for very many functions probably correlates
with that, so it probably helps to aim for it. However, doctests
On May 3, 4:47 am, Keshav Kini wrote:
> If such conditions exist (necessitating the calling of the parent
> initializer at the end of the child initializer rather than at the
> beginning) then the parent types are pretty clearly "abstract base
> classes", in OOP terminology -- i.e. classes which c
Both GMP and MPIR documentation complain about gcc-4.3.2, but I
haven't seen an explicit code snippet that triggers faulty behaviour.
Closest I found was this:
http://trac.mpir.org/mpir_trac/ticket/291
which indicates that at least something in "rootrem.c" goes wrong. I'd
assume the testsuites of
On May 10, 4:19 pm, Keshav Kini wrote:
> It seems like a reasonable feature request (or bug fix if you want to
> call it that) to me. I made a ticket on the bug tracker - it's up
> athttp://trac.sagemath.org/sage_trac/ticket/12939. If someone does come
> up with a reason why this is a bad idea, w
On May 11, 12:16 am, Simon King wrote:
> IIRC, the canonical answer to the request "do not predefine x" is:
> "That's not gonna happen, because way too many people expect to have a
> variable x handy."
Or perhaps:
"If you don't like x predefined, then put the command 'del x' in .sage/
init.sage"
On May 11, 1:14 am, John Cremona wrote:
> I would be
> interested to see how many doctests fail if the automattice
> predefinition iof x is turned off. How might that be done?
sage/all_cmdline.py
sage/all_notebook.py
both contain the line:
from sage.calculus.predefined import x
I'd expect
On May 11, 6:17 am, kcrisman wrote:
> There should be at least one thing that a user who has never heard of
> "variables" in computers can do without var or actually defining a
> function.
>
> sage: f(x) = x
> sage: plot(f) # works but two liner to plot even the simplest non-
> constant function
On May 11, 10:29 am, kcrisman wrote:
>> sage: _(y)=y
> I thought underscore only worked to give the previous command, but I
> guess the preparser makes this work right.
No, as far as I can tell, _ is an ordinary variable for python. It's
just that the toplevel assigns the latest return value to
On May 11, 12:37 am, Julien Puydt wrote:
> NameError: name 'y' is not defined -- perhaps you need to type var('y')
> first ?
A nice idea, but I don't think NameError is sufficiently aware of the
context it is raised in to make reliable suggestions:
sage: sinus(pi/3)
NameError: name 'sinus' is n
On May 11, 12:31 pm, Robert Bradshaw
wrote:
> One can write SR("a*x+b") and it defines the
> variables for you (though not globally IIRC).
Thanks! That is very good to know. So SR has its own parser! It even
works for SR("f(t)"). It doesn't do the expected thing for
SR("diff(sin(x),x)"), though,
On May 14, 3:14 am, "Nicolas M. Thiery"
wrote:
> > - Contributing to Sage;
I noticed some minor typos, but in
http://combinat.sagemath.org/doc/thematic_tutorials/tutorial-editing-sage-sources.html#a-real-modification
there's a serious one (Section 4): It still has the wrong editing
command the
On May 16, 1:08 am, Keshav Kini wrote:
[...]
> What I am proposing (and I guess it's similar to what Robert was
> saying):
>
> The package named foo consists of some files and directories created by
> Sage developers, and some files created by upstream developers. The
> files and directories creat
How much work would it be to change PARI/GP so that the GP compiler is
accessible via a PARI library call? Then it would be possible to mix
libpari use with gp script snippets and avoid pexpect-ing GP entirely.
I don't know how much havoc gp-programs designed to run alone would
wreak on PARI's glob
I understand that the notebook server is in the process of being
redesigned. I have one idea that would make notebook server security
easier to explain to sysadmins:
* Make a notebook server virtual machine (I guess "appliance") where
the notebook users have a 1-1 correspondence with the Unix Use
On Jan 18, 1:20 am, Simon King wrote:
> On the other hand, eventually we will have Python 3.*, and thus why
> should I not get used to write int(i/j) instead of i/j, for `int`s i
> and j?
Because it can give the wrong answer :-). In Python 3:
>>> int(10**40/10**10)
1198846248386
On Jan 28, 4:16 pm, Robert Miller wrote:
> I don't have time to track this down at the moment, but as it is a bit
> embarrassing I thought I'd report it here for now:
>
> sage: R. = QQ[]
> sage: E = EllipticCurve([0,0,0,-595*d^2,5586*d^3])
> sage: E.discriminant().factor()
> (1404928) * d^6
What
On Feb 8, 8:02 pm, William Stein almost wrote:
> Some relevant information is that our Spring Break is March 21-25, 2011.
Unfortunately I'm not around.
Another possible topic (but probably for a different meeting):
- moving the calculus use of maxima to a library interface.
If you'd get the righ
On Feb 11, 9:56 am, Simon King wrote:
> Why an exception? If the elements are in a field that is not the
> fraction field of a PID, it is totally fine that gcd(a,b) returns 0 if
> one of a,b is zero, and returns 1 otherwise.
>
> I hope the whole discussion is not "painting a bike shed"...
I'd sa
On Feb 21, 10:31 am, Robert Bradshaw
wrote:
> k[x,y], k[x,z], k[y,z] all coerce to k[x,y,z], but there some overhead
> due to the extra object creation (assuming one needed to coerce back
> into the larger ring). This, and creation of the new ring, is probably
> still pretty cheap.
The problem I
When I saw the following, initially I thought the preparser was
providing a very convenient feature:
sage: f(t)=sin(t)
sage: f
t |--> sin(t)
sage: parent(t)
Symbolic Ring
but recently I noticed on a trac ticket:
sage: R.=QQ[]
sage: phi(x)=x^2+c
Which causes:
sage: parent(x)
S
> > Do you have the same objections to:
> > R.=QQ[]?
No, but that is because I am used to magma. Perhaps also because the
notation contrasts with R = QQ["x","y"]. The fact that the variable
names only occur on the left side (and in fact in a place where they
should not in mathematics!) suggests th
Hm, thinking about how to parse the SR.var("x") properly, it seems a
rather odd symbolic object gets created by
sage: v=SR.var('x,')[1]
sage: x+v
+ x
sage integral(x+v,x)
*BOOM*
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email
On Feb 23, 12:50 pm, Robert Bradshaw
wrote:
> Escaping is nice when one wants to take a derivative, etc. I don't
> think most calculus students think about "scope" being local or not,
> and relying on the symbol not being re-defined seems like it would
> make for fragile and harder to follow code
On Feb 24, 8:52 pm, Robert Miller wrote:
> I'm working on wrapping a C package in Cython for use in Sage, and I'm
> having some trouble. I think the problem has to do with the fact that
> the C program uses stderr to report issues. When the program exits, I
> get the following message:
>
> SystemE
On Feb 25, 10:52 pm, William Stein wrote:
> > 2) Pay for advertising Sage in maths journals, New Scientist, or if
> > deemed appropriate, anywhere where the 4 M's are advertised.
>
> b) Is 2) something that will annoy anybody reading this? I could see
> somebody being annoyed that valuable Sage m
In an unexpected flurry of activity, thanks to JP, the maxima library
interface has developed surprisingly well. There is a whole stack of
patches and dependencies on http://trac.sagemath.org/sage_trac/ticket/7377
which enables the use of maxima as a library for calculus purposes.
Built on 4.6.2.al
On Feb 27, 1:30 pm, rjf wrote:
> That's great. I was concerned that stdio was getting lost in the
> shuffle.
Actually, presently we have a
(setf *standard-output* (make-broadcast-stream))
i.e., effectively a global redirect to /dev/null, because maxima has
quite a bit of output that is impossibl
On Mar 2, 8:23 am, Owen Densmore wrote:
> Preparing for a computer graphics class, I came across a new-to-me
> math package:http://www.mathjax.org/
> It looks pretty well supported. Have the sage developers looked at it?
Yes: http://trac.sagemath.org/sage_trac/ticket/9774
--
To post to this gro
On Mar 2, 10:36 pm, Simon King wrote:
> Is there a standard Python function ("is_identifier" or so) that tests
> whether a string in whatever encoding is an identifier?
A possibly somewhat heavyhanded approach:
sage: import tokenize,StringIO
sage: S="QQ['t'], a, a_2, for"
sage: list((a[0],a[1])
On Mar 13, 4:34 pm, Julien PUYDT wrote:
> Hi,
>
> among the few failing tests with my ARM built, two are because of
> accuracy reasons :
>
> File "/home/jpuydt/sage-4.6.2/devel/sage/sage/functions/other.py", line 497:
> sage: gamma1(float(6))
> Expected:
> 120.0
> Got:
> 119.999
Hi Simon,
I looked over the comments in trac #5 . Thank you for a very
thorough analysis and presentation. One thing I didn't immediately
find in the discussion there is that an increased memory footprint for
elements can also cause cache-misses sooner, so lead to a slowdown (so
memory usage c
On Apr 30, 1:51 pm, Simon King wrote:
> I don't understand that. Can you elaborate? Perhaps on the ticket?
I did, and I included some striking timings. The final effect for sage
elements will be much smaller because there are so many other factors,
but the timings do show that not having the data
Does anybody know the current state-of-the-art in sage to compute with
finitely generated Z-modules (i.e., finitely generated abelian
groups)? The operations I would be looking for are
- sums, intersections and quotients of/by submodules
- homomorphisms between Z-modules
- computing kernel and i
g they are not
fixing any shortcomings of fgp_modules in that respect?
Nils
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google
201 - 300 of 1748 matches
Mail list logo
