วันพุธที่ 30 กันยายน พ.ศ. 2552

[sage-devel] Re: Polynomial Factoring Content Problem

On Sep 30, 2009, at 8:25 PM, William Stein wrote:

>
> On Wed, Sep 30, 2009 at 7:13 PM, Marshall Hampton
> <hamptonio@gmail.com> wrote:
>>
>> Wow, that's quite disturbing. Did you make a trac ticket for this?
>>
>
> I've made this:
>
> http://trac.sagemath.org/sage_trac/ticket/7088
>
> and made it a 4.1.2 blocker, since it a serious bug. The problem is
> in the _factor_pari method in Sage. It's almost certainly a bug in
> Sage's wrapper of Pari for factoring in the non-monic case. The
> solution will be either to fix that (good) or use the ntl wrapper
> (wimpy).

Wow, it looks like this bug has been around since the very first
checkin. I posted a patch.

- Robert


--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Problem sharing directory

On Wed, Sep 30, 2009 at 10:57 PM, Thierry Dumont
<tdumont@math.univ-lyon1.fr> wrote:
> marik@mendelu.cz a écrit :
>>
>>
>> On 18 zář, 08:33, Robert Bradshaw <rober...@math.washington.edu>
>> wrote:
>>>> Ok, but it should be possible to share the "worksheet" directory ?
>>>> I *need* to share it (we have 3 machines, on which  the users -some
>>>> hundredsof students- will be connected at random).
>>> I don't think that would be possible. What you could do is use the
>>> "server pool" option to use ssh accounts on all three machines to
>>> share the actual computation load, while the notebook frontend would
>>> run on just one machine. This fall the notebook will be made much
>>> more scalable.
>>
>> Great, sounds good, but is this really possible? I found another
>> thread where prof. Stein sais that all accounts have to be on the same
>> Unix machine.
>> http://osdir.com/ml/sage-devel/2009-09/msg00144.html
>>
>> Is this feature allready available? Or should we expect it in the
>> forthcomming version?
>>
>> Sincerely
>> Robert Marik
>>
>>
> I think that the problem is the following (is it true, Dr. Stein ?): not
> everything is in the worksheets directory, which could be shared, but
> many datas concerning the worksheets and the users go in the file
> nb.sobj. And for this file, non concurrent access is [*not*] possible (not like
> in a database managed by a daemon for example).

Yes, that's true.

William

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Problem sharing directory

begin:vcard
fn:Thierry Dumont
n:Dumont;Thierry
org;quoted-printable;quoted-printable:Universit=C3=A9 Lyon 1 & CNRS.;Institut Camille Jordan -- Math=C3=A9matiques / Mathematics.
adr:;;43 Bd du 11 Novembre.;Villeurbanne;;69621;France
email;internet:tdumont@math.univ-lyon1.fr
title;quoted-printable:Ing=C3=A9nieur de Recherche / Research Engineer.
tel;work:04 72 44 85 23.
tel;fax:04 72 44 80 53
x-mozilla-html:FALSE
url:http://math.univ-lyon1.fr/~tdumont
version:2.1
end:vcard

marik@mendelu.cz a écrit :
>
>
> On 18 zář, 08:33, Robert Bradshaw <rober...@math.washington.edu>
> wrote:
>>> Ok, but it should be possible to share the "worksheet" directory ?
>>> I *need* to share it (we have 3 machines, on which the users -some
>>> hundredsof students- will be connected at random).
>> I don't think that would be possible. What you could do is use the
>> "server pool" option to use ssh accounts on all three machines to
>> share the actual computation load, while the notebook frontend would
>> run on just one machine. This fall the notebook will be made much
>> more scalable.
>
> Great, sounds good, but is this really possible? I found another
> thread where prof. Stein sais that all accounts have to be on the same
> Unix machine.
> http://osdir.com/ml/sage-devel/2009-09/msg00144.html
>
> Is this feature allready available? Or should we expect it in the
> forthcomming version?
>
> Sincerely
> Robert Marik
>
>
I think that the problem is the following (is it true, Dr. Stein ?): not
everything is in the worksheets directory, which could be shared, but
many datas concerning the worksheets and the users go in the file
nb.sobj. And for this file, non concurrent access is possible (not like
in a database managed by a daemon for example).
Yours,
t.

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: notebook mini-feature request

William Stein wrote:
> On Wed, Sep 30, 2009 at 9:22 AM, Jason Grout
> <jason-sage@creativetrax.com> wrote:
>> Pablo Angulo wrote:
>>> Many of my students have run into the following problem: they have
>>> deleted the code cells that separated two text blocks and it's
>>> impossible to put a code block between the two text blocks.
>>> The only solution I've found is: create more text and code blocks below,
>>> then copy and paste. Can I ask for a way to put a code block between two
>>> text blocks that lie one right after the other?
>>>
>> Part of the problem is that when the worksheet is saved and then
>> reopened, those two textblocks are just one block! The way things are
>> set up now, a text block is just everything between two input cells.
>> When creating the blocks, you might end up having separate text blocks,
>> but when it is saved, all consecutive text blocks get merged.
>>
>> I agree that it would be nice to have this change, so that text blocks
>> were not saved as just "everything between two input cells", but rather
>> as distinct text blocks.
>>
>> And it is a bug that you don't get a blue add-cell bar at the top of a
>> text block. I believe fixing that will address most of the cases that
>> you talk about.
>>
>
> I've added fixing this to my list.


See
http://groups.google.com/group/sage-devel/tree/browse_frm/thread/5892dd0accc24dde/6643d7c7c19e96fa?hl=en&rnum=1&q=Re%3A+TinyMCE+in+sage-3.3%3A+How+to+insert+a+new+text++cell%3F&_done=%2Fgroup%2Fsage-devel%2Fbrowse_frm%2Fthread%2F5892dd0accc24dde%2F6643d7c7c19e96fa%3Fhl%3Den%26tvc%3D1%26q%3DRe%253A%2BTinyMCE%2Bin%2Bsage-3.3%253A%2BHow%2Bto%2Binsert%2Ba%2Bnew%2Btext%2B%2Bcell%253F%26#doc_c1deb4ffca559300
for a long discussion of a nice UI for adding/breaking cells. I think
from this discussion, I like several ideas:

1. Make the blue "new-cell" bar be split into two halves, possibly of
different colors, and having the text "new code cell" and "new text
cell" or something like that in the middle of each half. Something like:

___________________________________________________________________
| new code cell | new text cell |
|_____________________________|___________________________________|


2. Make it easy to split text cells to insert either text or compute
cells, and make it easy to split compute cells to insert either text or
compute cells.

Jason


--
Jason Grout


--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Polynomial Factoring Content Problem

On Wed, Sep 30, 2009 at 7:13 PM, Marshall Hampton <hamptonio@gmail.com> wrote:
>
> Wow, that's quite disturbing.  Did you make a trac ticket for this?
>

I've made this:

http://trac.sagemath.org/sage_trac/ticket/7088

and made it a 4.1.2 blocker, since it a serious bug. The problem is
in the _factor_pari method in Sage. It's almost certainly a bug in
Sage's wrapper of Pari for factoring in the non-monic case. The
solution will be either to fix that (good) or use the ntl wrapper
(wimpy).

William

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Sage Days: India?

