Hi Dima,
On Mon, Feb 22, 2010 at 6:44 PM, Dima Pasechnik wrote:
> As it stands, updated optional spkgs for the new release are nowhere
> to be found
> (e.g. gap_packages and database_gap)
Can you find what you're looking for at this place?
http://www.sagemath.org/packages/optional/
> Shouldn'
As it stands, updated optional spkgs for the new release are nowhere
to be found
(e.g. gap_packages and database_gap)
Shouldn't
http://sage.math.washington.edu/home/release/sage-4.3.3/sage-4.3.3/spkg/
also contain optional packages that were upgraded?
Or these packages can be put directly to sage
On t2, can we please follow he Skynet's /usr/local/skynet_bash_profile
mechanism to have a ready setup for building sage there?
It would also be nice to have chsh working, so that ppl can change the
default shell...
Thanks,
Dima
On Feb 21, 4:51 pm, Minh Nguyen wrote:
> Hi Alex,
>
> On Sun, Feb
On Feb 22, 4:15 am, "Dr. David Kirkby"
wrote:
[...]
> I think once again, it shows that gcc's C, C++ and Fortran libraries should
> all
> be included with Sage. Otherwise, the build relies on the end user having a
> similar setup. This is not specific to Solaris, but one can probably get away
>
Hi folks,
I have written a script [1] to automate most of the task of updating
the online and downloadable documentation on the Sage website. With
the release of Sage 4.3.3, I test ran the script for the first time.
It would be good if people could give feedbacks on broken links or
other ways this
Hi folks,
Sage 4.3.3 was released on February 21, 2010. It is available at
http://www.sagemath.org/download.html
* About Sage (http://www.sagemath.org)
Sage is developed by volunteers and combines over 90 open source packages.
It is available for download from www.sagemath.org and it
Currently mod and Mod are the same function. I think that this should
remain true, if only for backward compatibility.
There seem to be plenty of ways to construct elements of Z/nZ quickly. I
would say that the only thing in question is what the behavior of a.mod(b)
should be: the same as the gl
On 21 February 2010 22:22, David Roe wrote:
> I think that the reason for having mod behave the way it does is that the
> percent operator is defined by __mod__.
>
> Personally, I have no strong preference as to whether a.mod(b) behaves like
> a % b (ie a.__mod__(b)) or like mod(a, b).
> David
Pe
Minh Nguyen wrote:
Hi David,
On Sun, Feb 21, 2010 at 6:18 AM, Dr. David Kirkby
wrote:
It would be good if someone could review
http://trac.sagemath.org/sage_trac/ticket/8191
and some other changes necessary to R's spkg-install
http://trac.sagemath.org/sage_trac/ticket/8285
A few hours
I think that the reason for having mod behave the way it does is that the
percent operator is defined by __mod__.
Personally, I have no strong preference as to whether a.mod(b) behaves like
a % b (ie a.__mod__(b)) or like mod(a, b).
David
On Sun, Feb 21, 2010 at 4:08 PM, slabbe wrote:
>
> > > I
On Sat, 20 Feb 2010 13:13:09 -0800
Robert Bradshaw wrote:
> On Feb 20, 2010, at 12:40 PM, John H Palmieri wrote:
> >
> > I was curious about this, so I tried specifying the number of
> > digits:
> >
> > sage: h = integral(sin(x)/x^2, (x, 1, pi/2)); h
> > integrate(sin(x)/x^2, x, 1, 1/2*pi)
> > sa
On Sunday, February 21, 2010, Minh Nguyen wrote:
> On Mon, Feb 22, 2010 at 7:55 AM, Minh Nguyen wrote:
>
>
>
>> It's mostly due to the new Moin Moin spkg at ticket #3693:
>>
>> [mv...@sage sage-src]$ du -hs sage-4.3.2/spkg/standard/moin-1.5.7.p3.spkg
>> 3.7M sage-4.3.2/spkg/standard/moin-1.5.
> > Is the following the intended behaviour?
>
> > sage: type(15.mod(4))
> >
> > sage: type(mod(15, 4).lift())
> >
> > sage: 15.mod(4) == 7
> > False
> > sage: mod(15, 4).lift() == 7
> > False
Sorry, I should have said what was the intended behavior. We were
expecting mod to behave the same whe
On Mon, Feb 22, 2010 at 7:55 AM, Minh Nguyen wrote:
> It's mostly due to the new Moin Moin spkg at ticket #3693:
>
> [mv...@sage sage-src]$ du -hs sage-4.3.2/spkg/standard/moin-1.5.7.p3.spkg
> 3.7M sage-4.3.2/spkg/standard/moin-1.5.7.p3.spkg
> [mv...@sage sage-src]$ du -hs
> sage-4.3.3.alpha
Hi William,
On Mon, Feb 22, 2010 at 7:12 AM, William Stein wrote:
> Anyway,
>
>http://trac.sagemath.org/sage_trac/ticket/8314
>
> has to get merged in before we can release 4.3.3, since we can't
> release with test failures on Ubuntu 32.
Noted.
> So can you swap out sagenb-0.7.5 for sag
The addition of
http://trac.sagemath.org/sage_trac/ticket/6583 (implement 2-isogeny descent over
QQ natively in Sage using ratpoints)
sage-4.3.1 broke the build of Sage on Solaris. I suspect this was the ticket,
but Minh had proved this some time back, after starting with Sage 4.3, he added
On Feb 21, 8:06 pm, Mike Hansen wrote:
> Hello,
>
> On Sun, Feb 21, 2010 at 12:03 PM, bsdz wrote:
> > I used to be able to obtain a function name in Sage 3+ using something
> > like the following: -
>
> > fu = function('fu', x)
> > print fu._f._name
> > # would print "fu"
>
> > I notice that this
Alex Ghitza wrote:
On Sun, 21 Feb 2010 19:51:34 +1100, Minh Nguyen wrote:
Hi Alex,
Did you get a message like this when you do "./sage"?
[snippety snip]
ImportError: ld.so.1: python: fatal: relocation error: file
/scratch/mvngu/sage-4.3.0.1/local/lib//libgmpxx.so.3: symbol
_ZNKSt5ctypeIcE1
On Sun, Feb 21, 2010 at 4:27 AM, Minh Nguyen wrote:
> Hi William,
>
> On Sun, Feb 21, 2010 at 3:09 AM, William Stein wrote:
>
>
>
>> I hope 4.3.3 can be out... tomorrow.
>
> This is not an official announcement. The Sage 4.3.3 source tarball is
> done and available under
>
> http://sage.math.was
Hello,
On Sun, Feb 21, 2010 at 12:03 PM, bsdz wrote:
> I used to be able to obtain a function name in Sage 3+ using something
> like the following: -
>
> fu = function('fu', x)
> print fu._f._name
> # would print "fu"
>
> I notice that this does not work in Sage 4 and "fu" is no longer a
> Symbol
Hi
I used to be able to obtain a function name in Sage 3+ using something
like the following: -
fu = function('fu', x)
print fu._f._name
# would print "fu"
I notice that this does not work in Sage 4 and "fu" is no longer a
SymbolicFunctionEvaluation but an Expression.
Is there a way to obtain t
More generally, The % operator tends to return the "remainder" term, in the
same ring. mod(a, b) constructs an element of the quotient ring. So, the
behavior you're observing is intended, though perhaps a bit unexpected.
David
On Sun, Feb 21, 2010 at 11:32 AM, John Cremona wrote:
> On 21 Februa
If you're calling the functions from cython code, and your variables are
cdef'd properly (so that the cython compiler knows the type of the object),
and the function you're calling is cdef'd, it will use C function calls and
you can pass in C types.
David
On Sat, Feb 20, 2010 at 7:46 AM, Nathann C
On 21 February 2010 16:05, Minh Nguyen wrote:
> On Mon, Feb 22, 2010 at 3:01 AM, slabbe wrote:
>
>
>
>> sage: 15.mod(4) == 7
>> False
>> sage: mod(15, 4) == 7
>> True
>
> Is the following the intended behaviour?
>
> sage: type(15.mod(4))
>
> sage: type(mod(15, 4).lift())
>
> sage: 15.mod(4) ==
On Mon, Feb 22, 2010 at 3:01 AM, slabbe wrote:
> sage: 15.mod(4) == 7
> False
> sage: mod(15, 4) == 7
> True
Is the following the intended behaviour?
sage: type(15.mod(4))
sage: type(mod(15, 4).lift())
sage: 15.mod(4) == 7
False
sage: mod(15, 4).lift() == 7
False
--
Regards
Minh Van Nguye
> > AFAIK, the "_import" module is built by the PIL spkg. Try reinstalling
> > it, eventually you have to issue "export SAGE_BINARY_BUILD=yes"
> > before, in order to make PIL build sanely (I have to do that every
> > time on my production machine).
>
> I tried reinstalling it, running this export
Dear sage-devel,
We just came up with the following behavior : mod(m,n) and m.mod(n)
behave differently :
sage: type(15%4)
sage: type(15.mod(4))
sage: type(mod(15,4))
which leads to
sage: 15.mod(4) == 7
False
sage: mod(15, 4) == 7
True
Sébastien (with Franco and Florent)
--
To post to thi
On Sun, 21 Feb 2010 19:51:34 +1100, Minh Nguyen wrote:
> Hi Alex,
>
>
> Did you get a message like this when you do "./sage"?
>
[snippety snip]
>
> ImportError: ld.so.1: python: fatal: relocation error: file
> /scratch/mvngu/sage-4.3.0.1/local/lib//libgmpxx.so.3: symbol
> _ZNKSt5ctypeIcE13_M_w
> At UW the grants system is called SAGE = "System for Administering
> Grants electronically" and when I teach a Sage course, I will
> occasionally have financial secretaries at UW contact me about taking
> the class :-).
Meanwhile, at another UW: yesterday I bought some tickets through the
Unive
Hi William,
On Sun, Feb 21, 2010 at 3:09 AM, William Stein wrote:
> I hope 4.3.3 can be out... tomorrow.
This is not an official announcement. The Sage 4.3.3 source tarball is
done and available under
http://sage.math.washington.edu/home/release/sage-4.3.3/
It is essentially the same as Sag
Dear sage-devels,
I have made an SPKG from Paul Zimmermann's C implementation of the PSLQ
algorithm for finding integer relations. I also made a first attempt at
creating an interface for easily using this from Sage. See
http://trac.sagemath.org/sage_trac/ticket/853
for spkg and patch. This
On Fri, Feb 19, 2010 at 04:09:58PM -0800, Mike Hansen wrote:
> You can do ReST (Sphinx) > HTML > Notebook with the code in
> sage/server/notebook/docHTMLProcessor.py (and/or the equivalent in
> sagenb).
Excellent, thanks!
Can you even just imagine that I had never noticed that one could
browse th
Minh Nguyen wrote:
Hi David,
On Sun, Feb 21, 2010 at 4:20 PM, Dr David Kirkby wrote:
I believe you have put the wrong ticket number there, as 7484 is
"update README.txt to require Fortran as a pre-requisite for compiling
Sage on Linux" and does not appear to be related to SAGE_CHECK at
all.
> I'm not suggesting it is a gold standard, but given the results agreed
> reasonably closely with Sage, and were computed to arbitrary precision, then
> I had a reasonable degree of confidence in believing the "failure" was not
> really a failure at all.
>
Thank you for your very clear explanati
Hi Alex,
On Sun, Feb 21, 2010 at 4:16 PM, Alex Ghitza wrote:
> I could not use the binary
> posted by Minh
Did you get a message like this when you do "./sage"?
mv...@t2 sage-4.3.0.1]$ ./sage
--
| Sage Version 4.3.0.1, Relea
I think the conversion of LaTeX to single worksheets is ready for
testing. You'll need tex, tex4ht and sagetex at a minimum, with sage
installed locally. Most of what you need to know is at the wiki page:
http://wiki.sagemath.org/devel/LatexToWorksheet
Download the "Approximating Polynomial Wor
Hi David,
On Sun, Feb 21, 2010 at 4:20 PM, Dr David Kirkby wrote:
> I believe you have put the wrong ticket number there, as 7484 is
> "update README.txt to require Fortran as a pre-requisite for compiling
> Sage on Linux" and does not appear to be related to SAGE_CHECK at
> all.
The updated
37 matches
Mail list logo
