Hi David,
On Thu, Sep 24, 2009 at 4:39 PM, Dr. David Kirkby
wrote:
> Is there anyone else who agrees or disagrees with putting messages to
> encourage those trying Sage on other OS's?
I strongly agree. Ideally Sage should run on FreeBSD, Solaris (SPARC
and x86), and other exotic systems. Not
On Wed, Sep 23, 2009 at 10:11 AM, Francois Maltey wrote:
>
> Hi,
>
> I'm testing sage, the expressions and I play with expr.expand().
>
> After test = 3*x, I find test.expand? and get the help text, and
> test.expand?? and the main call about expand.
>
> Then emacs goes to expression.pyx at the l
On Wed, Sep 23, 2009 at 11:39 PM, Dr. David Kirkby
wrote:
>
> Jason Grout wrote:
>> Dr. David Kirkby wrote:
>>
>>> 2) You are attempting to build Sage on HP-UX. While there are no plans
>>> to support HP-UX, if you want to port Sage to HP-UX, the Sage community
>>> would appreciate that, and give
Jason Grout wrote:
> Dr. David Kirkby wrote:
>
>> 2) You are attempting to build Sage on HP-UX. While there are no plans
>> to support HP-UX, if you want to port Sage to HP-UX, the Sage community
>> would appreciate that, and give you what support they can. Any patches
>> you are able to submi
On Wed, Sep 23, 2009 at 11:14 PM, Rado wrote:
>
> I am not sure if I get a vote, but I wanted to say my opinion as more
> of a Sage user than developer.
>
> Since n() is type conversion of sorts, I would expect it to behave
> similar to python's int() function. Which means just give error if you
I am not sure if I get a vote, but I wanted to say my opinion as more
of a Sage user than developer.
Since n() is type conversion of sorts, I would expect it to behave
similar to python's int() function. Which means just give error if you
pass it a list (to remind you to use map). "explicit is be
Hi!
On 23 Sep., 11:07, mmarco wrote:
> I have to do some computations in an exterior algebra, and i have seen
> that it is not yet implemented in sage, but there is some work in that
> direction. My question is: will this feature be implemented in sage
> 4.1.2? If so, how complete will it be?.
>>> The question is, do we want this case to also raise an error, or the
>>> function n() to iterate over the argument when it's iterable?
>>
>> Why is there list comprehension in Python? I am "-1" concerning
>> iteration over the argument.
>
> Would it be pythonic enough to have n(pi/2,pi,2*pi) r
On Wed, Sep 23, 2009 at 8:20 PM, Jason Grout
wrote:
>
> Nils Bruin wrote:
>> On Sep 8, 3:38 am, Jason Grout wrote:
>>> Would it be pythonic enough to have n(pi/2,pi,2*pi) return a list of
>>> three values? That way we could do:
>>>
>>> n(*my_list)
>>>
>>> Note that min, max, and other functions
>> I would go so far as to recommend
>> that we auto-email the logs each day to sage-devel.
>> Note that typically less than 20 people are logged into #sage-devel at
>> any time, and there is no posted log, so the people that benefit from
>> #sage-devel are about 2% of the subscribers to the sage-
Nils Bruin wrote:
> On Sep 8, 3:38 am, Jason Grout wrote:
>> Would it be pythonic enough to have n(pi/2,pi,2*pi) return a list of
>> three values? That way we could do:
>>
>> n(*my_list)
>>
>> Note that min, max, and other functions work something like this, in
>> that they accept a variable num
On Sep 22, 2009, at 8:51 AM, Jason Grout wrote:
> Tim Joseph Dumol wrote:
>> Sorry, I mean't we *can't* use it without a bit of modification.
>
>
> A google search for "rietveld mercurial" shows lots of work on this
> problem.
Very cool.
As mentioned, I used this system all summer, and it is
On Sep 23, 2009, at 7:57 PM, Nils Bruin wrote:
> On Sep 8, 3:38 am, Jason Grout wrote:
>> Would it be pythonic enough to have n(pi/2,pi,2*pi) return a list of
>> three values? That way we could do:
>>
>> n(*my_list)
>>
>> Note that min, max, and other functions work something like this, in
>> t
On Sep 8, 3:38 am, Jason Grout wrote:
> Would it be pythonic enough to have n(pi/2,pi,2*pi) return a list of
> three values? That way we could do:
>
> n(*my_list)
>
> Note that min, max, and other functions work something like this, in
> that they accept a variable number of arguments.
They do,
I have mixed feelings but in general I think it would be good to log.
Knowing that it is logged will affect how I interact with it - I would
say fewer personal things - but I have learned a huge amount from
#sage-devel and it could be of great use to other people.
So, overall, +1 to a formal log.
I think it would be great if n() and other functions mapped to a
list. I don't see the downside, but maybe I am missing something.
-Marshall
On Sep 8, 5:38 am, Jason Grout wrote:
> Simon King wrote:
> > Hi Burcin,
>
> > On Sep 8, 11:21 am, Burcin Erocal wrote:
> >> I would call it a bug, a si
Robert Bradshaw wrote:
>>
>> What i do understand is that for example elements in QQBar should be
>> represented by symbols (sqrt(2) instead of a numerical value 1,... or
>> pi instead of 3.14... ).
>
> The problem is that most elements of QQBar can't be represented this
> way, and even if t
If you want to look at possible definitions of solve that have been
refined more recently than Maxima's solve, you can look at
Mathematica's
Solve, NSolve, RSolve, Reduce, and maybe some others like Eliminate.
Maxima's solve dates to 1971, but there is also linsolve, algsys,
realroots, and some o
On Sep 22, 2009, at 3:20 PM, x x wrote:
> Hi Burcin,
>
> Thanks for the explanation!
>
>> "Symbolic ring" is an unfortunate name. It doesn't mean much from the
>> "mathematical point of view." It's just where all the symbolic stuff
>> live in Sage. Maybe we should call it symbolic parent.
>
> I a
Hi Simon,
On Wed, Sep 23, 2009 at 10:01 PM, Simon King wrote:
> If Frank allows, I will post his example on ticket #7001, and probably
> the ticket should be closed afterwards, labeled "reported upstream"
> and marked "invalid". Or what is the usual procedure?
That is the usual procedure for
On Sep 23, 2009, at 2:24 PM, William Stein wrote:
>
> On Wed, Sep 23, 2009 at 2:20 PM, Rob Beezer
> wrote:
>>
>> +/- 0 to logging. I can argue both sides.
>>
>> On the one hand, I know I have seen things on #sage-devel that I
>> think
>> would be better off not being posted and indexed - in
Hi Jaap,
On Thu, Sep 24, 2009 at 2:43 AM, Jaap Spies wrote:
> I had the same failures on Fedora 11, 32 bit
Felix Lawrence has uploaded a patch at ticket #6999 [1] to fix the 32-
versus 64-bit issues caused by these doctests:
sage -t -long "devel/sage/sage/interfaces/expect.py"
sage -t -long
2009/9/22 William Stein :
>
> Hi,
>
> I was able to create a limited functionality separated sage notebook so far:
>
> http://sage.math.washington.edu/home/wstein/patches/sagenb/
>
> One key thing I did was abstract out how the worksheets communicate
> with another python process. I then did a r
On Wed, Sep 23, 2009 at 4:41 AM, Prabhu Ramachandran
wrote:
> Thanks Fernando. The speed issue is still true but I wouldn't blame
> traits since that isn't the source of the bottleneck. I think there are
> a little too many events and too many renders. I have not had the time
> to profile it car
On Sep 8, 2009, at 3:38 AM, Jason Grout wrote:
> Simon King wrote:
>> Hi Burcin,
>>
>> On Sep 8, 11:21 am, Burcin Erocal wrote:
>>> I would call it a bug, a side effect of trying to convert the
>>> argument
>>> to a complex number as a last resort.
>>
>> No, it is documented, at least implicit
Hi,
I just released FEMhub 0.9.7.
web page: http://femhub.org/
Our mission: To create an open-source distribution featuring many
finite element codes, along with a web notebook and a unified Python
interface. We want FEMhub to become an alternative to commercial FEM
codes.
Source + binaries ar
On Wed, Sep 23, 2009 at 2:33 PM, Rob Beezer wrote:
>
> On Sep 23, 2:24 pm, William Stein wrote:
>> For the Sage project I think it would *best* if we changed our
>> behavior on #sage-devel and make the #sage-devel logs public and
>> searchable. The benefit to the project overall is that less g
William Stein wrote:
> On Wed, Sep 23, 2009 at 10:31 AM, John H Palmieri
> wrote:
>> On Sep 23, 6:27 am, Dan Drake wrote:
>>> On Wed, 23 Sep 2009 at 01:55PM +0100, Dr. David Kirkby wrote:
I will need to build Sage again on 't2' and let you know what it gives
on that, as it may be 2, 16
On Sep 23, 2:24 pm, William Stein wrote:
> For the Sage project I think it would *best* if we changed our
> behavior on #sage-devel and make the #sage-devel logs public and
> searchable. The benefit to the project overall is that less gets
> discussed "in secret", process -- such as release man
On Wed, Sep 23, 2009 at 2:20 PM, Rob Beezer wrote:
>
> +/- 0 to logging. I can argue both sides.
>
> On the one hand, I know I have seen things on #sage-devel that I think
> would be better off not being posted and indexed - in particular, a
> flamer and a naive-sage-support-poster being critiqu
On Wed, Sep 23, 2009 at 2:18 PM, William Stein wrote:
> On Wed, Sep 23, 2009 at 1:44 PM, Harald Schilly
> wrote:
>>
>> On Sep 23, 10:23 pm, Tim Joseph Dumol wrote:
>>> #sagemath...
>>
>> about that channel, i registered it because it seems to be a good fit
>> in the name with sagemath.org and s
+/- 0 to logging. I can argue both sides.
On the one hand, I know I have seen things on #sage-devel that I think
would be better off not being posted and indexed - in particular, a
flamer and a naive-sage-support-poster being critiqued. Nothing
necessarily wrong with that, mostly folks blowing
On Wed, Sep 23, 2009 at 1:44 PM, Harald Schilly
wrote:
>
> On Sep 23, 10:23 pm, Tim Joseph Dumol wrote:
>> #sagemath...
>
> about that channel, i registered it because it seems to be a good fit
> in the name with sagemath.org and similar. some are OPs (i.e. it is a
> moderated channel) there and
On Sep 23, 10:23 pm, Tim Joseph Dumol wrote:
> #sagemath...
about that channel, i registered it because it seems to be a good fit
in the name with sagemath.org and similar. some are OPs (i.e. it is a
moderated channel) there and we should discuss to make this the
official channel. i think it's b
04:11 < timdumol> wstein-3852: Oh, I've been looking through the sagenb
code, and I noticed that WorksheetProcess is an old-style object (doesn't
inherity from
object). Also, `misc/sageinspect.py` has been patched in
4.1.2.alpha2, and the changes are not yet reflected in the one y
William Stein wrote:
> On Wed, Sep 23, 2009 at 12:35 PM, kcrisman wrote:
>>> There are privacy issues at play here -- I would like some debate
>>> about this before we go ahead. Personally, I think #sage-devel should
>>> be logged, because it's a development channel, but there is a great
>>> dea
+1 for logging.
Any flames, we can use #sagemath, or a new channel for.
I would love to have at least see yesterday's logs posted. I saw a bit of
it, but I forgot to save my logs.
On Thu, Sep 24, 2009 at 4:14 AM, William Stein wrote:
>
> On Wed, Sep 23, 2009 at 12:35 PM, kcrisman wrote:
> >
>
Fernando Perez wrote:
> On Tue, Sep 22, 2009 at 11:14 AM, kstueve wrote:
>> An example of the desired functionality is to either with a few lines
>> of code from within a Sage worksheet, or by clicking buttons in a
>> graphical user interface (GUI) create a physics problem with
>> components such
On Wed, Sep 23, 2009 at 12:35 PM, kcrisman wrote:
>
>> There are privacy issues at play here -- I would like some debate
>> about this before we go ahead. Personally, I think #sage-devel should
>> be logged, because it's a development channel, but there is a great
>> deal of personal information
Hi,
A first version -- without any documentation! -- of units is now up at
http://trac.sagemath.org/sage_trac/ticket/3852
It's installed on http://alpha.sagenb.org.
sage: units.
sage: unis.mass.
sage: units.mass.gram?
<>
sage: s = 13 * var('a') * units.mass.gram/units.area.barn^2; s
13*a*gr
> There are privacy issues at play here -- I would like some debate
> about this before we go ahead. Personally, I think #sage-devel should
> be logged, because it's a development channel, but there is a great
> deal of personal information exchanged in that venue.
-1. At least for me, I
On Wed, Sep 23, 2009 at 10:31 AM, John H Palmieri
wrote:
>
> On Sep 23, 6:27 am, Dan Drake wrote:
>> On Wed, 23 Sep 2009 at 01:55PM +0100, Dr. David Kirkby wrote:
>> > I will need to build Sage again on 't2' and let you know what it gives
>> > on that, as it may be 2, 16 or 128!
>>
>> I download
Hi,
I am curious if anybody can go to the Educause 2009 conference in
Denver,CO. Sun was really hoping there could be some Sage
representation, and I can't go. See below if you're interested.
William
-- Forwarded message --
From: Corinne Cho-Beaulieu
Date: Wed, Sep 23, 2009
On Mon, Sep 21, 2009 at 12:20 PM, Ondrej Certik wrote:
> Hi,
>
> I passed my PhD comps! so I started to work on the femhub windows port
> (cygwin) and it's *almost* there. Lots of packages need to be fixed,
> we worked on that with William and Dan Drake yesterday, so
>
> gpg et. al
> numpy
> matp
On Sep 23, 6:27 am, Dan Drake wrote:
> On Wed, 23 Sep 2009 at 01:55PM +0100, Dr. David Kirkby wrote:
> > I will need to build Sage again on 't2' and let you know what it gives
> > on that, as it may be 2, 16 or 128!
>
> I downloaded Python 2.6.2 to 't2', built it, and ran
> multiprocessing.cpu_co
Hi,
I'm testing sage, the expressions and I play with expr.expand().
After test = 3*x, I find test.expand? and get the help text, and
test.expand?? and the main call about expand.
Then emacs goes to expression.pyx at the lines defining the interface
(outer) function expand.
In this code I fi
On 23-Sep-09, at 9:40 AM, William Stein wrote:
>
> On Wed, Sep 23, 2009 at 3:14 AM, Tim Dumol wrote:
>>
>> Are there any IRC logs up for #sage-devel? If there isn't, then
>> perhaps we can have a bot (http://www.eggheads.org/) do logging
>> automatically, and have them automatically posted onli
> This seems to give reasonable numbers for my iMac, an ubuntu box I
> sometimes use, and sage.math. Does it give bad numbers for your
> computer?
sage: import multiprocessing
sage: multiprocessing.cpu_count()
2
sage: !uname -a
Darwin pv139204.reshsg.uci.edu 9.7.0 Darwin Kernel Version 9.7.0: Tu
Jaap Spies wrote:
> Minh Nguyen wrote:
>> Hi folks,
>>
>
> I had the same failures on Fedora 11, 32 bit
>
> Jaap
>
>
In addition I get a message:
--
| Sage Version 4.1.2.alpha2, Release Date: 2009-09-21|
| Ty
Minh Nguyen wrote:
> Hi folks,
>
I had the same failures on Fedora 11, 32 bit
Jaap
> Sage 4.1.2.alpha2 compiles OK on the mandriva32 VM guest on
> boxen.math, i.e. 32-bit Mandriva 2009.0. The following doctests fail:
[...]
>
> ---
On Wed, Sep 23, 2009 at 3:14 AM, Tim Dumol wrote:
>
> Are there any IRC logs up for #sage-devel? If there isn't, then
> perhaps we can have a bot (http://www.eggheads.org/) do logging
> automatically, and have them automatically posted online. It will be
> helpful for people to catch up with any
I got 2 as answer over my core2duo laptop (running over gentoo linux),
which is correct counting the two cores as two processors.
I also got 2 as answer over my atom n270 netbook (running over
ubuntu), which is a single core processor but with hyperthreading. For
multithread computation puroposes,
Dr. David Kirkby wrote:
> 2) You are attempting to build Sage on HP-UX. While there are no plans
> to support HP-UX, if you want to port Sage to HP-UX, the Sage community
> would appreciate that, and give you what support they can. Any patches
> you are able to submit would probably be accepte
Dear mmarco,
as far as i know Burcin and Michael started integrating noncommutative
Singular features
and in particular, graded commutative (e.g. supercommutative and
exterior) algebras into Sage
(http://trac.sagemath.org/sage_trac/ticket/4539).
Luckily there will be another meeting concerning t
On Wed, 23 Sep 2009 at 01:55PM +0100, Dr. David Kirkby wrote:
> I will need to build Sage again on 't2' and let you know what it gives
> on that, as it may be 2, 16 or 128!
I downloaded Python 2.6.2 to 't2', built it, and ran
multiprocessing.cpu_count() -- it returned 128 on that machine.
Dan
-
As far as I know, if one tries to build Sage on Cygwin or Solaris x86,
there will be a warning that it is not support.
If one tried to build Sage on any of the rarer opperating systems, such
as HP-UX, tru64, AIX, SCO, Unicos, NetBSD etc, no such warning would be
issued. Some time ago, I posted
I just built 4.1.2.alpha2 on my Sun Ultra 80. The build still stops at
one point, with a problem in paripriv.h, so I have to comment out 3
lines. But apart from that, it built ok.
This machine does not have Sun Studio anywhere SCons can find it. As
soon as SCons can find SunStudio, so the whol
John H Palmieri wrote:
> The goal of trac #6283 is 'Make it so NUM_THREADS is set intelligently
> instead of idiotically in makefile so doing "make ptest" or "make
> ptestlong" doesn't kill some computer'. Right now, NUM_THREADS (set in
> SAGE_ROOT/makefile) is used for parallel testing if you do
On Sep 12, 3:08 pm, Jason Grout wrote:
> > Which features shall we ask the trac and wiki admins to install?
>
> For a long time, I've wanted a report of all tickets on which I've
> participated (i.e., commented, started, been assigned, posted patches, etc.)
>
> Jason
There is a trac ticket for
William Stein wrote:
> Thanks!!
To sample a bevy of Trac plugins, please visit
http://trac.sagemath.org/sage_trac/ticket/6928#comment:9
Highlights:
* Mercurial repository browser - side-by-side diffs; supports queues.
* Custom notifications - I have not tested these.
* "Blocks" and "Is bloc
Hi!
On Sep 23, 10:43 am, Simon King wrote:
[...]
> Probably I will be able to find the place in the code myself, but it
> might simplify the bug hunt if you can give me a pointer.
>
> The problem is tracked at http://trac.sagemath.org/sage_trac/ticket/7001
It turned out that the bug is in GAP:
On Wednesday 23 September 2009 07:20 AM, Fernando Perez wrote:
>> https://svn.enthought.com/enthought/wiki/TVTKIntroduction#visual
>>
>> I've used vpython too, and I thought it was really nice and simple.
>
> Prabhu may comment with more information, but in the meantime, it's
> worth keeping in m
Error building lapack on Arch Linux x86_64.
Log:
[timdu...@tim-pc sage-bin]$ sudo !!
sudo make
cd spkg && ./install all 2>&1 | tee -a ../install.log
make[1]: Entering directory `/opt/sage-bin/spkg'
standard/deps:406: warning: overriding commands for target `installed/'
standard/deps:188: warning:
We are pleased to announce the release of FLINT 1.5, available at
http://www.flintlib.org/
This release contains a number of new functions and a number of very
critical bug fixes.
IMPORTANT NOTE: the interface to the fmpz_multi_mod_ui,
fmpz_multi_CRT_ui and fmpz_multi_CRT_unsigned_ui functions h
Are there any IRC logs up for #sage-devel? If there isn't, then
perhaps we can have a bot (http://www.eggheads.org/) do logging
automatically, and have them automatically posted online. It will be
helpful for people to catch up with any discussion made in IRC.
--~--~-~--~~~
I got the right answer (counting different cores of the same processor
as different processors) in all the computers i have checked (with
different number of processors and different flavours of linux). All
of them are x86 or amd64 architecture. Still have to check how does it
work with atom proce
Dear sage-devel,
can you please point me to the place in the gap interface code where
errors are caught?
Namely, it seems to me that it is forgotten to quit GAP's break loop
before continuing.
Example:
sage: def bugtrigger(n):
: a = gap(1)
: for i in range(n):
:
I have to do some computations in an exterior algebra, and i have seen
that it is not yet implemented in sage, but there is some work in that
direction. My question is: will this feature be implemented in sage
4.1.2? If so, how complete will it be?. If no, any idea about when it
will be?
I have c
On Tue, Sep 22, 2009 at 7:01 PM, Minh Nguyen wrote:
>sage -t -long "devel/sage/sage/interfaces/gp.py"
>sage -t -long "devel/sage/sage/interfaces/expect.py"
Ticket #6999 [1] contains a patch to fix these two doctest failures on
32-bit platforms.
[1] http://trac.sagemath.org/sa
On Tue, Sep 22, 2009 at 2:07 PM, Minh Nguyen wrote:
>sage -t -long "-4.1.2.alpha2/devel/sage/sage/interfaces/expect.py"
>sage -t -long "-4.1.2.alpha2/devel/sage/sage/interfaces/gp.py"
Ticket #6999 [1] contains a patch to fix these two doctest failures on
32-bit platforms.
[1]
On Wed, Sep 23, 2009 at 5:45 PM, Minh Nguyen wrote:
> Hi folks,
>
> Sage 4.1.2.alpha2 builds OK on ubuntu32 VM guest on boxen.math, i.e.
> x86 Ubuntu 9.04. The following doctests fail:
Builds OK on ubuntu64 VM guest on boxen.math, i.e. x86_64 Ubuntu 9.04.
All doctests pass.
--
Regards
Minh Va
Hi folks,
Sage 4.1.2.alpha2 builds OK on ubuntu32 VM guest on boxen.math, i.e.
x86 Ubuntu 9.04. The following doctests fail:
{{{
sage -t -long "devel/sage/sage/crypto/boolean_function.pyx"
**
File
"/space/wstein/farm/sage-4.1.2
On Tue, Sep 22, 2009 at 4:46 PM, Minh Nguyen wrote:
> Hi folks,
>
> Compiling Sage 4.1.2.alpha2 from scratch went OK on 32-bit openSUSE
> 11.0. Here are the doctest failures on that platform:
Builds fine on opensuse64 VM guest on boxen.math, i.e. x86_64 openSUSE
11.1. All doctests pass.
--
Reg
On Tue, Sep 22, 2009 at 4:46 PM, Minh Nguyen wrote:
> Hi folks,
>
> Compiling Sage 4.1.2.alpha2 from scratch went OK on 32-bit openSUSE
> 11.0. Here are the doctest failures on that platform:
Compiles OK on opensuse32 VM guest on boxen.math, i.e. 32-bit openSUSE
11.1. The following doctests fail
On Wed, Sep 23, 2009 at 5:06 PM, Minh Nguyen wrote:
> Hi folks,
>
> Sage 4.1.2.alpha2 compiles OK on the mandriva32 VM guest on
> boxen.math, i.e. 32-bit Mandriva 2009.0. The following doctests fail:
Builds OK on mandriva64 VM guest on boxen.math, i.e. 64-bit Mandriva
2009.0. All doctests pass.
Hi folks,
Sage 4.1.2.alpha2 compiles OK on the mandriva32 VM guest on
boxen.math, i.e. 32-bit Mandriva 2009.0. The following doctests fail:
{{{
sage -t -long "devel/sage/sage/interfaces/expect.py"
**
File
"/space/wstein/farm/sa
76 matches
Mail list logo