On Wed, Sep 30, 2009 at 5:44 PM, Kiran Kedlaya <kskedl@gmail.com> wrote:
>
>
>
> On Sep 30, 5:15 pm, William Stein <wst...@gmail.com> wrote:
>> Hi Sage-Devel,
>>
>> Jarrod Millman, Prabhu Ramachandran, and I have been kicking around
>> the idea of having a Sage Days in India as a satellite conference near
>> when the next ICM (International Congress of Mathematicians) will
>> happen in India next year (Aug 19-27, 2010 -- seehttp://www.icm2010.org.in/).
>>
>> Who here is highly interested in the possibility of attending such a Sage Days?
>>
>>  -- William
>>
> I'll be in India for the ICM, but I've already booked the week before
> for a pair of satellite conferences in Goa, and I don't think I can
> stay any later. So I'm interested but very likely not actually
> available.

I'm also likely going to a number theory satellite conference in Goa
the week before (maybe the same as you). So this Sage Days would be
either two weeks before or the week after ICM.

William

>
> Kiran
> >
>

--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Sage Days: India?

On Wed, 30 Sep 2009 at 02:15PM -0700, William Stein wrote:
> Hi Sage-Devel,
>
> Jarrod Millman, Prabhu Ramachandran, and I have been kicking around
> the idea of having a Sage Days in India as a satellite conference near
> when the next ICM (International Congress of Mathematicians) will
> happen in India next year (Aug 19-27, 2010 -- see
> http://www.icm2010.org.in/).
>
> Who here is highly interested in the possibility of attending such a
> Sage Days?

It's quite unlikely I could make it -- I've got other travel, plus not
enough funding, etc -- but I definitely think this should happen. In the
other thread about #sage-devel's global coverage, I was going to mention
that our developer map has no one in China or India -- two countries
that together make up somewhere around 40% of the planet's population!
There's got to be mathematicians and programmers in India who would
love to contribute to Sage, and a Sage Days there near ICM is a great
idea.

Dan

--
--- Dan Drake
----- http://mathsci.kaist.ac.kr/~drake
-------

[sage-devel] Re: sagemath.org + google translate + localization

+1.

On Thu, Oct 1, 2009 at 6:17 AM, Harald Schilly <harald.schilly@gmail.com> wrote:

hi, i don't want to add this feature to the sagemath website without a
warning. with google translate it would be possible to display a
translate-bar on top of the page if the browser language (you can set
it, probably the one of the operating system) is different from
english. it would help people to read it in their language, i could
even expand this to work with the documentation pages...
points of concern:
. translation is maybe very bad, but still better than nothing and
will get better in the future.
. more users with little english abilities learn about sage, is this
good or bad? do we help or harm them? does it make sense to educate
them about sage if sage itself is only in english? this is a
hen-and-egg problem and draws resources from our total volume of
support we can give.

further reading:
http://googleblog.blogspot.com/2009/09/translate-your-website-with-google.html
http://translate.google.com/translate_tools

i'm for +1, or a test period to see if there are comments.

h





--
Tim Joseph Dumol <tim (at) timdumol (dot) com>

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Polynomial Factoring Content Problem

Wow, that's quite disturbing. Did you make a trac ticket for this?

-Marshall Hampton

On Sep 30, 7:32 pm, AndyNovo <a...@novocin.com> wrote:
> Hi all,
>
> Found this simple bug in a simple Z[x] factoring example.
>
> R.<x>=PolynomialRing(ZZ)
> f = 12*x^10 + x^9 + 432*x^3 + 9011
> g = 13*x^11 + 89*x^3 + 1
> F = f^2 * g^3
> G = F.factor()
> should_be_zero = F - G.prod()
> should_be_zero == 0
>
> The problem was that F.factor returns
>
> 2028 * (12*x^10 + x^9 + 432*x^3 + 9011)^2 * (13*x^11 + 89*x^3 + 1)^3
>
> Not 1 * (12*x^10 + x^9 + 432*x^3 + 9011)^2 * (13*x^11 + 89*x^3 + 1)^3
>
> This is in the pari degree range. Anyway thought I would post it.
>
> We'll have a very fast polynomial factoring algorithm in FLINT before
> too much longer, promise.
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Sage Days: India?

On Sep 30, 5:15 pm, William Stein <wst...@gmail.com> wrote:
> Hi Sage-Devel,
>
> Jarrod Millman, Prabhu Ramachandran, and I have been kicking around
> the idea of having a Sage Days in India as a satellite conference near
> when the next ICM (International Congress of Mathematicians) will
> happen in India next year (Aug 19-27, 2010 -- seehttp://www.icm2010.org.in/).
>
> Who here is highly interested in the possibility of attending such a Sage Days?
>
> -- William
>
I'll be in India for the ICM, but I've already booked the week before
for a pair of satellite conferences in Goa, and I don't think I can
stay any later. So I'm interested but very likely not actually
available.

Kiran
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Polynomial Factoring Content Problem

Hi all,

Found this simple bug in a simple Z[x] factoring example.

R.<x>=PolynomialRing(ZZ)
f = 12*x^10 + x^9 + 432*x^3 + 9011
g = 13*x^11 + 89*x^3 + 1
F = f^2 * g^3
G = F.factor()
should_be_zero = F - G.prod()
should_be_zero == 0

The problem was that F.factor returns

2028 * (12*x^10 + x^9 + 432*x^3 + 9011)^2 * (13*x^11 + 89*x^3 + 1)^3

Not 1 * (12*x^10 + x^9 + 432*x^3 + 9011)^2 * (13*x^11 + 89*x^3 + 1)^3

This is in the pari degree range. Anyway thought I would post it.

We'll have a very fast polynomial factoring algorithm in FLINT before
too much longer, promise.
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: The one remaining issue which stops Sage building on Solaris. What should we do?

William Stein wrote:
> On Wed, Sep 30, 2009 at 2:50 PM, Dr. David Kirkby
> <david.kirkby@onetel.net> wrote:
>> William Stein wrote:
>>> On Wed, Sep 30, 2009 at 12:29 PM, Dr. David Kirkby
>>> <david.kirkby@onetel.net> wrote:
>>>> http://sagetrac.org/sage_trac/ticket/6579
>>>>
>>>> documents a problem which will occur if one tries to build Sage using
>>>> gcc on 't2', or any other Solaris box I have tried on. One has to
>>>> manually comment out lines 258, 259 and 428 of the file
>>>> $SAGE_HOME/local/include/pari/paripriv.h
>>>>
>>>> I personally don't know how to fix this issue. Nobody I'm aware of has
>>>> looked at it. So each time Sage is built on Solaris, one needs to
>>>> manually edit the file.
>>>>
>>>> What do we do about this?
>>> We have *exactly* the same problem with the Cygwin port. One
>>> possibility would be
>>> to put a #ifdef around those 3 lines in order to remove them.
>>>
>>> Note that I think this problem only appears when building the *Sage*
>>> library, not when
>>> building PARI. So we would pass -Dsomething to Cython so those lines don't get
>>> included when building the Sage library. What do you think? If this
>>> seems reasonable for
>>> you, I think I can easily implement it (since, again, it is needed for
>>> the Cygwin port).
>>>
>>> William
>> I think that sounds reasonable, though without understanding the library
>> (which I don't), I have no idea of the implications. Someone said GAP
>> would be affected.
>
> Huh?! Nobody said anything about GAP -- that just makes no sense.

I thought some one said that about this bit, but perhaps it was
something else.

/* GP_DATA->flags */
enum { QUIET=1, TEST=2, SIMPLIFY=4, CHRONO=8, ECHO=16, STRICTMATCH=32,
USE_READLINE=64, SECURE=128, EMACS=256, TEXMACS=512};

>> I'd hate to see Solaris or Cygwin become second-rate versions of Sage.
>> (I often feel Mathematica on Solaris is not as good as the more popular
>> Linux or Windows versions. )
>
> I would love to see Cygwin have some version of Sage at all (which it
> doesn't right now).

Yes, it does seem a shame, as it is a very easy way for windows users.

Do you have a page like

http://sagetrac.org/sage_trac/ticket/7056

which lists the issues with Cygwin?

>> I'd suggest a few things that I feel would be useful and hopefully avoid
>> this.
>>
>> * You update http://sagetrac.org/sage_trac/ticket/6579 to say this
>> happens on Cygwin too.
>>
>> * Until the issue is resolved properly, that something should be added
>> to the banner to indicate what is basically a hack.
>>
>> * An environment variable will allow the hack to be enable or disabled
>> at compile time.
>>
>> Another option, and perhaps a better one, would be to comment out the 3
>> lines on ALL platforms, then wait until there are some bug reports
>> traceable to this. If the hack could be disabled with a compile-time we
>> might have more hope of finding out the real cause.
>>
>>
>> If http://sagetrac.org/sage_trac/ticket/7040 were resolved, we might be
>> able to build the library with Sun's compiler. The absence or presence
>> of this issue with another compiler could be useful.
>>
>> Pari builds ok with Sun's compiler - it's the Sage library which does
>> not, as CC is not respected properly.
>>
>> Dave
>>
>> If you have $50 spare in your grants, perhaps offer $50 prize to anyone
>> that can find the *real* cause! That might drum up a bit more interest
>> in solving a problem on a platform which most people do not use!
>
> I don't think this is a good way to drive Sage development. It's
> been tried before and the experience was thoroughly unpleasant.

OK. It was just an idea.

> And I do understand this paripriv.h thing more deeply than you guys
> might think... paripriv.h = "pari private". It's not meant to be
> #included by any programs outside of pari itself. However, because we
> dig into pari and use it as a library -- which is very invasive -- to
> build certain cython code we require certain prototypes from there.
> Commenting out those lines will have no impact on this.
>
> William

In that case, since you understand it, from your description it seems
you can do this safely on ALL platforms.

It would be nice to get it resolved, as that pari header file issue is
the only thing stopping Sage building on Solaris SPARC using gcc.

If

http://sagetrac.org/sage_trac/ticket/7021

can be integrated soon, then I'll try to drum up some interest in
getting Sage working with Sun's compiler.

I had some discussions with someone before, who was not really
interested in working on Sage with gcc. I think the fact Sage will then
build with gcc, might get him interested in fixing the issues for the
Sun compiler, which he was far more interested in.

Since there are nearly 40 issues stopping Sage build with the Sun
compiler (and I expect a lot more will be found), them, that is a lot of
work! It would be good to get someone else interested in the port. I
think that will have the side benefit of cleaning up some of the bad code.


Dave

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Problem sharing directory

On Wed, Sep 30, 2009 at 3:40 PM, marik@mendelu.cz <marik@mendelu.cz> wrote:
>
>
>
> On 18 zář, 08:33, Robert Bradshaw <rober...@math.washington.edu>
> wrote:
>> > Ok, but it should be possible to share the "worksheet" directory ?
>> > I *need* to share it (we have 3 machines, on which  the users -some
>> >hundredsof students- will be connected at random).
>>
>> I don't think that would be possible. What you could do is use the
>> "server pool" option to use ssh accounts on all three machines to
>> share the actual computation load, while the notebook frontend would
>> run on just one machine. This fall the notebook will be made much
>> more scalable.
>
> Great, sounds good, but is this really possible?

Not now. It will be in the near future.

> I found another
> thread where prof. Stein sais that all accounts have to be on the same
> Unix machine.
> http://osdir.com/ml/sage-devel/2009-09/msg00144.html
>
> Is this feature allready available?

No.

> Or should we expect it in the
> forthcomming version?

Yes.

-- William

>
> Sincerely
> Robert Marik
>
>
> >
>

--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: standalone sage notebook

On Wed, 30 Sep 2009 at 12:09PM -0700, Harald Schilly wrote:
> On Sep 30, 8:02 pm, Rob Beezer <goo...@beezer.cotse.net> wrote:
> > I often open a worksheet, do some little thing (say, a test or a
> > single plot), and never come back to it ever again.  ...
>
> Me too, maybe we need an additional type of notebook? say
> "scratchpad", which is just temporary without any saving and lost if
> you close the session/browser - but it has a save button, and when you
> press it, the scratchpad is converted to a normal notebook and asks
> for a name.

On most of my notebook accounts, I actually have a worksheet named
"scratch pad" that I use in this way!

Dan

--
--- Dan Drake
----- http://mathsci.kaist.ac.kr/~drake
-------

[sage-devel] Re: The one remaining issue which stops Sage building on Solaris. What should we do?

On Wed, Sep 30, 2009 at 2:50 PM, Dr. David Kirkby
<david.kirkby@onetel.net> wrote:
>
> William Stein wrote:
>> On Wed, Sep 30, 2009 at 12:29 PM, Dr. David Kirkby
>> <david.kirkby@onetel.net> wrote:
>>> http://sagetrac.org/sage_trac/ticket/6579
>>>
>>> documents a problem which will occur if one tries to build Sage using
>>> gcc on 't2', or any other Solaris box I have tried on. One has to
>>> manually comment out lines 258, 259 and 428 of the file
>>> $SAGE_HOME/local/include/pari/paripriv.h
>>>
>>> I personally don't know how to fix this issue. Nobody I'm aware of has
>>> looked at it. So each time Sage is built on Solaris, one needs to
>>> manually edit the file.
>>>
>>> What do we do about this?
>>
>> We have *exactly* the same problem with the Cygwin port.  One
>> possibility would be
>> to put a #ifdef around those 3 lines in order to remove them.
>>
>> Note that I think this problem only appears when building the *Sage*
>> library, not when
>> building PARI.  So we would pass -Dsomething to Cython so those lines don't get
>> included when building the Sage library.  What do you think?  If this
>> seems reasonable for
>> you, I think I can easily implement it (since, again, it is needed for
>> the Cygwin port).
>>
>> William
>
> I think that sounds reasonable, though without understanding the library
> (which I don't), I have no idea of the implications. Someone said GAP
> would be affected.

Huh?! Nobody said anything about GAP -- that just makes no sense.

> I'd hate to see Solaris or Cygwin become second-rate versions of Sage.
> (I often feel Mathematica on Solaris is not as good as the more popular
> Linux or Windows versions. )

I would love to see Cygwin have some version of Sage at all (which it
doesn't right now).

> I'd suggest a few things that I feel would be useful and hopefully avoid
> this.
>
> * You update http://sagetrac.org/sage_trac/ticket/6579 to say this
> happens on Cygwin too.
>
> * Until the issue is resolved properly, that something should be added
> to the banner to indicate what is basically a hack.
>
> * An environment variable will allow the hack to be enable or disabled
> at compile time.
>
> Another option, and perhaps a better one, would be to comment out the 3
> lines on ALL platforms, then wait until there are some bug reports
> traceable to this. If the hack could be disabled with a compile-time  we
> might have more hope of finding out the real cause.
>
>
> If http://sagetrac.org/sage_trac/ticket/7040 were resolved, we might be
> able to build the library with Sun's compiler. The absence or presence
> of this issue with another compiler could be useful.
>
> Pari builds ok with Sun's compiler - it's the Sage library which does
> not, as CC is not respected properly.
>
> Dave
>
> If you have $50 spare in your grants, perhaps offer $50 prize to anyone
> that can find the *real* cause! That might drum up a bit more interest
> in solving a problem on a platform which most people do not use!

I don't think this is a good way to drive Sage development. It's
been tried before and the experience was thoroughly unpleasant.

And I do understand this paripriv.h thing more deeply than you guys
might think... paripriv.h = "pari private". It's not meant to be
#included by any programs outside of pari itself. However, because we
dig into pari and use it as a library -- which is very invasive -- to
build certain cython code we require certain prototypes from there.
Commenting out those lines will have no impact on this.

William

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Where can I find the inner sage code ?

On Wed, 23 Sep 2009 23:47:50 -0700
William Stein <wstein@gmail.com> wrote:

>
> On Wed, Sep 23, 2009 at 10:11 AM, Francois Maltey <fmaltey@nerim.fr>
> wrote:
> >
> > Where is this mysterious method self._gobj.expand(0) ?
>
> That is in the pynac source code. Pynac is a C++ librayr. To look at
> it you have to download and extra the source code, then figure out
> where the expand C++ method is. The pynac website is here:
>
> http://pynac.sagemath.org/
>
> The source code is in an spkg, which you can extract via
>
> tar jxvf pynac-0.1.9.spkg

The source for expand is in several different files. Each
container/operator for a symbolic expression (like add, mul, pow)
defines it's own expand, which in turn call those of the sub
expressions as necessary.

In order to find out how the symbolic expression is kept in memory (and
when an add, mul, or a pow is used) see here:

http://www.ginac.de/tutorial/The-class-hierarchy.html

and here:

http://www.ginac.de/tutorial/Internal-representation-of-products-and-sums.html


If you look in the files add.cpp, mul.cpp, pow.cpp in src/ginac/ of the
untarred package, you'll see the code for the corresponding expand()
functions. AFAIR, all the operations they apply are written in comments
in the form "x^(a+b) -> x^a * x^b", so it's not hard to find out what
goes on.


Cheers,
Burcin

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Sun C++ compiler does not accept pynac C++ code

Burcin Erocal wrote:
> On Sun, 27 Sep 2009 13:47:49 -0700
> William Stein <wstein@gmail.com> wrote:
>
>> On Sun, Sep 27, 2009 at 6:38 AM, Dr. David Kirkby
>> <david.kirkby@onetel.net> wrote:
>>> Using
>>>
>>> * Solaris 10 update 7 on SPARC
>>> * sage-4.1.2.alpha2
>>> * Sun Studio 12.1
>>> * An updated configure script to allow the Sun compiler to be
>>> used
>>>
>>> I found that pynac-0.1.8.p2 will not build. It appears the Sun C++
>>> compiler simply does not like the C++ code in pynac 0.1.8.p2
>> Does ginac build? Maybe this is something you can report to the
>> ginac list too.
>
> I guess a recent version of ginac would build successfully. AFAIR, at
> least some of the problems below were also seen while trying to compile
> with MSVC, and there were patches to fix them.
>
> I will try to grab the relevant patches from ginac, and see if they are
> enough to fix this for pynac. I would appreciate some help testing my
> changes though.
>
> I have access to t2, but I suppose this message didn't come from that
> machine. How can I reproduce it? Would I get the same error on t2? Is
> there a (perhaps half built) Sage installation on t2 that I could copy
> to my home directory and do "sage -sh" to get going?
>
> Thanks.
>
> Burcin

I don't have a recent build on t2 which will work for you. I would
suggest you start from scratch with the following steps.

1) Type

$ export CC=/opt/SUNWspro/bin/cc
$ export CXX=/opt/SUNWspro/bin/CC
$ export SAGE_FORTRAN=/opt/SUNWspro/bin/f95

This will tell Sage to use all the Sun compilers, though in practice
several parts of Sage ignore the settings of CC and CXX.

2) extract the tar file

3) You *MUST* apply the fix at

http://sagetrac.org/sage_trac/ticket/7021

Do not take the files from the attachments on the ticket, but from here.

http://sage.math.washington.edu/home/kirkby/Solaris-fixes/prereq-0.4/

Download the two files to the directory $SAGE_HOME/spkg/base/

That fix is awaiting review, so you might want to comment on it later.
You should see a warning that you are not using GCC, and that Sage has
only every been built with gcc. Without that fix, any attempt to use the
Sun compiler would fail, as the configure script in Sage would say your
gcc is too old.


4) Type 'make'

You should soon see that prereq-0.4 is being built, rather than the
prereq-0.3 which is usual.

5) You will get a few failures. I got the following fail before
'pynac-0.1.9.p0' was built. It would be interesting if you get any
more/less on 't2', as I have not tried recently.

ntl-5.4.2.p9
eclib-20080310.p7
flint-1.5.0.p2
lapack-20071123.p0
atlas-3.8.3.p9
givaro-3.2.13rc2
linbox-1.1.6.p2
matplotlib-0.99.0

To get past the failures, I just used
touch spkg/installed/ntl-5.4.2.p9
or whatever package would not build.

I documented all the failures I observed on my own machine at:

http://sagetrac.org/sage_trac/ticket/7056

6) I'm not sure what prerequisites pynac might have. But at some point
you can try:

$ ./sage -f pynac-xxx

I actually used a slightly newer version of the Sun tools than what is
on 't2', but that should not matter. It would be interesting if you get
the same error as I did, at

http://sagetrac.org/sage_trac/ticket/7029


Dave

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: standalone sage notebook

On Sep 30, 8:02 pm, Rob Beezer <goo...@beezer.cotse.net> wrote:
> I often open a worksheet, do some little thing (say, a test or a
> single plot), and never come back to it ever again.  ...

Me too, maybe we need an additional type of notebook? say
"scratchpad", which is just temporary without any saving and lost if
you close the session/browser - but it has a save button, and when you
press it, the scratchpad is converted to a normal notebook and asks
for a name.

h
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: notebook mini-feature request

On Wed, Sep 30, 2009 at 9:22 AM, Jason Grout
<jason-sage@creativetrax.com> wrote:
>
> Pablo Angulo wrote:
>> Many of my students have run into the following problem: they have
>> deleted the code cells that separated two text blocks and it's
>> impossible to put a code block between the two text blocks.
>> The only solution I've found is: create more text and code blocks below,
>> then copy and paste. Can I ask for a way to put a code block between two
>> text blocks that lie one right after the other?
>>
>
> Part of the problem is that when the worksheet is saved and then
> reopened, those two textblocks are just one block!  The way things are
> set up now, a text block is just everything between two input cells.
> When creating the blocks, you might end up having separate text blocks,
> but when it is saved, all consecutive text blocks get merged.
>
> I agree that it would be nice to have this change, so that text blocks
> were not saved as just "everything between two input cells", but rather
> as distinct text blocks.
>
> And it is a bug that you don't get a blue add-cell bar at the top of a
> text block.  I believe fixing that will address most of the cases that
> you talk about.
>

I've added fixing this to my list.

William

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Sun C++ compiler does not accept pynac C++ code

On Sun, 27 Sep 2009 13:47:49 -0700
William Stein <wstein@gmail.com> wrote:

>
> On Sun, Sep 27, 2009 at 6:38 AM, Dr. David Kirkby
> <david.kirkby@onetel.net> wrote:
> >
> > Using
> >
> >     * Solaris 10 update 7 on SPARC
> >     * sage-4.1.2.alpha2
> >     * Sun Studio 12.1
> >     * An updated configure script to allow the Sun compiler to be
> > used
> >
> > I found that pynac-0.1.8.p2 will not build. It appears the Sun C++
> > compiler simply does not like the C++ code in pynac 0.1.8.p2
>
> Does ginac build? Maybe this is something you can report to the
> ginac list too.

I guess a recent version of ginac would build successfully. AFAIR, at
least some of the problems below were also seen while trying to compile
with MSVC, and there were patches to fix them.

I will try to grab the relevant patches from ginac, and see if they are
enough to fix this for pynac. I would appreciate some help testing my
changes though.

I have access to t2, but I suppose this message didn't come from that
machine. How can I reproduce it? Would I get the same error on t2? Is
there a (perhaps half built) Sage installation on t2 that I could copy
to my home directory and do "sage -sh" to get going?

Thanks.

Burcin

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Pynac auto-evaluation question

On Sep 30, 2:13 pm, Burcin Erocal <bur...@erocal.org> wrote:
> On Wed, 30 Sep 2009 10:52:56 -0700 (PDT)
>
> kcrisman <kcris...@gmail.com> wrote:
> > As it turns out, for this particular issue (#5556), it turned out that
> > gamma(3/4) was auto-evaluating in the actual rational rings code, so
> > this was not Pynac.  I apologize if I didn't make that clearer above.
>
> No apologies necessary, it was clear. I just wanted to explain the
> general situation from my point of view for the record.
>
> ATM, I feel like I am the only one making design decisions for pynac,
> and I'm bound to forget the rationale behind these after a while. I
> would like these to be documented, and get more input from other
> developers.
>
> I know that this is partly caused by the fact that I don't make my
> changes public until they are done, and that happens right before a
> Sage release not leaving much time for discussion. I'll try to improve
> this situation in the future.
>

Is there any possibility of Pynac becoming part of the standard Sage
mercurial repo? In the sense that one would have immediate access to
changes to it via hg_sage, etc. Maybe that's not kosher, since those C
++ files aren't generated by Cython. But it would make it a lot
easier to do, and presumably others who need symbolics would like to
have an easier way to talk about them, since changes in Pynac can have
big influence on Sage.

However, that might be a pretty difficult thing to do - just throwing
it out there. Thanks for all the work on it, as usual! Now if I only
understood enough to help Nils get library access to ECL/Maxima, we'd
really be in business...

- kcrisman
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: assume() syntax or bug?

>
> This issue is being tracked athttp://trac.sagemath.org/sage_trac/ticket/7084

Patch is up.

- kcrisman
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Pynac auto-evaluation question

On Wed, 30 Sep 2009 10:52:56 -0700 (PDT)
kcrisman <kcrisman@gmail.com> wrote:

> As it turns out, for this particular issue (#5556), it turned out that
> gamma(3/4) was auto-evaluating in the actual rational rings code, so
> this was not Pynac. I apologize if I didn't make that clearer above.

No apologies necessary, it was clear. I just wanted to explain the
general situation from my point of view for the record.

ATM, I feel like I am the only one making design decisions for pynac,
and I'm bound to forget the rationale behind these after a while. I
would like these to be documented, and get more input from other
developers.

I know that this is partly caused by the fact that I don't make my
changes public until they are done, and that happens right before a
Sage release not leaving much time for discussion. I'll try to improve
this situation in the future.

Thank you.

Burcin

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: standalone sage notebook

On Sep 30, 7:12 am, Bill Page <bill.p...@newsynthesis.org> wrote:
> > Also, would you like it so that when you create a new worksheet
> > it immediately always by default pops up the "rename" window?
>
> No, I don't think so. It might be a little awkward to have to specify
> a new name every time you just want to try something simple.

I often open a worksheet, do some little thing (say, a test or a
single plot), and never come back to it ever again. So a worksheet
named "Untitled" is usually ripe for deletion without inspection when
I clean up my list of worksheets. Maybe with tags, or folders, or
whatever system is implemented for greater organization of worksheets,
a worksheet that you never bother to name can be automatically placed
into the organizational scheme in some natural way.

Rob
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Call pyginac functions in sage.

Hi Francois,

On Mon, 28 Sep 2009 20:28:46 +0200
Francois Maltey <fmaltey@nerim.fr> wrote:

> If I am right, the symbolic manipulations of Sage come from the
> (py)ginac librairies.

Yes, we use pynac, which is derived from ginac to replace the numeric
types with python objects.

It is a good idea to read the ginac documentation to find out more
about pynac data structures, especially the tutorial:

http://www.ginac.de/tutorial/

Ginac is very well documented, this was one of the reasons we chose to
base the new symbolics on it. :)

> In ginac documentation I find very intersting functions for my use of
> expressions :
>
> is_a<numeric>
> is_a<real>
> is_a<rational>
>
> There are about 30 tests for possible types.
<snip>
> Is it possible to call theses functions from sage ? or must I insert
> a new "module" in sage ?

You can call these functions only from cython, since these are
functions in a c++ library. It's not hard to add support for these,
perhaps as ._is_numeric() or ._is_real() methods of symbolic
expressions.

One way to do that is

- to look in sage/libs/ginac/decl.pxi to see if the function you want
is declared so it can be used in cython. Search for "is_a_" and
you'll see several declarations scattered through the file. If what
you want isn't listed, just add it imitating one of the previous
ones. I suggest adding the new ones after the comment "# more is_a
tests " on line 195.

- then go to sage/symbolic/expression.pyx and add a new method for the
property you are testing for. It would look like:

def _is_numeric(self):
return is_a_numeric(self._gobj)

- save your changes and rebuild Sage by doing "sage -br"
- now if you do "x.<tab>" you should see your new function


On another note, I have a very experimental patch that returns the real
python object after calls to methods of symbolic expressions, instead
of the python object wrapped in a sage.symbolic.expression.Expression.
For example:

sage: t = 2*x
sage: t.operands()[1]
2
sage: type(t.operands()[1])
<type 'sage.rings.integer.Integer'>

Note that now the command above returns

sage: type(t.operands()[1])
<type 'sage.symbolic.expression.Expression'>

With this patch, you could just test for the type of the coefficient,
as you would normally test anywhere else in Sage, using "in ZZ".

My motivation for this change was to get this working:

sage: type(sin(x).subs(x=float(.5)))
<type 'float'>

I put this patch here:

http://sage.math.washington.edu/home/burcin/pynac/return_numeric_as_pyobject.2.patch

Any comments are welcome.


Cheers,
Burcin

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Pynac auto-evaluation question

Thanks for the examples, Burcin - it will definitely be great for the
long haul to have a unified context. I'm not exactly sure what the
difference between _eval_ and friends is, to be honest, and as long as
the use of prec is deprecated and there is a consistent alternative
everywhere, it should be okay.

As it turns out, for this particular issue (#5556), it turned out that
gamma(3/4) was auto-evaluating in the actual rational rings code, so
this was not Pynac. I apologize if I didn't make that clearer above.

- kcrisman
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Pynac auto-evaluation question

Hi Karl-Dieter,

On Wed, 30 Sep 2009 07:01:03 -0700 (PDT)
kcrisman <kcrisman@gmail.com> wrote:

> On Sep 29, 2:30 pm, Robert Bradshaw <rober...@math.washington.edu>
> wrote:
> > On Sep 29, 2009, at 9:16 AM, kcrisman wrote:
> >
> > > Dear sage-devel,
> >
> > > The recently merged Pynac 0.1.9 now automatically evaluates
> > > "inexact" (whatever that means) input to most functions, like
> > > trig, gamma, etc.
> >
> > > Should it do this for rationals?
> >
> > No, I don't think so.
>
> And in fact this doesn't happen for some, e.g.
<snip examples>

As you point out, pynac-0.1.9 doesn't evaluate exact arguments to most
functions. (The only one I know that is evaluated is factorial().)

The fact that some inputs are evaluated is the result of confusion
caused by having a __call__, _eval_, and an _evalf_ method for these
functions in Sage. I guess Mike had to do things this way, because I
misinterpreting the request in #1158 and disabled evaluation in ginac,
so he had to work around that when switching over to pynac.

I've rewritten most of the symbolic function stuff over the last week.
One of the changes was to make the role of __call__, _eval_ and _evalf_
clear. I actually got rid of the __call__. :)

I'll try make my changes public although they are no where near
complete. Maybe this way interested people can comment and fix the
remaining problems, since I don't think I'll have much time for pynac
in the next weeks.


> > > But
> > > in this case it's not obvious how to obtain extra precision
> > > except by passing in a RealField(100) element or something, as
> > > opposed to sqrt (though sqrt seems to be unique in this regard).
> >
> > > My thought is that rationals are "exact" enough that maybe they
> > > shouldn't be autoevaluated, but I don't know what the consensus
> > > would be on that.  Thoughts?  Or maybe we should just add a
> > > 'prec' keyword to all known symbolic functions.
> >
> > That might be a good idea.
>
> That's something I could possibly work on. It would be useful as an
> alternative to making the user cast everything into RR(n).

I suggest you wait to see my patches to the symbolic functions. I don't
think you can add a precision parameter without touching pynac (C++)
code. Though I'd be happy to make this change myself if we decide to go
that way.

Adding this parameter to functions, so they evaluate their inexact
input with higher precision is just a different syntax for this:

sage: t = 0.5
sage: t.prec()
53
sage: gamma(t.n(100))
1.7724538509055160272981674833


I would like to keep a single syntax if possible. This will also
eliminate a lot code dealing with precisions in symbolic functions.


> > Another option (perhaps in addition) would  
> > be to have a context. E.g.
> >
> > with prec(100):
> >     [do some stuff]
> >

I like this option, but this should apply to all preparsed float values
in that context. I.e., 0.5 should have precision 100 in this context,
not 53.


Cheers,
Burcin

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Does Sage need a Fortran compiler?

Dr. David Kirkby wrote:


>> Just out of curiosity, what is the reason behind Solaris shipping with
>> such an ancient compiler? I mean, GCC 3.4.3 was released short of 5
>> years ago, it is not maintained anymore by the original developers (I
>> think), it has no Fortran > 77 support, poor compliance to C++
>> standard, etc.
>
> You would have to ask Sun for a real answer, but I can take an educated
> guess.
>
> I suspect it is the cost of testing a new version properly. Solaris is
> aimed at the big corporate market, where having stability is more
> important than the latest and greatest. They could have no doubt built
> with Fortran, Java, Ada and whatever else compiled in, but chose not to.


If I paid 500K for a set of sun boxes to run my application, and my
application compiled with gcc 3.4.3 when I bought the boxes, I'd be
pretty upset if they stopped supporting it in an update. While I
personally don't have enterprise experience, my guess is that at least
part of the big money that is paid for enterprise-level systems goes
towards ensuring that the system will function as advertised for the
life of the box, even after upgrades of the OS etc. In the same vein, I
wouldn't be surprised if they also had a stock of the hard drives and
other components identical to the ones bought with the system. So why
keep around old stuff? One reason is to keep a commitment with the
people that paid you the big bucks a few years ago.

Jason


--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Review Day next Tuesday (22 Sep)

On Thu, Sep 24, 2009 at 11:07 AM, Robert Bradshaw <robertwb@math.washington.edu> wrote:

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 very nice
compared to how we're using trac. Trac is great at what it was meant
for--bugtracking, but it was not meant to be part of a manual
revision control system. I actually started thinking about this well
before this summer, but now that I've used a fairly nice setup it's
even more clear how good it is when the system gets out of the way
and lets you focus on the work.

Here's my ideal system (which rietveld may or may not be a part of,
but certainly it'd be better to not start something from scratch).

(0) I hack on my own code, committing as I want, the normal mercurial
way.
(1) I run a sage command that takes all my changes and uploads them
to trac (or rietveld, or Review Board, or ...). It may or may not
flatten them. The ticket description should be no more than the
commit description (i.e. our commit descriptions should be a lot more
verbose.)
(2) This patch automatically gets applied to the current alpha, any
merge problems, build problems (including documentation), or test
failures get reported and bounced back. Linting could happen at this
point too (everything from no tabs to coverage to "Sage:" in docstrings)
(3) Upon a successful build (or even not) this build gets saved and
can be accessed and played with (via the notebook or by ssh-ing into
a virtual machine). The code can be browsed and commented on.
(4) Reviewer makes comments, as a whole or line-by-line. They can use
(3), browse the code, and have a sage command like sage -merge that
will quickly update their local copy to the state of the ticket, and
allow them to push as well.
(5) I can quickly address those comments via a sage -b into that
branch (or otherwise using queues/etc. to get back to my ticket
state), make my changes, and re-push to trac. Building and tests
happen after every push. This point here is not to be underestimated--
I think it will greatly improve the quality of the code to lower the
overhead of the feedback loop.
(6) When the reviewer is happy, he marks it as positive review.
(7) The release manager(s) approve the patch. At this point they know
it builds, passes tests, and has at least one positive review. It
goes into a queue.
(8) Patches in the queue get applied to the current alpha. This
implies a moving alpha, which one knows builds and passes all tests
on at least one system. It should be easy to upgrade to that alpha.
(9) People can (easily) donate computer time to build and test
alphas, which will greatly increase hardware coverage. Bisection can
be used to locate the offending ticket in case of failure.


If you don't mind, I put this in SageTasks (http://wiki.sagemath.org/SageTasks)

Note that one can still work "out of the system" mailing around
mercurial bundles and patches, so there's no lock-in. I'm sure there
are a lot of more details to work out (like how to handle spkgs,
which I think could still fit into the above system), but I think a
system like the above would make the job easier for both developers
and release managers. It might tax the computer systems a bit, but
that's not what we're short on now (or, probably, into the
foreseeable future). Every step above that involves a human needs a
human, and doesn't require tons of overhead.

- Robert

P.S. I won't be the one setting this up, at least I hope someone
beats me to it before I have time to tackle something like this next
year.






--
Tim Joseph Dumol <tim (at) timdumol (dot) com>

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Does Sage need a Fortran compiler?

francesco biscani wrote:
> On Wed, Sep 30, 2009 at 8:16 AM, Dr. David Kirkby
> <david.kirkby@onetel.net> wrote:
>> Does there need to be a Fortran compiler on the system to build Sage, or
>> is the fortran-20071120.p9 package a fortran compiler able to build Sage?
>>
>> The reason I ask is that if there is no need for a Fortran compiler, it
>> is quite possible the standard C/C++ compiler shipped with Solaris
>> (3.4.3) could build Sage. It would appear that whatever code in
>> ratpoints is requiring a 4.0.1 or later compiler is not compiled on
>> Solaris.
>>
>> There is an issue with PolyBoRi, but I suspect with a minor change to
>> the code that could be worked around.
>
> Just out of curiosity, what is the reason behind Solaris shipping with
> such an ancient compiler? I mean, GCC 3.4.3 was released short of 5
> years ago, it is not maintained anymore by the original developers (I
> think), it has no Fortran > 77 support, poor compliance to C++
> standard, etc.

You would have to ask Sun for a real answer, but I can take an educated
guess.

I suspect it is the cost of testing a new version properly. Solaris is
aimed at the big corporate market, where having stability is more
important than the latest and greatest. They could have no doubt built
with Fortran, Java, Ada and whatever else compiled in, but chose not to.

Another argument might be they ship a better compiler anyway. Sun Studio
can be downloaded free. The problem is a lot of code is Sage will not
build with Sun Studio. It's not helped by the fact that at least 10% of
the Sage packages don't even respect the CC variable.

dave

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: notebook mini-feature request

Pablo Angulo wrote:
> Many of my students have run into the following problem: they have
> deleted the code cells that separated two text blocks and it's
> impossible to put a code block between the two text blocks.
> The only solution I've found is: create more text and code blocks below,
> then copy and paste. Can I ask for a way to put a code block between two
> text blocks that lie one right after the other?
>

Part of the problem is that when the worksheet is saved and then
reopened, those two textblocks are just one block! The way things are
set up now, a text block is just everything between two input cells.
When creating the blocks, you might end up having separate text blocks,
but when it is saved, all consecutive text blocks get merged.

I agree that it would be nice to have this change, so that text blocks
were not saved as just "everything between two input cells", but rather
as distinct text blocks.

And it is a bug that you don't get a blue add-cell bar at the top of a
text block. I believe fixing that will address most of the cases that
you talk about.

Jason


--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: #sage-devel on irc

Marshall Hampton wrote:
> I think Jason is in Iowa, not Idaho. Often confused by coastal folks,
> but very different.
>

Yep, that's right. I hear that in the winter, we in Iowa feel colder
than the folks in Idaho. (though Marshall, you are probably colder yet!)

> I was marveling at the broad distribution as well yesterday, its great
> to see. While developers are still mostly in Europe and the US,
> things are improving. I think we could probably benefit from more
> exposure in South America,
> according to the dev map the only Sage developers are in Brazil and
> Argentina. Any plans to visit Chile?


And we have some people in Africa as well. Thanks for visiting there
and helping the Sage presence to develop.

Jason


--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Need reviewer for a SERIOUSLY messed up package!!

William Stein wrote:
> On Tue, Sep 29, 2009 at 5:11 PM, Robert Bradshaw
> <robertwb@math.washington.edu> wrote:
>>
>> On Sep 29, 2009, at 3:36 PM, Dr. David Kirkby wrote:

>>> As such, I've set all flags, including those for Fortran, even when
>>> not
>>> needed. The extra few bytes of code does no significant harm. If the
>>> package does not use Fortran, then it will ignore the Fortran flags.
>>>
>>> The problem with creating a spkg-install with a subset of things
>>> set, is
>>> that the subset needs carefully testing for each package. My version
>>> might waste a couple of KB bytes, but it is safe.
>>>
>>> So I have tended to write spkg-install's in such a way that they
>>> should
>>> work with any package.
>>>
>>> Minh asked me the other day to write this up, though I chose not to
>>> just
>>> now, as I am not convinced my latest version is as good as possible.
>> Sounds like something that could be globally useful, rather than
>> having separate logic inside each spkg.
>
> +1

OK, I'll add this logic to sage-env.

I know the variables AR, CP, NM etc are supposed to be user configurable
in Sage, but I somewhat doubt many packages respect the rarer ones,
given they don't even respect CC and CXX.

>>> One of the troublesome packages I noticed when testing with Sun Studio
>>> is tachyon, which uses -O6.
>>>
>>> http://sagetrac.org/sage_trac/ticket/7069
>>>
>>> It's not the -O6 which is causing the Solaris problem, though I do
>>> think
>>> -O6 is unwise. The fact that the tachyon.spkg ignores CC and uses
>>> gcc
>>> anyway, makes me believe the code is not well thought out. Therefore I
>>> suspect there has not been extensive testing to prove -O6 is safe.
>
> There is no -O6 option to GCC. There are three nonzero numbered
> optimization levels: -O1, -O2, and -O3. Do "man gcc". The
> optimization options are:
>
> -O -O0 -O1 -O2 -O3 -Os


That does not stop tachyon using -O6 - see

http://sagetrac.org/sage_trac/ticket/7069

gcc does not indicate any error. It's anyones guess what it does when
passed -O6.

> The difference between -O2 and -O3 is: " -O3 turns on all
> optimizations specified by -O2 and also turns on the
> -finline-functions, -funswitch-loops and -fgcse-after-reload options."
> I think these are not *supposed* to generate invalid assembly code --
> if they do, isn't that considered a bug in GCC? Of course there are
> bugs in GCC, and using aggressive optimization is much more likely to
> uncover them.
>
> -O3 has drawbacks such as potentially larger binaries, cache misses, etc.
>
> -- William

OK. I'll set it at -O3. I think on Solaris with Sun's compiler, it would
be sensible to use just -O, as that will set it to whatever is the
default optimisation, which is currently -O3, but Sun could change that
in the future.

-O Use default optimization level (-xO3)

so -O, -x03 and -O3 are all the same, but they might not be in another
compiler. Sun say -O3 can break some code, so its not a 100% guarantee,
but it would appear such could would be quite rare.


--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] notebook mini-feature request

Many of my students have run into the following problem: they have
deleted the code cells that separated two text blocks and it's
impossible to put a code block between the two text blocks.
The only solution I've found is: create more text and code blocks below,
then copy and paste. Can I ask for a way to put a code block between two
text blocks that lie one right after the other?

Thanks

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: assume() syntax or bug?

On Sep 30, 11:07 am, lutusp <lut...@gmail.com> wrote:
> I find I cannot make more than one of a certain kind of assume
> statement:
>
> sage: assume(a,'real')
> sage: assume(b,'real')
>
> If I do, I get an error message:
>
> AttributeError: 'GenericDeclaration' object has no attribute
> 'variables'

It's comparing your second assumption with the first one, presumably
to make sure it doesn't conflict (?) ... but it is strange that it is
talking about an attribute variables, since the attribute _var is
being called, and b is real has that.

The problem is in symbolic/expression.pyx, where __nonzero__ tries to
find the variable of "a is real" - but it only has a _var, not
variables like "t>0", which is a symbolic expression.

This issue is being tracked at http://trac.sagemath.org/sage_trac/ticket/7084

- kcrisman

>
> One such assumption is accepted, but not two. But more typical
> assumptions are accepted:
>
> sage: forget()
> sage: assume(a > 0)
> sage: assume(b > 0)
> sage: assume(c > 0)
> sage: assumptions()
>
> [a > 0, b > 0, c > 0]
>
> Am I using the wrong syntax or is this a bug?
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Sage Usability outline

A simplified successor to

http://wiki.sagemath.org/SageUsability

is up at

http://wiki.sagemath.org/SageTasks

My apologies for omissions, other mistakes, poor classifications, and
other errors of judgment. Feel free to make changes.

I'm too tired right now to add the new items in sagenb/todo.txt, the
current version of which is available at

http://sage.math.washington.edu:8100/file/77d1f40c7371/sagenb/todo.txt

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] assume() syntax or bug?

I find I cannot make more than one of a certain kind of assume
statement:

sage: assume(a,'real')
sage: assume(b,'real')

If I do, I get an error message:

AttributeError: 'GenericDeclaration' object has no attribute
'variables'

One such assumption is accepted, but not two. But more typical
assumptions are accepted:

sage: forget()
sage: assume(a > 0)
sage: assume(b > 0)
sage: assume(c > 0)
sage: assumptions()

[a > 0, b > 0, c > 0]

Am I using the wrong syntax or is this a bug?

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: standalone sage notebook

On Wed, Sep 30, 2009 at 12:32 AM, William Stein wrote:
>
> On Tue, Sep 29, 2009 at 12:30 PM, Bill Page wrote:
>>
>> I'd like to propose a new item in the
>>
>>  File ...
>>
>> drop-down box.  One thing that has always bugged me is having to
>> Rename a worksheet before clicking Save.  I have also seen it stump a
>> few first time users of the Notebook. How about a
>>
>>  Save As ...
>>
>> option that prompts you with a pop-up for a name in the same way as
>> 'Rename worksheet' and then does a Save.
>
> Sure, I like that idea a lot.
>

Great. It is a common idiom on most gui systems that I use.

> Also, would you like it so that when you create a new worksheet
> it immediately always by default pops up the "rename" window?
>

No, I don't think so. It might be a little awkward to have to specify
a new name every time you just want to try something simple. A default
of "untitled" is fine - at least until you want to save it. If a
worksheet is still named "untitled" then perhaps the system should not
just blindly save it with that pseudo-title when you click 'Save' but
rather automatically pop-up the rename box and invite the user to
change it before saving.

Regards,
Bill Page.

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Pynac auto-evaluation question

On Sep 29, 2:30 pm, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> On Sep 29, 2009, at 9:16 AM, kcrisman wrote:
>
> > Dear sage-devel,
>
> > The recently merged Pynac 0.1.9 now automatically evaluates
> > "inexact" (whatever that means) input to most functions, like trig,
> > gamma, etc.
>
> > Should it do this for rationals?
>
> No, I don't think so.

And in fact this doesn't happen for some, e.g.

sage: sin(SR(3/4))
sin(3/4)
sage: sin(3/4)
sin(3/4)
sage: gamma(SR(3/4))
gamma(3/4)
sage: gamma(3/4)
1.22541670246518
sage: zeta(SR(3/4))
zeta(3/4)
sage: zeta(3/4)
-3.44128538694522

I think that perhaps the problem lies in the special functions, not
Pynac. Apologies to Burcin!

> > But
> > in this case it's not obvious how to obtain extra precision except by
> > passing in a RealField(100) element or something, as opposed to sqrt
> > (though sqrt seems to be unique in this regard).
>
> > My thought is that rationals are "exact" enough that maybe they
> > shouldn't be autoevaluated, but I don't know what the consensus would
> > be on that.  Thoughts?  Or maybe we should just add a 'prec' keyword
> > to all known symbolic functions.
>
> That might be a good idea.

That's something I could possibly work on. It would be useful as an
alternative to making the user cast everything into RR(n).

> Another option (perhaps in addition) would  
> be to have a context. E.g.
>
> with prec(100):
>     [do some stuff]
>

I don't know how to do that.

- kcrisman
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: colour blindness and the Sage notebook interface

2009/9/30 kcrisman <kcrisman@gmail.com>:
>
> This was already considered when graph color defaults were discussed,
> and I've been impressed by how Sage developers seem quite cognizant of
> the issue.

Perhaps because of red-green colour blind developers like me! In the
article linked to above there's one of those dotty diagrams, with a
note saying that people with normal vision can see the number 74 in
it. Well, all I see is a random collection of coloured dots!

John

PS No, I don't have trouble with traffic lights....

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: Does Sage need a Fortran compiler?

On Wed, Sep 30, 2009 at 8:16 AM, Dr. David Kirkby
<david.kirkby@onetel.net> wrote:
>
> Does there need to be a Fortran compiler on the system to build Sage, or
>  is the fortran-20071120.p9 package a fortran compiler able to build Sage?
>
> The reason I ask is that if there is no need for a Fortran compiler, it
> is quite possible the standard C/C++ compiler shipped with Solaris
> (3.4.3) could build Sage. It would appear that whatever code in
> ratpoints is requiring a 4.0.1 or later compiler is not compiled on
> Solaris.
>
> There is an issue with PolyBoRi, but I suspect with a minor change to
> the code that could be worked around.

Just out of curiosity, what is the reason behind Solaris shipping with
such an ancient compiler? I mean, GCC 3.4.3 was released short of 5
years ago, it is not maintained anymore by the original developers (I
think), it has no Fortran > 77 support, poor compliance to C++
standard, etc.

F.

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: colour blindness and the Sage notebook interface

This was already considered when graph color defaults were discussed,
and I've been impressed by how Sage developers seem quite cognizant of
the issue.

On a related note, does anyone know what happens when you try to use a
Sage notebook with some standard software for visually-impaired users
(I think Jaws is one of them)? I imagine that jsmath isn't fully
compatible, or even entry cells...

- kcrisman

On Sep 30, 3:32 am, Minh Nguyen <nguyenmi...@gmail.com> wrote:
> Hi folks,
>
> The sitewww.webmonkey.comhas an interesting article [1] about design
> patterns to consider when designing websites to cater to a range of
> users, including people with colour blindness. Many of the ideas
> mentioned there, and some links listed, might be useful to the
> re-design of the Sage notebook.
>
> [1]http://www.webmonkey.com/blog/Design_Patterns_Solve_Common_Problems_f...
>
> --
> Regards
> Minh Van Nguyen
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: yet another odd integration /w maxima problem

This works fine in the latest alpha release, at any rate.

- kcrisman

On Sep 30, 7:41 am, Harald Schilly <harald.schi...@gmail.com> wrote:
> From the "report a problem" bug list:
>
> in Sage 4.1.1
>
> the evaluation of :
> f = e^(sqrt(x));
> f.integral(x,1,2);
>
> give the error :
> Traceback (click to the left for traceback)
> ...
> Is yx positive or negative?
>
> however the evalutation of :
> f = 2^((sqrt(x))/ln(2));
> f.integral(x,0,2);
>
> work correctly....
>
> Note by me:
> Just f = e^(sqrt(x)); f.integral(x) works!
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] yet another odd integration /w maxima problem

From the "report a problem" bug list:

in Sage 4.1.1

the evaluation of :
f = e^(sqrt(x));
f.integral(x,1,2);

give the error :
Traceback (click to the left for traceback)
...
Is yx positive or negative?


however the evalutation of :
f = 2^((sqrt(x))/ln(2));
f.integral(x,0,2);

work correctly....


Note by me:
Just f = e^(sqrt(x)); f.integral(x) works!
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

[sage-devel] Re: #sage-devel on irc

I think Jason is in Iowa, not Idaho. Often confused by coastal folks,
but very different.

I was marveling at the broad distribution as well yesterday, its great
to see. While developers are still mostly in Europe and the US,
things are improving. I think we could probably benefit from more
exposure in South America,
according to the dev map the only Sage developers are in Brazil and
Argentina. Any plans to visit Chile?

Cheers,
Marshall

On Sep 29, 10:09 pm, William Stein <wst...@gmail.com> wrote:
> Hi,
>
> I'm posting the irc log for #sage-devel here right now. I'm not going
> to do this regularly. The point is just to give people a sense of
> what goes on there on a daily basis in the hopes of encouraging more
> people to login to irc. Typically there are about 20-30 people logged
> in at any given time to #sage-devel on irc.freenode.net. I think
> Sage development would improve if this number were a bit higher,
> especially given the number of active Sage developers.
>
> It's also interesting to see how distributed the people are on IRC.
> For example, today the people involved in the discussion were in
> Seattle (me), Oxford (SPancratz), Philippines (tim dumol), Korea
> (ddrake), Australia (mvngu), Thailand (mhansen), and Idaho (jason
> grout).
>
> ...
> 04:50 < williamstein> excellent progress.
> 04:50 < williamstein> and the next step will be more *fun*.
> 04:52 -!- gpannwitz
> [i=d5dd5cea@gateway/web/freenode/x-kelkxedpcjvrhigl] has quit ["Page
> closed"]
> 04:52 < williamstein> ok, i pushed my changes...
> 05:01 -!- williamstein is now known as williamstein-zzz
> 05:12 -!- timdumol-dinner is now known as timdumol
> 05:22 -!- buntfalke [n=nobody@unaffiliated/buntfalke] has joined #sage-devel
> 06:20 -!- ncohen [n=nco...@rebelote.inria.fr] has quit ["Lost terminal"]
> 06:33 -!- mhansen [n=u...@61.19.67.104] has joined #sage-devel
> 06:49 -!- SPancratz [n=su...@129.67.184.43] has joined #sage-devel
> 06:49 < SPancratz> Hello
> 06:49 < timdumol> SPancratz: hey.
> 06:49 < SPancratz> I just noticed something rather disturbing with the
> general matrix solving code
> 06:50 < SPancratz> I thought I should share this, if someone is interested.
> 06:51 < SPancratz> Code of mine that takes about 65s to execute is
> heavily dominated by solving two matrix equations (matrix * vector =
> vector) where the coefficient ring is QQ[]
> 06:52 < SPancratz> Of that time, 44s (of cumtime from using %prun)are
> spent in the method Hom in homset.py, 17s in the method 'category' of
> the Ring object, and 11s in _repr_ in polynomial_ring.py
> 06:53 < SPancratz> Only a very small time is actually spent crunching
> away at the matrices
> 06:54 < timdumol> SPancratz: I am unfamiliar with that code, unfortunately.
> 06:56 < SPancratz> I think as far as my own code is concerned, I will
> just copy the relevant SAGE code and take away everything that _might_
> be needed in general but can be ignored if one knows which ring all
> elements lie in and knows that this won't change.
> 06:57 < SPancratz> I just thought other people might perhaps have come
> across this
> 07:01 < mhansen> SPancratz: Do you have a test case that I could look at?
> 07:02 -!- jason [n=ja...@97-125-136-197.desm.qwest.net] has joined #sage-devel
> 07:02 -!- jason is now known as Guest81620
> 07:02 -!- Guest81620 is now known as jason-
> 07:08 < SPancratz> mhansen: I can quickly make on up
> 07:09 < mhansen> Cool. I'll be back in about 15 minutes and get
> hopefully get things sped up for you.
> 07:30 < SPancratz> mhansen: I've uploaded an example tohttp://sage.pastebin.com/m3203c2a7
> 07:35 < SPancratz> Of course, I see that the matrix and the vector are
> ridiculously sparse and I should take advantage of that. However,
> most of the standard numerical methods don't apply (they often assume
> the matrix is positive definite or symmetric, and in this case I am
> not even sure what the first notion could mean, and the matrix isn't
> symmetric). I am trying to find useful references for solving sparse
> linear equations, but I've only started that an hour ago and
> 07:37 < SPancratz> mhansen: I need to go to College for a few
> minutes, but I should be back in about 15mins.
> 08:03 < SPancratz> mhansen: Just to let you know, I am back.
> 08:03 < mhansen> Cool. I just got back as well.
> 08:18 < SPancratz> mhansen: Did you get my previous messages?
> 08:20 < mhansen> Yeah. I'm just looking at it now.
> 08:22 < SPancratz> Thank you
> 08:37 < mhansen> SPancratz: Are you using your FLINT Q(x) code?
> 08:39 < SPancratz> Yes
> 08:41 < mhansen> Let me install the latest version of that so that
> we're working off the same thing :-)
> 08:59 < mhansen> SPancratz: I get an error when running your code.
> But, if I switch to Frac(ZZ['t']) then it finishes in about 2s.
> 09:00 < SPancratz> Which error do you get?
> 09:01 < SPancratz> I think I fixed one small thing
> 09:01 < mhansen> TypeError: Rescaling row by Fraction Field of
> Univariate Polynomial Ring in t over Rational Field element cannot be
> done over Fraction Field of Univariate Polynomial Ring in t over
> Rational Field, use change_ring or with_rescaled_row instead.
> 09:01 < mhansen>
> 09:01 < mhansen> Which is a silly bug.
> 09:01 < SPancratz> Can I just let you know the fix?
> 09:01 < mhansen> Sure
> 09:02 < SPancratz> It's in the method reduce in fraction_field_element.pyx
> 09:03 < SPancratz> (The second occurrence, of the
> UnivariateRationalRational... type)
> 09:04 < SPancratz> The method should add another cdef Rational y, and
> then on about line 1054, rather than having x = ~x (which causes the
> bug for integer x) it should to y = ~ Rational(x), and the next two
> lines should be num = y * num and den = y * den
> 09:07 < mhansen> So, if you need this for research right away, you can
> work over Frac(ZZ['t']) which is the same ring.
> 09:08 < mhansen> Hmm... I'm getting "Error: unable to alloc/realloc memory"
> 09:08 < mhansen>
> 09:08 < SPancratz> Well, the idea behind it is that I am trying to
> make code computing connection matrices faster
> 09:09 < SPancratz> (Using basic linear algebra rather than the usual
> Groebner basis approach)
> 09:11 < SPancratz> It might be doomed to failure, but for some example
> I am only out by a factor of 20, which I think I can comfortably
> achieve by re-implementing Q(t), adding methods _addmul_ and _submul_
> (similary to the ones in GMP, for computing x = r + s*t), and using
> the sparsity of the matrices
> 09:12 -!- mjturk [n=mjt...@128.54.7.241] has joined #sage-devel
> 09:12 < mhansen> Why do you use Q(t) instead of Z(t)?
> 09:13 < SPancratz> It would probably be better to use Z(t). The short
> answer is that I didn't think about that part.
> 09:14 < mhansen> That's what I did before with ZZ['t'] was much faster
> than QQ['t'] :-)
> 09:15 < SPancratz> But on trying that right now, I noticed that
> something else in my code doesn't work. For f definitely being equal
> to a monomial in S = Z(t)[X,Y,Z], I get an error from
> multi_polynomial_element.py:
> 09:15 < SPancratz> 563 if not (isinstance(mon,
> MPolynomial) and mon.parent() is self.parent() and mon.is_monomial()):
> 09:15 < SPancratz> --> 564 raise TypeError, "mon must be a
> monomial in the parent of self."
> 09:15 < SPancratz> Where my f is mon in the relevant SAGE code
> 09:15 < SPancratz> I am guessing the "isinstance(mon, MPolynomial)" might fail
> 09:16 < SPancratz> I think my f is an MPolynomial_polydict
> 09:17 < SPancratz> I think that inherits from MPolynomial, but the
> isinstance check fails, of course.
> 09:18 -!- opp [n=huxp...@60.168.88.177] has quit [Read error: 60
> (Operation timed out)]
> 09:19 < mhansen> I think the isinstance should work.
> 09:21 < SPancratz> I'll run the code again, printing the results of
> the three checks before calling the method
> 09:26 < SPancratz> You were right
> 09:27 < SPancratz> I am checking Q.monomial_
> 09:28 < SPancratz> I am using Q.monomial_coefficient(f) for lots of f.
> For various Q and f. For most Q, the parent is "Multivariate
> Polynomial Ring in X, Y, Z over Fraction Field of Univariate
> Polynomial Ring in t over Integer Ring", but for no apparent reason
> for one of them it turns out as "... Rational Field"
> 09:31 < SPancratz> I am guessing somewhere in the code must be an
> exact division which triggers the ring to change. Well, I guess I
> need to go and fix that now.
> 09:31 < SPancratz> Thank you for your help. By the way, is there
> anything I ought to do regarding QQ[] at the moment, or can I leave it
> as is for the time being and look at it again after the next stable
> release of SAGE?
> 09:32 < mhansen> With the latest patch at #4000 on trac, I can that
> memory error.
> 09:32 < mhansen> err, I get that
> 09:33 < SPancratz> Which memory error?
> 09:34 < mhansen> Error: unable to alloc/realloc memory
> 09:34 < mhansen>
> 09:34 < mhansen> Here's a traceback:http://sage.pastebin.com/m1ce587b9
> 09:36 < SPancratz> What do you have to do to get that?
> 09:39 < mhansen> I just ran the session that you posted with the
> latest patch from #4000 (and FLINT 1.5.0).
> 09:42 -!- prometheus1809 [n=prome...@202.3.77.11] has joined #sage-devel
> 09:43 < SPancratz> From the traceback, the call comes from
> "__fmpq_poly_den_fit_limbs", and that in turn from floor division.
> The former is only 7 lines long and almost surely without mistakes if
> I dare to say that at all. The only thing I can think of is that
> perhaps somewhere in floor div instead of passing an unsigned long,
> somewhere there is mixed operation with a signed integer and that
> could perhaps cause the unsigned long limbs to be ridiculously large,
> and that
> 09:43 < SPancratz> (I am looking at that now. Other than that, I
> would have now idea)
> 09:47 < SPancratz> In floor div, I can see any bad handling of
> unsigned longs. fmpz_size should return an unsigned long, and so
> should the pseudo division code. And then I am only adding and
> multiplying those.
> 09:47 < mhansen> Hmm...
> 09:50 < SPancratz> Could you perhaps let me know to which line in
> polynomial_rational_flint.pyx the line 7319 in your compiled version
> *.cpp corresponds?
> 09:51 < mhansen> /*
> "/opt/sage/devel/sage-main/sage/rings/polynomial/../../libs/flint/fmpq_poly_linkage.pxi":715
> 09:51 < mhansen> *
> 09:51 < mhansen> * if __fmpq_poly_den_is_one(a):
> 09:51 < mhansen> * __fmpq_poly_den_fit_limbs(q, limbs)
> # <<<<<<<<<<<<<<
> 09:51 < mhansen> * fmpz_pow_ui(q.den, lead, m)
> 09:51 < mhansen> * else:
> 09:51 < mhansen> */
> 09:51 < mhansen>
> __pyx_f_4sage_5rings_10polynomial_25polynomial_rational_flint___fmpq_poly_den_fit_limbs(__pyx_v_q,
> __pyx_v_limbs);
> 09:51 < mhansen>
> 09:57 -!- SPancratz [n=su...@129.67.184.43] has left #sage-devel []
> 09:57 -!- SPancratz [n=su...@129.67.184.43] has joined #sage-devel
> 09:57 < SPancratz> mhansen: I can't see anything there that should be
> going wrong
> 10:03 < SPancratz> mhansen: I just found that strange behaviour that
> breaks my other code right now.
> 10:03 < SPancratz> Say F = Frac(ZZ['t']), Q = (t-3)/(t-1), then Q has
> parent F. But setting R = (3/7) * Q, R has parent Frac(QQ['t']).
> 10:04 < SPancratz> Would you know how one can change that?
> 10:08 < mhansen> Yeah
> 10:08 -!- zirpu [n=zi...@nefud.org] has left #sage-devel []
> 10:10 < SPancratz> On which level is that happening?
> 10:10 < SPancratz> A quick fix on my end would be to always coerce the
> result back into the ring I want, but that seems like creating to much
> overhead. (Not on this occasion, but in principle)
> 10:13 < mhansen> It's with the coercion system.
> 10:14 < SPancratz> Should I file a bug report for that? (I won't be
> able to do anything about it at the moment because I don't know the
> coercion system well enough.)
> 10:18 < mhansen> Let me try something.
> 10:22 < mhansen> sage: F = Frac(ZZ['t'])
> 10:22 < mhansen> sage: F.has_coerce_map_from(QQ)
> 10:22 < mhansen> True
> 10:22 < mhansen> sage: f = F.random_element()
> 10:22 -!- williamstein-zzz [n=willi...@66.235.51.227] has quit []
> 10:22 < mhansen> sage: f
> 10:22 < mhansen> (t^2 + 2*t + 1)/(-t^2 + 2*t - 1)
> 10:22 < mhansen> sage: g = 1/2 * f; g
> 10:22 < mhansen> (t^2 + 2*t + 1)/(-2*t^2 + 4*t - 2)
> 10:22 < mhansen> sage: g.parent()
> 10:22 < mhansen> Fraction Field of Univariate Polynomial Ring in t
> over Integer Ring
> 10:22 < mhansen>
> 10:23 < mhansen> Here's one way to do ithttp://sage.pastebin.com/m56acd5e7
> 10:23 < mhansen> Not the most exact, but...
> 10:48 < SPancratz> mhansen: Thank you very much for the help
> 10:49 < mhansen> No problem.
> 10:49 < SPancratz> I have to leave in a few minutes; I've been in the
> office for long enough today I think. Perhaps I'll be online again
> later tonight at home. Bye!
> 10:51 -!- SPancratz [n=su...@129.67.184.43] has left #sage-devel []
> 10:54 -!- pearu [n=pe...@82.131.23.30.cable.starman.ee] has joined #sage-devel
> 10:57 -!- williamstein
> [n=willi...@D-69-91-159-214.dhcp4.washington.edu] has joined
> #sage-devel
> 10:59 -!- williamstein
> [n=willi...@D-69-91-159-214.dhcp4.washington.edu] has quit [Client
> Quit]
> 11:07 -!- mnick [n=...@e181107125.adsl.alicedsl.de] has quit ["leaving"]
> 11:10 -!- mvngu is now known as mvngu|afk
> 11:15 -!- jbosman [n=quas...@132.252.150.95] has quit [Remote closed
> the connection]
> 11:35 -!- prometheus1809 [n=prome...@202.3.77.11] has quit ["Leaving"]
> 11:54 -!- williamstein
> [n=willi...@D-69-91-159-214.dhcp4.washington.edu] has joined
> #sage-devel
> 12:12 < timdumol> williamstein: You there?
> 12:12 < williamstein> yes
> 12:13 < williamstein> just got out of the faculty meeting.
> 12:13 < williamstein> UW math isn't broke :-)
> 12:13 < timdumol> Great to know :))
> 12:13 < timdumol> Great timing. I think I finally got the introspection to work.
> 12:14 < timdumol> williamstein: Nevermind. I missed a TODO.
> 12:15 < williamstein> ?
> 12:15 < timdumol> Just need to generate a confdir, then it should work.
> 12:16 < timdumol> It works with access to SAGE_DOC. But since that
> can't be assumed, I guess a confdir will have to be generated.
> 12:20 < mhansen> jason-: Are you reviewing #7007?
> 12:20 < jason-> now, or in general?
> 12:21 < mhansen> In general
> 12:21 < mhansen> It does fix #5755
> 12:21 < jason-> let me look...
> 12:22 < mhansen> It's just basically two changes to a regex and then
> fallout from that.
> 12:22 < jason-> wow, that's quite a fallout
> 12:23 < jason-> so you just added "(\.0+)?" to the regex?
> 12:23 < jason-> it's just a printing issue?
> 12:24 < williamstein> timdumol -- I think SAGE_DOC can be assumed, right?
> 12:24 < williamstein> at least SAGE_dOC in the worksheet process.
> 12:25 < williamstein> If the worksheet process is a running copy of
> *SAGE* then we have SAGE_DOC.
> 12:25 < williamstein> If it isn't, then we don't do Sphinx.
> 12:25 < williamstein> Since without Sage we only have PYthon and no
> guarantee of any Sphinx stuff.
> 12:25 < williamstein> And anyways, Sphinx support without Sage can be
> added later.
> 12:25 < mhansen> jason-: Yeah. It removed stuff like 1*x from
> everything else before.
> 12:26 < jason-> yes, I see. So this is more consistent now.
> 12:26 < timdumol> williamstein: Alright. But I think I've gotten the
> confdir generation done already anyways. A tad inefficient though.
> 12:26 < williamstein> Hey, nice work.
> 12:26 < williamstein> That's even better of course.
> 12:26 < jason-> mhansen: what about the latex representation, though?
> 12:27 < jason-> _latex_ still has the old replace, it looks like
> 12:28 < mhansen> Yep, you're right. I didn't about that.
> 12:30 -!- pearu [n=pe...@82.131.23.30.cable.starman.ee] has quit ["Leaving."]
> 12:30 < mhansen> (Since it wasn't relevant to the title of the ticket :-) )
> 12:30 < jason-> yeah, I know..
> 12:31 < jason-> but since you're already knee-deep in the code
> 12:31 < mhansen> Yep -- I'll do it now.
> 12:41 < mhansen> jason-: New patch is up.
> 12:45 < timdumol> williamstein: K. Finally done with the docstrings.
> I'm going to post the patch on trac now.
> 12:45 < williamstein> excellent
> 12:45 < williamstein> i'll try it
> 12:46 < jason-> mhansen: thanks
> 12:50 < timdumol> williamstein: Patch up at #7076
> 12:50 < williamstein> ok, trying now.
> 12:50 < williamstein> timdumol -- and thanks for doing this, since I
> was really procrastinating it!
> 12:51 < timdumol> williamstein: No prob. It's been a great learning experience.
> 12:51 < williamstein> And factoring the code out like you did is
> awesome, since it will make it much easier to make a sphinxify command
> line tool, etc.
> 12:52 < williamstein> If you ever need a letter of recommendation,
> don't hesitate to ask me.
> 12:52 < timdumol> williamstein: Actually, I'm reasonably certain it
> should work as a command line tool already.
> 12:52 < williamstein> cool.
> 12:52 < timdumol> williamstein: Thanks a lot.
> 12:53 < jason-> mhansen: so far, it looks great. Thanks! Can you
> address kcrisman's comments on the ticket though?
> 12:53 < mhansen> Sure, but it's about bedtime for me.
> 12:53 < mhansen> If you'd also weigh in, that'd be good.
> 12:53 < jason-> okay. I'm finishing a few doctests
> 12:54 < jason-> I'll post positive review (since it's just a printing issue)
> 12:54 < timdumol> It's a bit late here (4 AM). I think I'll sleep now. Bye.
> 12:54 -!- timdumol is now known as timdumol-asleep
> 12:55 < jason-> I guess the question is if there is a distinction, if
> x=polygen(RR), between x the variable and the polynomial 1.0000000*x
> 12:55 < jason-> williamstein might be able to give a nice
> authoritative answer...
> 12:55 < mhansen> Well, we have no datatype for representing the variable itself.
> 12:56 < jason-> aah, okay, that does change things
> 12:56 < jason-> so the variables literally are the polynomials like 1.00000*x?
> 12:56 < williamstein> jason- -- yep
> 12:56 < mhansen> Yeah
> 12:57 < jason-> can you explain this, then:
> 12:57 < jason-> sage: x=polygen(RDF)
> 12:57 < jason-> sage: x is 1*x
> 12:57 < jason-> False
> 12:57 < jason-> sage: (1*x).variables()[0] is x
> 12:57 < jason-> True
> 12:57 < jason-> if x the variable really is 1*x
> 12:58 < mhansen> If the generator is cached, then you get the above behavior.
> 12:58 < jason-> okay
> 12:58 < mhansen> 1*x creates a new polynomial in memory.
> 12:59 < jason-> sure, okay.
> 12:59 < jason-> so positive review, then.
> 13:00 < jason-> now I have to remember what I was doing when I ran
> across the issue...
> 13:02 -!- mhansen is now known as mhansen-sleep
> 13:02 < jason-> thanks again mhansen-sleep
>
> --
> William Stein
> Associate Professor of Mathematics
> University of Washingtonhttp://wstein.org
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to sage-devel-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---