วันจันทร์ที่ 31 พฤษภาคม พ.ศ. 2553

Re: [sage-devel] bug with DisjointUnionEnumeratedSet?

Hi John,

> One of the examples in the docstring for DisjointUnionEnumeratedSet
> goes something like this:
>
> sage: U = DisjointUnionEnumeratedSets(Family(NonNegativeIntegers(),
> Permutations))
> sage: it = iter(U)
> sage: it.next()
> []
>
> If I try the same thing, replacing "Permutations" with "Partitions",
> it doesn't work:
>
> sage: U = DisjointUnionEnumeratedSets(Family(NonNegativeIntegers(),
> Partitions))
> sage: it = iter(U)
> sage: it.next()
> ---------------------------------------------------------------------------
> ValueError Traceback (most recent call
> [...]
> Is this expected?

I can't reproduce the problem with sage 4.4.2:

tomahawk-~ $ sage
----------------------------------------------------------------------
| Sage Version 4.4.2, Release Date: 2010-05-19 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: U = DisjointUnionEnumeratedSets(Family(NonNegativeIntegers(), Partitions))
sage: it = iter(U)
sage: it.next()
[]
sage: it.next()
[1]
sage: it.next()
[2]
sage: it.next()
[1, 1]
sage: it.next()
[3]
sage: it.next()
[2, 1]
sage: it.next()
[1, 1, 1]
sage: quit
Exiting Sage (CPU time 0m0.12s, Wall time 0m13.00s).

Which version of sage are you using ?

Cheers,

Florent

--
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] Allowing parameters for GSL ode solver

Hi,

a few weeks ago I noticed the code for the GSL ode solver in Sage
doesn't support parameters in compiled functions, although the native
API supports it and I found that feature quite useful for solving with
different parameter sets.

I wrote a patch to enable it. The only problem I see is that it breaks
compatibility with existing user code due to a changed interface for
compiled functions. Maybe you've a idea how to prevent that.

Trac #8981: http://trac.sagemath.org/sage_trac/ticket/8981

BTW, is there a policy I need to request a review on the mailing list? I
opened the bug two weeks ago and haven't got an answer yet. :p

Best regards,
André Bubel

--
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] bug with DisjointUnionEnumeratedSet?

One of the examples in the docstring for DisjointUnionEnumeratedSet
goes something like this:

sage: U = DisjointUnionEnumeratedSets(Family(NonNegativeIntegers(),
Permutations))
sage: it = iter(U)
sage: it.next()
[]

If I try the same thing, replacing "Permutations" with "Partitions",
it doesn't work:

sage: U = DisjointUnionEnumeratedSets(Family(NonNegativeIntegers(),
Partitions))
sage: it = iter(U)
sage: it.next()
---------------------------------------------------------------------------
ValueError Traceback (most recent call
last)

/Users/palmieri/<ipython console> in <module>()

/Applications/sage/local/lib/python2.6/site-packages/sage/sets/
disjoint_union_enumerated_sets.pyc in __iter__(self)
398 """
399 for k in self._family.keys():
--> 400 for el in self._family[k]:
401 if self._keepkey:
402 el = (k, el)

/Applications/sage/local/lib/python2.6/site-packages/sage/sets/
family.pyc in __getitem__(self, i)
939 10
940 """
--> 941 return self.function(i)
942
943 def __getstate__(self):

/Applications/sage/local/lib/python2.6/site-packages/sage/combinat/
combinat.pyc in __call__(self, x)
1013 return self._element_constructor_(x)
1014 else:
-> 1015 raise ValueError, "%s not in %s"%(x, self)
1016
1017 Element = CombinatorialObject # mostly for backward
compatibility

ValueError: 0 not in Partitions


Is this expected?

--
John

--
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

Re: [sage-devel] Re: Is there a linbox / BLAS dependency missing in 'deps'?

> On 05/31/10 08:36 AM, François Bissey wrote:
> >> I think you've found a bug in the makefile.
> >>
> >> We have
> >>
> >> LINBOX depends on ATLAS
> >>
> >> ATLAS depends on LAPACK and PYTHON
> >>
> >> LAPACK depends on FORTRAN
> >>
> >> It is just a lucky coincidence that the Sage build has actually worked.
> >> We need to add BLAS as a dependency of LAPACK, e.g,.
> >>
> >> $(INST)/$(LAPACK): $(INST)/$(FORTRAN) $(INST)/$(BLAS)
> >>
> >> $(SAGE_SPKG) $(INST)/$(LAPACK) 2>&1
> >>
> >> Then everything should work fine, since depence is transitive.
> >
> > Can you remind me again why we have BLAS and not just ATLAS?
> > We can just build lapack against ATLAS.
> >
> > Francois
>
> I've looked at 'linbox' and find that it usually has two libraries - cblas
> and atlas. I don't know how it resolves these, but I assume if either will
> do, then it will use the first one (usually cblas, but sometimes blas),
> and not use atlas.
>
> Does this make a lot of sence to you? The code from linbox's spkg-install
> is below.
>
> Dave
>
>
> if [ "$LINBOX_BLAS" != "" ]; then
>
> echo "Using environment variable LINBOX_BLAS "$LINBOX_BLAS""
>
> elif [ $UNAME = "Darwin" -a -f "/usr/lib/libcblas.dylib" ]; then
>
> LINBOX_BLAS=/usr/lib/libcblas.dylib
>
> elif [ $UNAME = "Linux" -a -f "${SAGE_LOCAL}/lib/libcblas.so" ]; then
>
> echo "Linux cblas"
>
> LINBOX_BLAS="-lcblas -latlas"
>
> elif [ $UNAME = "CYGWIN" ]; then
>
> echo "Using system-wide Cygwin LAPACK BLAS."
> if [ ! -f "/usr/lib/libblas.a" ]; then
> echo "*************************************************"
> echo "*"
> echo "* On Cygwin you must install the standard LAPACK Cygwin
> package" echo "* via the Cygwin setup.exe program in the 'Math' category."
> echo "*"
> echo "*************************************************"
> exit 1
> fi
> LINBOX_BLAS="-lblas "
>
> elif [ $UNAME = "SunOS" -a -f "${SAGE_LOCAL}/lib/libcblas.so" ]; then
>
> echo "Solaris cblas"
>
> LINBOX_BLAS="-lcblas -latlas"
>
> elif [ $UNAME = "FreeBSD" -a -f "${SAGE_LOCAL}/lib/libcblas.a" ]; then
>
> echo "FreeBSD cblas"
>
> LINBOX_BLAS="-lcblas -latlas"
>
> elif [ $UNAME = "FreeBSD" -a -f "${SAGE_LOCAL}/lib/libcblas.so" ]; then
>
> echo "FreeBSD cblas"
>
> LINBOX_BLAS="-lcblas -latlas"
>
> else
> echo "WARNING WARNING"
> echo "WARNING WARNING"
> echo "WARNING WARNING"
> echo "WARNING WARNING"
> echo "using frickin' slow GSL C-blas"
> echo "WARNING WARNING"
> echo "WARNING WARNING"
> echo "WARNING WARNING"
> echo "WARNING WARNING"
> echo "WARNING WARNING"
>
> if [ $UNAME = "Darwin" ]; then
> LINBOX_BLAS="$SAGE_LOCAL"/lib/libgslcblas.dylib
> else
> LINBOX_BLAS="$SAGE_LOCAL"/lib/libgslcblas.so
> fi
>
> fi

It's been some time since I have looked at the spkg-install code for linbox.
You may notice that in the blas detection macros shipped with linbox they
add -llapack - I think it probably should be added in LINBOX_BLAS.

Francois

--
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

Re: [sage-devel] Re: Is there a linbox / BLAS dependency missing in 'deps'?

On 05/31/10 08:36 AM, François Bissey wrote:
>> I think you've found a bug in the makefile.
>>
>> We have
>>
>> LINBOX depends on ATLAS
>>
>> ATLAS depends on LAPACK and PYTHON
>>
>> LAPACK depends on FORTRAN
>>
>>
>> It is just a lucky coincidence that the Sage build has actually worked.
>> We need to add BLAS as a dependency of LAPACK, e.g,.
>>
>> $(INST)/$(LAPACK): $(INST)/$(FORTRAN) $(INST)/$(BLAS)
>> $(SAGE_SPKG) $(INST)/$(LAPACK) 2>&1
>>
>> Then everything should work fine, since depence is transitive.
> Can you remind me again why we have BLAS and not just ATLAS?
> We can just build lapack against ATLAS.
>
> Francois
>

I've looked at 'linbox' and find that it usually has two libraries - cblas and
atlas. I don't know how it resolves these, but I assume if either will do, then
it will use the first one (usually cblas, but sometimes blas), and not use atlas.

Does this make a lot of sence to you? The code from linbox's spkg-install is below.

Dave


if [ "$LINBOX_BLAS" != "" ]; then

echo "Using environment variable LINBOX_BLAS "$LINBOX_BLAS""

elif [ $UNAME = "Darwin" -a -f "/usr/lib/libcblas.dylib" ]; then

LINBOX_BLAS=/usr/lib/libcblas.dylib

elif [ $UNAME = "Linux" -a -f "${SAGE_LOCAL}/lib/libcblas.so" ]; then

echo "Linux cblas"

LINBOX_BLAS="-lcblas -latlas"

elif [ $UNAME = "CYGWIN" ]; then

echo "Using system-wide Cygwin LAPACK BLAS."
if [ ! -f "/usr/lib/libblas.a" ]; then
echo "*************************************************"
echo "*"
echo "* On Cygwin you must install the standard LAPACK Cygwin package"
echo "* via the Cygwin setup.exe program in the 'Math' category."
echo "*"
echo "*************************************************"
exit 1
fi
LINBOX_BLAS="-lblas "

elif [ $UNAME = "SunOS" -a -f "${SAGE_LOCAL}/lib/libcblas.so" ]; then

echo "Solaris cblas"

LINBOX_BLAS="-lcblas -latlas"

elif [ $UNAME = "FreeBSD" -a -f "${SAGE_LOCAL}/lib/libcblas.a" ]; then

echo "FreeBSD cblas"

LINBOX_BLAS="-lcblas -latlas"

elif [ $UNAME = "FreeBSD" -a -f "${SAGE_LOCAL}/lib/libcblas.so" ]; then

echo "FreeBSD cblas"

LINBOX_BLAS="-lcblas -latlas"

else
echo "WARNING WARNING"
echo "WARNING WARNING"
echo "WARNING WARNING"
echo "WARNING WARNING"
echo "using frickin' slow GSL C-blas"
echo "WARNING WARNING"
echo "WARNING WARNING"
echo "WARNING WARNING"
echo "WARNING WARNING"
echo "WARNING WARNING"

if [ $UNAME = "Darwin" ]; then
LINBOX_BLAS="$SAGE_LOCAL"/lib/libgslcblas.dylib
else
LINBOX_BLAS="$SAGE_LOCAL"/lib/libgslcblas.so
fi

fi


--
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

Re: [sage-devel] Re: Fwd: [sage-combinat-devel] permutation group perspectives

>> I've brought this one up before.  How do folks feel about having the
>> named permutation groups available like graphs are?  In other words,
>> rather than each family of permutation groups being a new class, there
>> is a single system-wide object ("groups", or "perm_groups") whose
>> methods produce instances of permutation groups (or more generally,
>> just groups).  So for example,
>>
>> D=groups.DihedralGroup(7)
>>
>> would replace the above syntax.  Advantages - namespace is less
>> cluttered, and tab-completion (groups.<tab>) gives precise one-stop
>> shopping for examples of specific groups.
>
> I'm +1 to a group object like this, but removing things from the top level
> namespace is backwards incompatable and could break a lot of code out there.

What is wrong with using sage.misc.misc.deprecation?

> As for classes vs. methods, one advantage of classes is that sometimes
> certain methods can be simplified/optimized if you know what specific group
> you have.

I might be off on what you are trying to say, and I'm not fully pro
with gap but I believe depending class inheritance with group theory
is inherently too weak. Applicable methods installed into operations
that are dynamically chosen at runtime based on some fitness criteria
(what gap has) seems smarter than dynamic classes (operations chosen
by class hierarchy only). This applies specifically to group theory,
where there are many different ways to deal with groups, and some
properties are more important than others when dealing with different
functions.

http://www.gap-system.org/Manuals/doc/htm/tut/CHAP008.htm#SECT002

I might be a gap fan boy here, but having many attributes in a small
number of classes with many private functions that are called from
public ones seems more robust than an extremely large class hierarchy.

-bill

--
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

Re: [sage-devel] Mercurial - merging patch while keeping owner

On May 31, 2010, at 12:52 PM, Dr. David Kirkby wrote:

> On 05/31/10 05:51 PM, Robert Bradshaw wrote:
>> On May 30, 2010, at 2:27 PM, Dr. David Kirkby wrote:
>>
>>> On 05/30/10 10:10 PM, Mike Hansen wrote:
>>>> On Sun, May 30, 2010 at 2:04 PM, Dr. David Kirkby
>>>> <david.kirkby@onetel.net> wrote:
>>>>> 3) I want to add some patches.
>>>>>
>>>>> I've saved Robert's changes to files /tmp/robert1 and /tmp/
>>>>> robert2,
>>>>> but when
>>>>> I import them, hg log shows:
>>>>
>>>> How did you save the changes? You should do "hg export
>>>> 9be0b02f70c5>
>>>> /tmp/robert1" to get the patch along with the Mercurial info. You
>>>> should be able to import this with all of the metadata. If you do
>>>> "hg
>>>> qrefresh" on any of these patches (say to change a date or so),
>>>> then
>>>> the metadata will stay the same.
>>>>
>>>> --Mike
>>>>
>>>
>>> Thanks mike. I think I used just the '67' from the changeset
>>>
>>>
>>> changeset: 67:9be0b02f70c5
>>> user: Robert Bradshaw <robertwb@math.washington.edu>
>>> date: Tue May 25 01:14:41 2010 -0700
>>> summary: The -m64 flag is needed in OPT to build distutils
>>> extensions.
>>>
>>> and not the 'be0b02f70c5' bit. I must admit, I could be wrong. But
>>> it
>>> seems to have worked now doing what you say.
>>
>>
>> Another option, perhaps more natural from the distributed revision
>> control perspective, would be to just pull the changes in from one
>> repository to the other and merge. E.g.
>>
>> cd /new/repo
>> hg pull /old/repo
>
> Would that bring in all the changes from oldrepo? If so, it sounds a
> quicker way to do what I wanted.

Yep, that's what the command is for.

>
>> hg merge
>> hg commit
>>
>> Queues are nice too though, especially for "pulling" stuff from trac.
>>
>> - Robert
>
> I need to get to know Mercurial better, though I must admit, I often
> wished we used a central server so one did not have to keep rebasing
> packages. It gets a bit tedious.

We do have http://hg.sagemath.org/ , but that only gets updated at
release. It'd be nice to serve the alphas up there too (at least,
maybe even more fine grained) and also the spkg repositories.

- 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: Doctests failures of sage-4.4.3.alpha0 on Solaris 10 (SPARC) 32-bit

On 31 Mai, 20:23, "Dr. David Kirkby" <david.kir...@onetel.net> wrote:
> Building on my own Sun Blade 1000, then running
>
> 'make ptestlong', I get:
>
> The following tests failed:
>
>          sage -t  -long devel/sage/sage/graphs/generic_graph.py # 1 doctests failed

See ticket #9086.
http://trac.sagemath.org/sage_trac/ticket/9086

>          sage -t  -long devel/sage/sage/sets/set.py # 1 doctests failed

Same on Linux.

-Leif

--
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

Re: [sage-devel] Mercurial - merging patch while keeping owner

On 05/31/10 05:51 PM, Robert Bradshaw wrote:
> On May 30, 2010, at 2:27 PM, Dr. David Kirkby wrote:
>
>> On 05/30/10 10:10 PM, Mike Hansen wrote:
>>> On Sun, May 30, 2010 at 2:04 PM, Dr. David Kirkby
>>> <david.kirkby@onetel.net> wrote:
>>>> 3) I want to add some patches.
>>>>
>>>> I've saved Robert's changes to files /tmp/robert1 and /tmp/robert2,
>>>> but when
>>>> I import them, hg log shows:
>>>
>>> How did you save the changes? You should do "hg export 9be0b02f70c5>
>>> /tmp/robert1" to get the patch along with the Mercurial info. You
>>> should be able to import this with all of the metadata. If you do "hg
>>> qrefresh" on any of these patches (say to change a date or so), then
>>> the metadata will stay the same.
>>>
>>> --Mike
>>>
>>
>> Thanks mike. I think I used just the '67' from the changeset
>>
>>
>> changeset: 67:9be0b02f70c5
>> user: Robert Bradshaw <robertwb@math.washington.edu>
>> date: Tue May 25 01:14:41 2010 -0700
>> summary: The -m64 flag is needed in OPT to build distutils extensions.
>>
>> and not the 'be0b02f70c5' bit. I must admit, I could be wrong. But it
>> seems to have worked now doing what you say.
>
>
> Another option, perhaps more natural from the distributed revision
> control perspective, would be to just pull the changes in from one
> repository to the other and merge. E.g.
>
> cd /new/repo
> hg pull /old/repo

Would that bring in all the changes from oldrepo? If so, it sounds a quicker way
to do what I wanted.

> hg merge
> hg commit
>
> Queues are nice too though, especially for "pulling" stuff from trac.
>
> - Robert

I need to get to know Mercurial better, though I must admit, I often wished we
used a central server so one did not have to keep rebasing packages. It gets a
bit tedious.

--
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] Doctests failures of sage-4.4.3.alpha0 on Solaris 10 (SPARC) 32-bit

Building on my own Sun Blade 1000, then running

'make ptestlong', I get:

The following tests failed:

sage -t -long devel/sage/sage/graphs/generic_graph.py # 1 doctests failed
sage -t -long devel/sage/sage/schemes/elliptic_curves/BSD.py # 1
doctests failed
sage -t -long devel/sage/sage/sets/set.py # 1 doctests failed
----------------------------------------------------------------------
Total time for all tests: 24001.4 seconds
drkirkby@redstart:~/sage-4.4.3.alpha0$

How do these compare with what people are getting on Linux?

Is there anything that can be done about that timeout of test #2, when it gives
up on one algoritm and switches to another on slow machines?

Dave


1)
sage -t -long devel/sage/sage/server/notebook/conf.py (skipping) --
nodoctest.py file in directory
/Failed
"1" [label=" ", texlbl="$1$"];
"1/4" [label=" ", texlbl="$\frac{1}{4}$"];
"4/5" [label=" ", texlbl="$\frac{4}{5}$"];
"-4" [label=" ", texlbl="$-4$"];
"2" [label=" ", texlbl="$2$"];
"-2" [label=" ", texlbl="$-2$"];
"-1/2" [label=" ", texlbl="$-\frac{1}{2}$"];
"-1" [label=" ", texlbl="$-1$"];
<BLANKLINE>
"1/2" -> "-2" [label=" ", texlbl="$x \ {\mapsto}\ \frac{1}{x}$"];
"1/2" -> "2/3" [label=" ", texlbl="$x \ {\mapsto}\ \frac{1}{x + 1}$"];
"1" -> "-1" [label=" ", texlbl="$x \ {\mapsto}\ \frac{1}{x}$"];
"1" -> "1/2" [label=" ", texlbl="$x \ {\mapsto}\ \frac{1}{x + 1}$"];
"1/4" -> "-4" [label=" ", texlbl="$x \ {\mapsto}\ \frac{1}{x}$"];
"1/4" -> "4/5" [label=" ", texlbl="$x \ {\mapsto}\ \frac{1}{x + 1}$"];
"2" -> "-1/2" [label=" ", texlbl="$x \ {\mapsto}\ \frac{1}{x}$"];
"2" -> "1/3" [label=" ", texlbl="$x \ {\mapsto}\ \frac{1}{x + 1}$"];
}
**********************************************************************
1 items had failures:
1 of 20 in __main__.example_180
***Test Failed*** 1 failures.
For whitespace errors, see the file
/export/home/drkirkby/.sage//tmp/.doctest_generic_graph.py
[355.5 s]

2)
sage -t -long devel/sage/sage/graphs/base/graph_backends.py
[9.8 s]
/
ord_p(#Sha_an) = 2
Remaining primes:
p = 3: irreducible, surjective, non-split multiplicative
(0 <= ord_p <= 2)
[3]
Got:
p = 2: True by 2-descent
Timeout stopped Heegner index computation...
Proceeding to use heegner_index_bound instead.
True for p not in {2, 3} by Kolyvagin.
p = 3 may divide the Heegner index, for which only a bound was computed.
ALERT: p = 3 left in Kolyvagin bound
0 <= ord_p(#Sha) <= 2
ord_p(#Sha_an) = 2
Remaining primes:
p = 3: irreducible, surjective, non-split multiplicative
(0 <= ord_p <= 2)
[3]
**********************************************************************
1 items had failures:
1 of 35 in __main__.example_6
***Test Failed*** 1 failures.
For whitespace errors, see the file /export/home/drkirkby/.sage//tmp/.doctest_BSD.py
[133.8 s]

3)
sage -t -long devel/sage/sage/sets/set.py
**********************************************************************
File "/export/home/drkirkby/sage-4.4.3.alpha0/devel/sage-main/sage/sets/set.py",
line 316:
sage: Primes() < Set(QQ)
Expected:
True
Got:
False
**********************************************************************
1 items had failures:
1 of 7 in __main__.example_10
***Test Failed*** 1 failures.
For whitespace errors, see the file /export/home/drkirkby/.sage//tmp/.doctest_set.py
[11.5 s]

--
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

Re: [sage-devel] Mercurial - merging patch while keeping owner

On May 30, 2010, at 2:27 PM, Dr. David Kirkby wrote:

> On 05/30/10 10:10 PM, Mike Hansen wrote:
>> On Sun, May 30, 2010 at 2:04 PM, Dr. David Kirkby
>> <david.kirkby@onetel.net> wrote:
>>> 3) I want to add some patches.
>>>
>>> I've saved Robert's changes to files /tmp/robert1 and /tmp/
>>> robert2, but when
>>> I import them, hg log shows:
>>
>> How did you save the changes? You should do "hg export 9be0b02f70c5>
>> /tmp/robert1" to get the patch along with the Mercurial info. You
>> should be able to import this with all of the metadata. If you do
>> "hg
>> qrefresh" on any of these patches (say to change a date or so), then
>> the metadata will stay the same.
>>
>> --Mike
>>
>
> Thanks mike. I think I used just the '67' from the changeset
>
>
> changeset: 67:9be0b02f70c5
> user: Robert Bradshaw <robertwb@math.washington.edu>
> date: Tue May 25 01:14:41 2010 -0700
> summary: The -m64 flag is needed in OPT to build distutils
> extensions.
>
> and not the 'be0b02f70c5' bit. I must admit, I could be wrong. But
> it seems to have worked now doing what you say.


Another option, perhaps more natural from the distributed revision
control perspective, would be to just pull the changes in from one
repository to the other and merge. E.g.

cd /new/repo
hg pull /old/repo
hg merge
hg commit

Queues are nice too though, especially for "pulling" stuff from trac.

- 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] Sphinx target search...

Hi there,

Though sphinx is perfectly working with target in the local module he isn't
able to find reference target from other modules even if they are exported in
all.py. For example, if I want to link Parent from anywhere but parent.pyx, I
have to write the full path (ie. :class:`~sage.structure.parent.Parent`) even
if it is imported in my module. I find this extremely annoying since, in the
task of improving the category doc, I'm setting up a lot of huge cross
references such as:

:meth:`Algebras.ParentMethods.algebra_generators()
<sage.categories.algebras.Algebras.ParentMethods.algebra_generators>`.

I would be very happy if I had to write only

:meth:`Algebras.ParentMethods.algebra_generators`

Does anyone know if there is a way to have sphinx aware of all.py
or local import in a module ?

Thanks for any help,

Florent

--
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

Re: [sage-devel] Re: Fwd: [sage-combinat-devel] permutation group perspectives

On May 30, 2010, at 4:46 PM, Rob Beezer wrote:

> On May 30, 2:46 pm, Mike Hansen <mhan...@gmail.com> wrote:
>> I've been working on this over the next few days, cleaning up the
>> code, and making permutation groups act over an "arbitrary" domain.
>> I'll be posting these in the next few days.
>
> Mike H - thanks for your work on this!
>
> Mike O'S - that's a great wish list. I'd like to see lots of that
> happen. Another item on my wish list is to build a quotient group and
> have its elements (optionally) actually be cosets. Right now for
> permutation groups you get back a new permutation group:
>
> sage: D=DihedralGroup(7)
> sage: H=D.subgroup([D((1,2,3,4,5,6,7))])
> sage: Q=D.quotient(H)
> sage: Q.list()
> [(), (1,2)]
>
> Maybe with a new "coset" class and Mike's arbitrary domains this would
> be easy to implement?
>
> I've brought this one up before. How do folks feel about having the
> named permutation groups available like graphs are? In other words,
> rather than each family of permutation groups being a new class, there
> is a single system-wide object ("groups", or "perm_groups") whose
> methods produce instances of permutation groups (or more generally,
> just groups). So for example,
>
> D=groups.DihedralGroup(7)
>
> would replace the above syntax. Advantages - namespace is less
> cluttered, and tab-completion (groups.<tab>) gives precise one-stop
> shopping for examples of specific groups.

I'm +1 to a group object like this, but removing things from the top
level namespace is backwards incompatable and could break a lot of
code out there. As for classes vs. methods, one advantage of classes
is that sometimes certain methods can be simplified/optimized if you
know what specific group you have.

- 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

Re: [sage-devel] Re: Fwd: [sage-combinat-devel] permutation group perspectives

On May 30, 2010, at 3:33 PM, Jason B Hill wrote:

>
> Sweet!
>
> I'm assuming you're using a dictionary map? I think this could kill
> two birds with one stone. If we want to make Sage act more like GAP
> and consider the domain of a permutation group to be the collection
> of non-fixed points

To clarify, are you talking just about the case where a group it
constructed from a set of generators, or are you considering having
every construction figure out the set of fixed points and throw them
away? The former sounds fine, but I don't like the latter.

> (I think we should consider subgroups separately), then even in the
> case when the generators contain integers, those integers could be
> dictionaried (I think that's a word) into a compacted list of
> integers. In that situation, 99% of the existing methods could be
> used.
>
> I have some things to add to the subgroup discussion from farther
> up, and I'll be back from vacation on Wednesday. Unfortunately, this
> will be my last computer access until then. :-(
>
> Jason B. Hill
>
>
>
>
>
> On Sun, May 30, 2010 at 3:46 PM, Mike Hansen <mhansen@gmail.com>
> wrote:
> On Fri, May 21, 2010 at 5:58 PM, Jason B Hill <Jason.B.Hill@colorado.edu
> > wrote:
> > Can we get a list together of all of those who may be interested in
> > contributing to the rewrite of permutation groups on some level?
> We can move
> > to an in-depth discussion and inventory. I don't want to flood the
> > sage-devel list with too much, unless there are those who think the
> > discussion should remain here.
>
> I've been working on this over the next few days, cleaning up the
> code, and making permutation groups act over an "arbitrary" domain.
> I'll be posting these in the next few days.
>
> --Mike
>
> --
> You received this message because you are subscribed to the Google
> Groups "sage-combinat-devel" group.
> To post to this group, send email to sage-combinat-devel@googlegroups.com
> .
> To unsubscribe from this group, send email to sage-combinat-devel+unsubscribe@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en
> .
>
>
>
> --
> 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

--
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

Re: [sage-devel] Re: Sage 4.4.2 sources - Atlas failed to build

On 05/31/10 04:26 PM, MartinX wrote:
>>
>> You could try making a package using the latest (unstable) ATLAS snapshot. The
>> ChangeLog shows many new processors added since the release in Sage.
>>
>
> Successful build using ATLAS 2.9.24 directly on LAPACK 3.2.1 tar file
> today - no failures running checks and timing stages which is
> encouraging.

Yes

> Took a long time though.

Did it give messages about tuning? It can take about 5~10x as long to build if
it has to go through the tuning process

> While waiting have been trying
> make sense of the Sage fixes.

See my post, and this trac ticket

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

> I am considering a build using version of LAPACK used in Sage with
> ATLAS 3.8.3, but without the Sage fixes.
>
> Martin
>

If it works, then clearly one of the Sage "fixes" is not too good. That would
not totally surprise me.

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: Sage 4.4.2 sources - Atlas failed to build

>
> You could try making a package using the latest (unstable) ATLAS snapshot. The
> ChangeLog shows many new processors added since the release in Sage.
>

Successful build using ATLAS 2.9.24 directly on LAPACK 3.2.1 tar file
today - no failures running checks and timing stages which is
encouraging. Took a long time though. While waiting have been trying
make sense of the Sage fixes.

I am considering a build using version of LAPACK used in Sage with
ATLAS 3.8.3, but without the Sage fixes.

Martin

--
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] ATLAS - the package has modifications to upstream source.

I believe the ATLAS package has modifications to the upstream source code, as
some files in the 'patches' subdirectory are identical to those in the original
source code directory. This is now:

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

Furthermore, ATLAS was apparently updated to the latest upstream source code on
February 20th, 2009 (that's what SPKG.txt says), but some of the files in the
'src' directory have modification dates of June 22nd 2009 - some 4 months later.

I don't know for sure who is guilty here, but I've suspicion it might be me, as
'hg log' shows:

changeset: 53:41de1efe8559
user: Robert Miller <rlm@rlmiller.org>
date: Thu Jul 02 14:13:54 2009 -0700
summary: Checked in drkirkby's changes

changeset: 52:3acaaff52099
user: William Stein <wstein@gmail.com>
date: Tue Jun 02 14:30:03 2009 -0700
summary: fix FAT binary building so only impacts x86 boxes (e.g. not itanium!)

So it looks like I probably screwed up, and Robert did not notice and checked in
my changes.

Either way, I'll download the latest *stable* source 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

Re: [sage-devel] Name for NonNegativeIntegers

Note that there are many different rings of modular forms, not one,
but to be consistent we should probably change ModularFormsRing to
ModularFormRing. Compare also the general constructor PolynomialRing
which is not PolynomialsRing!

John

On 31 May 2010 11:59, Tim Joseph Dumol <tim@timdumol.com> wrote:
> On Mon, May 31, 2010 at 6:30 PM, Nicolas Borie <poutfou@gmail.com> wrote:
>>
>> Hello all!
>>
>> I have a language question: which one of the following is the correct
>> name for the semiring of non-negative integers:
>>
>>  - NonNegativeIntegerSemiring
>>  - NonNegativeIntegersSemiring
>>
>> On IRC, Tim suggested :
>> (12:15:44) nborie: English Language question : we say Integer Ring,
>> not Integers Ring. What about Non Negative Integers ? Non Negative
>> Integer(s) Semiring ?
>> (12:16:18) timdumol: Non-negative Integer Semiring
>> (12:16:45) timdumol: Plurals are not generally used (if at all) as
>> noun adjectives.
>
> To expand:
>
> Noun adjectives take the plural form only when they depict variety
> (different kinds/varieties) or when they are normally used in the plural
> form (sports, blues,...). As a Non-negative Integer Semiring does not
> contain multiple kinds of integers, it should take the singular form.
>
>>
>> I found both in sage :
>>
>>  - ModularFormsRing
>>  - IntegerRing
>>
>> Cheers,
>> Nicolas (the little).
>>
>> --
>> 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
>
>
>
> --
> Tim Joseph Dumol <tim (at) timdumol (dot) com>
> http://timdumol.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
>

--
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

Re: [sage-devel] Re: Sage 4.4.2 sources - Atlas failed to build

On 05/31/10 10:45 AM, Dr. David Kirkby wrote:
> On 05/31/10 01:58 AM, MartinX wrote:

>> PS I meant type i5-750 processor not 750i in the original post.
>
> I've never used such a processor myself, but I'm not surprised there are
> not tuning parameters as that processor is quite new. Fortunately, ATLAS
> does not have to tune on my 3.333 GHz Intel Xeon W3580, though I suspect
> there are no parameters that have actually been optimised for my Xeon,
> but there is probably some generic Xeon code.
>
> Dave

You could try making a package using the latest (unstable) ATLAS snapshot. The
ChangeLog shows many new processors added since the release in Sage.

I've posted below the bit of the changelog showing changes since the release of
ATLAS in Sage. Note however these are all in the 'unstable'. Also, creating a
new package will not be easy, as there are ton's of Sage-specific fixes to ATLAS

Nothing in here unfortunately looks as though it will resolve my Solaris issues,
but it might just resolve issues on your processor.

Dave

ATLAS 3.9.24 released 04/21/10, changes from 3.9.23:
* Should see a roughly doubling in performance of L2's SYR2/HER2
* Addition of new BLAS2.5-like kernel, GER2 (rank-2 update)
- A = alpha*x*y + beta*w*z + A
* Native ATLAS support for xGELS and all subsidiary routines, including
C and Fortran interfaces for GELS
- Internal routs not yet exposed in C/F77 iface include:
+ ORM[[QL,QR,LQ,RQ] -> UNM* called ORM for complex
+ GE[QL,QR,LQ,RQ]2 (unblocked QR)
+ GE[QL,QR,LQ,RQ]R (recursive QR)
+ LADIV, LAPY2, LAPY3
+ LARFB, LARFT (F77 ifaces, but no C ifaces)
+ LARF, LARFG, LARFP
+ LASCL (not supported for banded matrices)
- Of these, should definitely expose UNM/ORM at iface level
* Addition of [D,S]LAMCH for both C & F77 interfaces
* Fixed slvtst (LU & QR) to use norm of original A, not factored matrix
in computing solve residual
* Chad fixed a bug in the SSE generator in type casting for stores
* Changed it so unknown LAPACK routs are given ATLAS's NB for NB,
rather than 1
* Fixed bug in r1hgen.c where Level 1 & 2 blocking were hugely inflated
(leading to no effective blocking)
* Updated archinfo_linux to recognize "PPC970MP" as a G5
ATLAS 3.9.23 released 02/07/10, changes from 3.9.22:
* Fixed dependency error in ATLAS/makes/Make.mmtune
* Improved mmflagsearch, so we now have O(N) greedy search as default
-> if you pass -f gcc, will gen most opt-related gcc flags in gccflags.txt
* Improved flags used on PowerPC G4 & G5
* Updated some architectural defaults:
- Corei764SSE3, PPCG564AltiVec, PPCG4AltiVec, MIPSICE964
ATLAS 3.9.22 released 02/05/10, changes from 3.9.21
* Fixed long-standing bug in cleanup code generation -- this bug has been
in package since we've generated cleanup, and it causes malformed ifs
that select cleanup code; most commonly it creates uncompilable code,
but it could also result in using a suboptimal cleanup kernel.
* Fixed another long-standing bug in cleanup code generation, this
one involving not building enough fixed=1 clean cases if there are
higher imult cleanup cases in the Q. This resulted in errors in
cleanup answers.
* Complete rewrite of search for finding best generated kernel to use
new test/time infrastructure. See ATLAS/tune/blas/gemm/gmmsearch for
new search. Cleanup and no-copy still uses old search, which is renamed
ATLAS/tune/blas/gemm/mmcuncpsearch.c. New search driver is mmsearch.c
* Chad fixed several bugs in the SSE generator relating to type casting
* Fixed genparse's DupString to handle NULL pointers
* Fixed erroneous include of atlas_misc.h in clapack.h
* Added a compiler flag search to ease job of finding good flags.
- ATLAS/tune/blas/gemm/mmflagsearch.c
* Arch def changes:
- Updated G4 defs -- reduced perf due to gcc PPC performance bug
- Corei7464SSE3: negated ?MMRES.sum mflop values
- AMD64K10h64SSE3 : updated to new style
- Core264SSE3 : updated to new style
* Some PowerPC-specific fixes:
- Fixed it so configure can autodetect clock speed on G4/Linux
- Fixed it so ATLAS always assumes gnu gcc altivec handling on PowerPC
- Renamed vector registers to numbers just like GPRs (fixes Linux/PPC
assembly, and related altivec probe)
ATLAS 3.9.21 released 01/11/10, changes from 3.9.20
* Fixed error in threaded SYMM, where recursion had bad pointer
* Created ability to tune threaded/serial crossover points, see
ATLAS/tune/blas/gemm/txover.c
* Improved CacheEdge detection
* Fixed bug in configure for --shared on archs w/o f77 compiler
* Updated lanbtst to work wt new QR naming scheme, and to compile
correctly for lanbtime (was not using lapack's ILAENV in this case)
ATLAS 3.9.20 released 12/21/09, changes from 3.9.19
* Fixed bug in call to memcpy by casting all MulBySize to size_t
* Fixed several ilaenv-related errors, including QR always using serial parms
* Made it so ORMQR and UNMQR variants use QR's tuned NB
* Fixed error in complex gemoveT & gemoveC (src/auxil)
* Made gemoveT & C TLB-aware
* Added src/auxil/ATL_sqtrans to do TLB-aware in-place square transpose
* If M==N, then RQ & LQ (row-major) do in-place transpose and call
QL or QR (column-major). This gives ~10% performance improvement.
* Added F77 interface for xLARFT and xLARFB
ATLAS 3.9.19 released 12/08/09, changes from 3.9.18
* Got rid of files in C2F now being provided natively by ATLAS:
- larft, geqrf, geqlf, gerqf, gelqf, geqrf,
* Fixed duplication of unmqr_wrk symbols
* Removed use of SAFMIN global variable in larfb/larfg
ATLAS 3.9.18 released 12/05/09, changes from 3.9.17
* Found & fixed error in threaded GEMM
* Fixed bug where lanbtst_pt didn't set NB
* Modified mmksearch_sse.c to try gcc & sse flags if native compiler
can't handle the generated files.
* Rewrote LAPACK/QR NB tuning
- now uses ATLAS/tune/lapack/lanbsrch rather than bin/lanbtst (faster)
- Now done by default
* Numerous errors fixed involving architecture default timing (all levels)
* Modified atlas_install to keep track of times for every part of install,
so we can see where time is spent
* Architectural default related changes:
- Fixed ArchNew target in building arch defs to negate .sum files
- Core264SSE & AMD64K10h64SSE needed negative values in .sum files
- Updated Core264SSE, AMD64K10h64SSE, HAMMER64SSE3 to get new threaded
lapack, and full .sum support
ATLAS 3.9.17 released 11/15/09, changes from 3.9.16
* Chad's SSE GEMM generator now works for CGEMM
- Provides faster (CGEMM) arch defs for Core264SSE3
* Addition of householder factorizations (mostly written by Siju Samuel):
- F77 & C interface, C supports row/col- major
- GEQRF GEQLF GERQF GELQF
- tester is qrtst.c in ATLAS/bin/
- Retuned LAPACK's QR NB arch defs for AMD64K10h64SSE3 & Core264SSE3
* Fixed seg fault in ummsearch caused by mmksearch_sse failure
* Rewrote Write[MM,MV,R1]File to get around gcc bug
* Fixed bugs in ATLAS/src/auxil/[ge,tr]collapse
* Fixed bug in ATLAS/tune/blas/ger/CASES/ATL_zgerk_1x4_sse3.c
* Renamed xatlas_install -> xatlas_build, to get around Windows 7
"security-through-stupidity" misfeature
ATLAS 3.9.16 released 10/17/09 (bugfix release), changes from 3.9.15
* Fixed bugs in mmksearch_sse.c for machines w/o SSE3
* Fixed errors in C2F preventing full lapack install
* Fixed error in atlas_install trying to open wrong filename in latune
* Fixed error in mmsearch's FindNoCopyNB where latency computed incorrectly
* Numerous errors related to new architectural default handling
* New architectural defaults for:
- AMD64K10h64SSE3
- Core264SSE3
- Corei764SSE3
ATLAS 3.9.15 released 10/10/09, changes from 3.9.14
* Addition of Chad Zalkin's SSE GEMM generator to ATLAS
* Support for external searches and use of standard matmul search routs in:
- include/atlas_mmparse.h
- include/atlas_mmtesttime.h
* Numerous search changes to incorporate above in ATLAS matmul install
- Changed matmul install to be much quieter
ATLAS 3.9.14 released 08/19/09 (bugfix release), changes from 3.9.13
* Fixed complex indexing errors in ATL_ger.c & ATL_zgerk_1x4_sse3.c
* Fixed error in config.c where using LAPACK caused OpenMP to be built
* Made it so C2F LAPACK interface only built if F77 LAPACK is provided
* Basic --shared install now works (tested Linux build only)
ATLAS 3.9.13 released 08/17/09 (bugfix release), changes from 3.9.12
* Fixed ATL_smm14x1x84_sseCU.c so it won't be used when NB > 84
- fixed AMD64 arch def not to use it
* Fixed 1-character memory overwrite in atlas_genparse.h's DupString
* Added prototype to r1ktest.c
* 3.9.12 showed version of 3.9.11; this version shows correct 3.9.13
ATLAS 3.9.12 released 08/06/09, changes from 3.9.11
* Complete rewrite of GER, SYR/HER and SYR2/HER2:
- New tuning mechinism tunes GER for in-L1, in-L2, and out-of-cache
* Call ATL_<pre>ger_L1 if data known to be in L1 cache
* Call ATL_<pre>ger_L2 if data known to be in L2 cache
- Most architectures now lack GER arch defs
* Provided GER archdefs 64-bit K10h and Core2
- atlas_devel not yet updated
* Relatively untested standard timing/tester code available for all
tuned kernels (GER fairly well tested)
- atlas_[mv,r1,mm]parse.h reads standard input/output files
- atlas_[mv,r1,mm]testtime.h provides tester/timer calls for kernels
* Can compile both lapack 3.2 and 3.1 with --with-netlib-lapack-tarfile
- Removed support for other ways of building lapack
- atlas_install mostly updated
* Bug fixes
- Fixed BETA=0 SCAL NaN-propogation bug (no more call to ATL_set)
- Fixed C/Z GEMM JITcp bug where C was read when BETA=0
- Fixed threaded LAPACK calling serial ilaenv (QR speedup)
ATLAS 3.9.11 released 04/07/09, changes from 3.9.10
* Added flags -Si [omp,antthr] 0/1/2 to allow ease of building ATLAS
with alternative threading implementations
* Fixed prototypes in atlas_f77wrap.h so that all thread interfaces
are properly prototyped when they are selected by the above flags
* Fixed missing TRMM prototype in atlas_tlvl3.h that caused STRSM
to fail tests in xsl3blastst_pt
ATLAS 3.9.10 released 03/11/09, changes from 3.9.9
* Rewrote tgemm's combine routine to work on arbitrary partitionings
combined in arbitrary orders (necessary for non-power-of-2 processors)
- Restricted fix for SYRK (not general, as it isn't needed yet)
* Fixed bug in EnforceNonPwr2LO caused by failure to rename moved
structure in the Cinfp array
* Fixed makefile problem that caused ATLAS to re-archive the L3BLAS for
every tester compile
* On windows, added -lkernel32 to LIBS macro to enable shared lib build
ATLAS 3.9.9 released 02/26/09, changes from 3.9.8
* Fixed bug in Xtsyrk's ATL_tsyrkdecomp_K, both on when the algorithm
is used, and correctness for when K is not large enough to give all
processors NB of work.
* Fixed bug in lanbtst, where single precision (S/C) used double values
rather than single values when determining workspace requirements
* Changed atlas_install to have a final library build phase
- Was not rebuilding lib after post-build tuning
-> Caused lapack and poss other files to be untuned unless user rebuilds
by invoking tester/timer for each subpiece
-> Caused dynamic libs to be built from badly tuned libs
* Added missing lapack arch defs for Corei764 and MIPSICE9
ATLAS 3.9.8 released 02/23/09, changes from 3.9.7
* Fixed bug in ATL_Xtgemm where ATL_thrdecompMM failed to return the
number of processors on non-power-of-2 processor systems
* Fixed bug in ATL_tsyrk where I was calling the K-splitting routine
when the required workspace was large, rather than when it was small.
* Fixed analagous problem in ATL_tsyrk as the 3.9.7 did for ATL_tgemm;
however, tsyrk bug could not have been exercised by current decomposition.
* Introduced some fixes & workarounds for SiCortex/MIPSICE9:
- Changed default MIPSICE9 compiler back to gcc, since pathcc produces
bad ATL_tsyrk when optimization is above -O1 (confirmed compiler error)
* Added dependence on atlas_ptalias3.h in cblas interface Makefile.
ATLAS 3.9.7 released 02/20/09, changes from 3.9.6:
* Fixed bug in ATL_tgemm that caused seg faults for some small-M tGEMMs
* Added architectural defaults for K7323DNow (Athlon "classic")
ATLAS 3.9.6 released 02/01/09, Changes from 3.9.5:
* Made it so LAPACK is tuned specifically for threading as well as for serial
- Added threaded lapack arch defs for:
+ Core264SSE3, P4E64SSE3, Corei764SSE3
* Made it so LAPACK NB-tuning is mu/nu aware
* MIPSICE9 (sicortex) improvements:
- added pathcc arch defs
- updated gcc arch defs to better values
--> Still getting errors on this platform
* Some bug fixes:
- Detect model 29 as Core2
- Rewrote ptFlushAreasByCL to use new thread framework
- Fixed handling of non-power-of-2 number of threads
- Better dependencies for building ilaenv
ATLAS 3.9.5 released 12/11/08, Changes from 3.9.4:
* Complete rewrite of ATLAS threading system:
- Now supports native windows threads in addition to pthreads
- Use of master-last and affinity increases threaded performance, with
an advantage that grows with P (almost no advantage for P=2, but for
instance LU is more than 60% faster asymptotically on a P=8 Core2)
+ OS X and FreeBSD don't support processor affinity, and so their
performance is still bad
- Cacheedge specifically tuned for threading (another 5%)
* Changed emit_buildinfo so that it replaces all control characters with
spaces (prevents errors under windows).
* Added dependency info for ATL_ilaenv so that it is recompiled once
lapack tuning is complete
* Fixed error in configure where it issues commands in wrong directory
when the user builds lapack directly from a tarfile
* Fixed typos in config.c where I used 'comp' rather than 'comps'.
* Added mmtime_pt.c, which can allow us to find kernels that do well
in parallel operation.
* Various small configure fixes for windows
ATLAS 3.9.4 released 09/06/08, Changes from 3.9.3:
* Improved Windows/cygwin configure with addition of archinfo_win.c
* Added basic support for Windows/interix
- Did not pursue much due to widespread seg fault in gcc, hundreds of
hard-to-get "hot fixes", and ancient gnu tools that can't assemble SSE3
* Removed special "no-need-to-copy" cases from ATLmm_JIK/IJK.c, since they
occasionally seem to cause large performance drops.
* Changed it so JIK matmul always called for rank-K update, in order to
reduce access costs on C.
* Fixed several errors in ATLAS's ILAENV.
* Fixed several errors in configure
* Fixed error when -Ss lasrc is given as relative rather than absolute path
* Added BETA support for auto-building shared/dynamic libraries when the
user passes --shared to configure (no need to explicitly set compiler
flags [eg., -fPIC] for any of the known compilers):
- Not fully tested, but appears to work for Windows, OS X and Linux
- Now referenced in make install, but present process is crude
- with --nof77, get clapack reather than lapack; eventually probably want
a logical link of lapack


--
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

Re: [sage-devel] Name for NonNegativeIntegers

On Mon, May 31, 2010 at 6:30 PM, Nicolas Borie <poutfou@gmail.com> wrote:
Hello all!

I have a language question: which one of the following is the correct
name for the semiring of non-negative integers:

 - NonNegativeIntegerSemiring
 - NonNegativeIntegersSemiring

On IRC, Tim suggested :
(12:15:44) nborie: English Language question : we say Integer Ring,
not Integers Ring. What about Non Negative Integers ? Non Negative
Integer(s) Semiring ?
(12:16:18) timdumol: Non-negative Integer Semiring
(12:16:45) timdumol: Plurals are not generally used (if at all) as
noun adjectives.

To expand:

Noun adjectives take the plural form only when they depict variety (different kinds/varieties) or when they are normally used in the plural form (sports, blues,...). As a Non-negative Integer Semiring does not contain multiple kinds of integers, it should take the singular form.
 

I found both in sage :

 - ModularFormsRing
 - IntegerRing

Cheers,
Nicolas (the little).

--
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



--
Tim Joseph Dumol <tim (at) timdumol (dot) com>
http://timdumol.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] Name for NonNegativeIntegers

Hello all!

I have a language question: which one of the following is the correct
name for the semiring of non-negative integers:

- NonNegativeIntegerSemiring
- NonNegativeIntegersSemiring

On IRC, Tim suggested :
(12:15:44) nborie: English Language question : we say Integer Ring,
not Integers Ring. What about Non Negative Integers ? Non Negative
Integer(s) Semiring ?
(12:16:18) timdumol: Non-negative Integer Semiring
(12:16:45) timdumol: Plurals are not generally used (if at all) as
noun adjectives.

I found both in sage :

- ModularFormsRing
- IntegerRing

Cheers,
Nicolas (the little).

--
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

Re: [sage-devel] Re: Sage 4.4.2 sources - Atlas failed to build

On 05/31/10 01:58 AM, MartinX wrote:

> Luck was never my strong point. nothing like a problem to get one up
> the learning curve though.

True

> If I do fix it I'll post back here.

That would be good. Do you have a trac account? If so, can you create a ticket
for this. If not, either I can create the ticket, but it is better if you
request an account from William and create the ticket yourself.

> PS I meant type i5-750 processor not 750i in the original post.

I've never used such a processor myself, but I'm not surprised there are not
tuning parameters as that processor is quite new. Fortunately, ATLAS does not
have to tune on my 3.333 GHz Intel Xeon W3580, though I suspect there are no
parameters that have actually been optimised for my Xeon, but there is probably
some generic Xeon 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

Re: [sage-devel] Re: Is there a linbox / BLAS dependency missing in 'deps'?

On 05/31/10 10:17 AM, Dr. David Kirkby wrote:

> It might be different on 't2' (I've not tried), since ATLAS of the T2+
> processors on 't2.math', whereas ATLAS is aware of the older UltraSPARC
> III+ processors I have.

What I mean is ATLAS is unaware of the T2+ processors, whereas it has
information about the UltraSPARC III+ processors. That's why it takes so long to
build on 't2'

ATLAS seems to be a bit problematic in Sage, with many of these issues
outstanding a long time.

* I have this problem.
http://trac.sagemath.org/sage_trac/ticket/9101

* MartinX is finding it is not building on his i5-750 processor processor.
(we need to create a trac ticket for that. Does MartinX have an account?)

* There is no tuning information on the T2+ processors on 't2.math'
http://trac.sagemath.org/sage_trac/ticket/6705

* On 't2,math' ATLAS dumps core in one of the tuning routines, so we have a hack
which returns a reasonable (unoptimised) value from the tuning routine
http://trac.sagemath.org/sage_trac/ticket/6276

* ATLAS ignore CC variable and dumps core if one tries to build with SunStudio
http://trac.sagemath.org/sage_trac/ticket/7048

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

Re: [sage-devel] Re: Is there a linbox / BLAS dependency missing in 'deps'?

On 05/31/10 05:52 AM, William Stein wrote:
>> I've never had this problem building on 32-bit SPARC, or 64-bit OpenSolaris
>> x64. I only see it on 64-bit Solaris 10 SPARC. Perhaps the behavior is
>> undefined if the dependency is missing, and it just happens by luck to work
>> on the other systems. Either that, or I've mis-understood it.
>
> I think you've found a bug in the makefile.
>
> We have
>
> LINBOX depends on ATLAS
>
> ATLAS depends on LAPACK and PYTHON
>
> LAPACK depends on FORTRAN
>
>
> It is just a *lucky coincidence* that the Sage build has actually worked.
> We need to add BLAS as a dependency of LAPACK, e.g,.
>
> $(INST)/$(LAPACK): $(INST)/$(FORTRAN) $(INST)/$(BLAS)
> $(SAGE_SPKG) $(INST)/$(LAPACK) 2>&1
>
> Then everything should work fine, since depence is transitive.
>
> William

That may be so, (Francois seems to have another opinion though). But it is
certainly not the only issue on Solaris. If, as Francois says, Linbox prefers
ATLAS, then I think I know why Linbox is not finding ATLAS on Solaris 10 with a
SPARC processor in 64-bit mode.

1) On Solaris 10 SPARC, *without* SAGE64 being set to "yes" (the normal
build-mode on 't2'), ATLAS builds a 32-bit library, as one would expect.

2) On OpenSolaris x64, with SAGE64 set to "yes" (what I believe will be the
normal build mode for OpenSolaris x64), ATLAS builds 64-bit as one would want.

3) However, on Solaris 10 SPARC, with SAGE64 set to "yes", ATLAS is building
32-bit, despite most other packages building 64-bit on that system. I expect
linbox reports the message as it can't find a suitable 64-bit BLAS library, only
an unsuitable 32-bit one.

'cblas' is also building 32-bit when it should be building 64-bit, so Linbox
will not find a suitable 'cblas' either.

So MartinX is not the only one with ATLAS problems with his i5-750 processor - I
seem to have found a problem on the SPARC processor if one tries to build 64-bit
code.

It might be different on 't2' (I've not tried), since ATLAS of the T2+
processors on 't2.math', whereas ATLAS is aware of the older UltraSPARC III+
processors I have. ATLAS *might* build differently on two otherwise similar
SPARC systems. It certianly spends an eternity building on 't2', whereas it is
nothing like as slow on my SPARC system.

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: math equation editor

> Although I am used to learning the hard way, I
> find that there are few free resources (as in beer) for learning
> JavaScript, so I don't really know how to start with the existing
> code.
These are nice, though not definitive:

https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide
https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference

--
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

Re: [sage-devel] Re: Is there a linbox / BLAS dependency missing in 'deps'?

> I think you've found a bug in the makefile.
>
> We have
>
> LINBOX depends on ATLAS
>
> ATLAS depends on LAPACK and PYTHON
>
> LAPACK depends on FORTRAN
>
>
> It is just a lucky coincidence that the Sage build has actually worked.
> We need to add BLAS as a dependency of LAPACK, e.g,.
>
> $(INST)/$(LAPACK): $(INST)/$(FORTRAN) $(INST)/$(BLAS)
> $(SAGE_SPKG) $(INST)/$(LAPACK) 2>&1
>
> Then everything should work fine, since depence is transitive.
Can you remind me again why we have BLAS and not just ATLAS?
We can just build lapack against ATLAS.

Francois

--
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

A paper of MPACK in Japanese has been uploaded (Re: [sage-devel] Re: multiprecision linear algebra)

Hi,
just FYI..
I uploaded a paper of http://accc.riken.jp/maho/slides/mpack-0.6.4.pdf (sorry in Japanese)

thanks
-- Nakata Maho http://accc.riken.jp/maho/ , JA OOO http://ja.openoffice.org/
http://blog.goo.ne.jp/nakatamaho/ ,GPG: http://accc.riken.jp/maho/maho.pgp.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

วันอาทิตย์ที่ 30 พฤษภาคม พ.ศ. 2553

[sage-devel] Re: Is there a linbox / BLAS dependency missing in 'deps'?

On Sun, May 30, 2010 at 8:52 PM, Dr. David Kirkby
<david.kirkby@onetel.net> wrote:
> Trying to build Sage 4.3.2 on Solaris 10 (SPARC), as a 64-bit build (my
> first semi-serious attempt at 64-bit SPARC build), I get a failure:
>
> checking for C interface to BLAS... not found
>  checking for others BLAS... not found
>
>  *******************************************************************************
>  ERROR: BLAS not found!
>
>  BLAS routines are required for this library to compile. Please
>  make sure BLAS are installed and specify its location with the option
>  --with-blas=<lib> when running configure.
>  *******************************************************************************
>  Error configuring linbox
>
>  real    0m32.070s
>  user    0m15.156s
>  sys     0m12.915s
>  sage: An error occurred while installing linbox-1.1.6.p3
>
> http://trac.sagemath.org/sage_trac/ticket/9101
>
> Looking in spkg/standard/deps, I don't see anything to force BLAS to build
> before linbox.
>
>
> $(INST)/$(LINBOX): $(BASE) $(INST)/$(MPIR) $(INST)/$(NTL) $(INST)/$(GIVARO)
> $(INST)/$(GSL) $(INST)/$(ATLAS)
>        $(SAGE_SPKG) $(LINBOX) 2>&1
>
> It's strange I've never come across this before on a 32-bit build on the
> same machine, yet the BLAS libraries are not installed as far as I'm aware.
>
> drkirkby@redstart:~$ ls /usr/lib/*blas* /lib/*blas*
> /usr/lib/*blas*: No such file or directory
> /lib/*blas*: No such file or directory
>
> I've never had this problem building on 32-bit SPARC, or 64-bit OpenSolaris
> x64. I only see it on 64-bit Solaris 10 SPARC. Perhaps the behavior is
> undefined if the dependency is missing, and it just happens by luck to work
> on the other systems. Either that, or I've mis-understood it.

I think you've found a bug in the makefile.

We have

LINBOX depends on ATLAS

ATLAS depends on LAPACK and PYTHON

LAPACK depends on FORTRAN


It is just a *lucky coincidence* that the Sage build has actually worked.
We need to add BLAS as a dependency of LAPACK, e.g,.

$(INST)/$(LAPACK): $(INST)/$(FORTRAN) $(INST)/$(BLAS)
$(SAGE_SPKG) $(INST)/$(LAPACK) 2>&1

Then everything should work fine, since depence is transitive.

William

--
William Stein
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

Re: [sage-devel] Is there a linbox / BLAS dependency missing in 'deps'?

> Trying to build Sage 4.3.2 on Solaris 10 (SPARC), as a 64-bit build (my
> first semi-serious attempt at 64-bit SPARC build), I get a failure:
>
> checking for C interface to BLAS... not found
> checking for others BLAS... not found
>
>
> **************************************************************************
> ***** ERROR: BLAS not found!
>
> BLAS routines are required for this library to compile. Please
> make sure BLAS are installed and specify its location with the option
> --with-blas=<lib> when running configure.
>
> **************************************************************************
> ***** Error configuring linbox
>
> real 0m32.070s
> user 0m15.156s
> sys 0m12.915s
> sage: An error occurred while installing linbox-1.1.6.p3
>
> http://trac.sagemath.org/sage_trac/ticket/9101
>
> Looking in spkg/standard/deps, I don't see anything to force BLAS to build
> before linbox.
>
>
> $(INST)/$(LINBOX): $(BASE) $(INST)/$(MPIR) $(INST)/$(NTL) $(INST)/$(GIVARO)
> $(INST)/$(GSL) $(INST)/$(ATLAS)
> $(SAGE_SPKG) $(LINBOX) 2>&1
>
> It's strange I've never come across this before on a 32-bit build on the
> same machine, yet the BLAS libraries are not installed as far as I'm
> aware.
>
> drkirkby@redstart:~$ ls /usr/lib/*blas* /lib/*blas*
> /usr/lib/*blas*: No such file or directory
> /lib/*blas*: No such file or directory
>
> I've never had this problem building on 32-bit SPARC, or 64-bit OpenSolaris
> x64. I only see it on 64-bit Solaris 10 SPARC. Perhaps the behavior is
> undefined if the dependency is missing, and it just happens by luck to
> work on the other systems. Either that, or I've mis-understood it.
>
ATLAS is a blas implementation and linbox prefer that one - along with the
clapack shipped with it. So if atlas is installed you should have libcblas
and linbox definitely should detect it.

Francois

--
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] Is there a linbox / BLAS dependency missing in 'deps'?

Trying to build Sage 4.3.2 on Solaris 10 (SPARC), as a 64-bit build (my first
semi-serious attempt at 64-bit SPARC build), I get a failure:

checking for C interface to BLAS... not found
checking for others BLAS... not found

*******************************************************************************
ERROR: BLAS not found!

BLAS routines are required for this library to compile. Please
make sure BLAS are installed and specify its location with the option
--with-blas=<lib> when running configure.
*******************************************************************************
Error configuring linbox

real 0m32.070s
user 0m15.156s
sys 0m12.915s
sage: An error occurred while installing linbox-1.1.6.p3

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

Looking in spkg/standard/deps, I don't see anything to force BLAS to build
before linbox.


$(INST)/$(LINBOX): $(BASE) $(INST)/$(MPIR) $(INST)/$(NTL) $(INST)/$(GIVARO)
$(INST)/$(GSL) $(INST)/$(ATLAS)
$(SAGE_SPKG) $(LINBOX) 2>&1

It's strange I've never come across this before on a 32-bit build on the same
machine, yet the BLAS libraries are not installed as far as I'm aware.

drkirkby@redstart:~$ ls /usr/lib/*blas* /lib/*blas*
/usr/lib/*blas*: No such file or directory
/lib/*blas*: No such file or directory

I've never had this problem building on 32-bit SPARC, or 64-bit OpenSolaris x64.
I only see it on 64-bit Solaris 10 SPARC. Perhaps the behavior is undefined if
the dependency is missing, and it just happens by luck to work on the other
systems. Either that, or I've mis-understood it.

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

Re: [sage-devel] Many small patches need review - please help.

On 05/31/10 02:52 AM, Dr. David Kirkby wrote:

> http://trac.sagemath.org/sage_trac/ticket/9034 (flintqs)
> http://trac.sagemath.org/sage_trac/ticket/8089 (ECL)
>
> are both particularly easy, though none of them are rocket science.

I realised the ECL one should not be reviewed, as I'd already got positive
review for

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

which is an updated ECL, which does not have the problem.

So unfortunately, one of the easiest tickets to review now no longer needs
reviewing! Sods law.

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] Many small patches need review - please help.

I've got 11 ticket which need review. They are designed to allow Sage to build
on 64-bit OpenSolaris. Most of the patches just involve adding the -m64 flag to
the compiler flags. If anyone wants to review one or two, I'd appreciate it. You
don't really need an OpenSolaris machine to test these on.

There's a list of all the patches on this ticket.

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

which I'm using to track the outstanding OpenSolaris issues.


http://trac.sagemath.org/sage_trac/ticket/9034 (flintqs)
http://trac.sagemath.org/sage_trac/ticket/8089 (ECL)

are both particularly easy, though none of them are rocket science.

Most have only a few lines of code - the number of comments I add usually
exceeds the amount of code.

FWIW, there are still about 8 outstanding OpenSolaris issues, and most of them
are non-trivial problems.

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: Sage 4.4.2 sources - Atlas failed to build

On May 30, 10:20 pm, "Dr. David Kirkby" <david.kir...@onetel.net>
wrote:

>
> It looks to me like ATLAS does not know about your CPU, so is running it's
> tuning routine, then somehow manages to screw up when it creates the file with
> tuning parameters. I've no idea why that might be.
>
> Ideally what you would want to do is to get some parameters, get them saved,
> then it will avoid the tuning process each time. Easier said than done though -
> I've never worked out how to do it myself. If I could, I could reduce the
> build-time on 't2.math.washington.edu' significantly - seehttp://trac.sagemath.org/sage_trac/ticket/6705
>

Ok. I'll investigate

> Take note of that error file.
>
> Good luck! When ATLAS goes wrong, it is hard to work out what to do.
>
> Dave

Luck was never my strong point. nothing like a problem to get one up
the learning curve though. If I do fix it I'll post back here. Thanks
for you help

Martin

PS I meant type i5-750 processor not 750i in the original post.

--
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: math equation editor

It now seems evident to me that this is no trivial task. Davide has
replied to my mail and wisely adviced me not to take this as my first
JavaScript project. Although I am used to learning the hard way, I
find that there are few free resources (as in beer) for learning
JavaScript, so I don't really know how to start with the existing
code.

I made a program that takes text in firefox, processes it, and
displays it in realtime. But I have no idea how to make nice
mathematical expressions to appear.

Nevertheless I feel like this should be a top priority for developers,
as it would make Sage a lot more usable. Does anybody want to develop
this?

I guess I'll go back to writing plotting stuff for sage.

thanks!

Oscar

On 30 mayo, 13:35, William Stein <wst...@gmail.com> wrote:
> On Sun, May 30, 2010 at 11:02 AM, Oscar Lazo <algebraicame...@gmail.com> wrote:
> > On 30 mayo, 12:40, William Stein <wst...@gmail.com> wrote:
> >> Excellent!  If I can help some, I will.
>
> >> I've corresponded with David (the author) about the that math editor before,
> >> and he was very discouraging, saying it wasn't done yet, might be done soon,
> >> etc. (years ago).   Make sure you make a copy, in case the above webpage
> >> disappears.
>
> >> William
>
> > I am very sorry to hear that. I tried to save the site but the editor
> > won't work from a
> > file in my computer. I get an error message:
>
> > Unknown control sequence '\cssId'
>
> > It will be a lot more difficult to do everything again (which will
> > very likely be necessary
> > if I can't get some explanations about how the code works). If that is
> > the case, then
> > I would like to hear some suggestions about how to implement things
> > (language, approach,
> > etc.)
>
> > Also, I can't seem to find decent JavasScript material. If you people
> > can provide some that
> > would also be very helpful.
>
> For learning the Javascript *language*, I like this book:
>
>    http://oreilly.com/catalog/9780596517748
>
>
>
> > Thank you
>
> > Oscar
>
> > --
> > 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 athttp://groups.google.com/group/sage-devel
> > URL:http://www.sagemath.org
>
> --
> William Stein
> 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

[sage-devel] Re: Fwd: [sage-combinat-devel] permutation group perspectives

On May 30, 2:46 pm, Mike Hansen <mhan...@gmail.com> wrote:
> I've been working on this over the next few days, cleaning up the
> code, and making permutation groups act over an "arbitrary" domain.
> I'll be posting these in the next few days.

Mike H - thanks for your work on this!

Mike O'S - that's a great wish list. I'd like to see lots of that
happen. Another item on my wish list is to build a quotient group and
have its elements (optionally) actually be cosets. Right now for
permutation groups you get back a new permutation group:

sage: D=DihedralGroup(7)
sage: H=D.subgroup([D((1,2,3,4,5,6,7))])
sage: Q=D.quotient(H)
sage: Q.list()
[(), (1,2)]

Maybe with a new "coset" class and Mike's arbitrary domains this would
be easy to implement?

I've brought this one up before. How do folks feel about having the
named permutation groups available like graphs are? In other words,
rather than each family of permutation groups being a new class, there
is a single system-wide object ("groups", or "perm_groups") whose
methods produce instances of permutation groups (or more generally,
just groups). So for example,

D=groups.DihedralGroup(7)

would replace the above syntax. Advantages - namespace is less
cluttered, and tab-completion (groups.<tab>) gives precise one-stop
shopping for examples of specific groups.

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] Cygwin - think about 64-bit too.

I know Mike and William are working on the Cygwin port now (perhaps others are
too).

I believe the initial port is going to be 32-bit, which is all I belive Cygwin
supports now. It is certainly not beyond the bounds of possibility that a 64-bit
version of Cygwin becomes available.


So I would consider the implication of your changes if SAGE64 is set to "yes".

Micheal originally only allowed that environment variable to work on OS X, which
was a bit stupid, considering he was paid to work on the Solaris port, and
Solaris needs that option too! Virtually all packages in Sage should now add
-m64 as a compiler flag if SAGE64 is set to yes.

I would consider that while making patches for Cygwin. I can assure you, there
is nothing more boring than going around making changes to permit a 64-bit
build, when with foresight you could have avoided the hassle.

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

Re: [sage-devel] Re: Fwd: [sage-combinat-devel] permutation group perspectives


Sweet!

I'm assuming you're using a dictionary map? I think this could kill two birds with one stone. If we want to make Sage act more like GAP and consider the domain of a permutation group to be the collection of non-fixed points (I think we should consider subgroups separately), then even in the case when the generators contain integers, those integers could be dictionaried (I think that's a word) into a compacted list of integers. In that situation, 99% of the existing methods could be used.

I have some things to add to the subgroup discussion from farther up, and I'll be back from vacation on Wednesday. Unfortunately, this will be my last computer access until then. :-(

Jason B. Hill





On Sun, May 30, 2010 at 3:46 PM, Mike Hansen <mhansen@gmail.com> wrote:
On Fri, May 21, 2010 at 5:58 PM, Jason B Hill <Jason.B.Hill@colorado.edu> wrote:
> Can we get a list together of all of those who may be interested in
> contributing to the rewrite of permutation groups on some level? We can move
> to an in-depth discussion and inventory. I don't want to flood the
> sage-devel list with too much, unless there are those who think the
> discussion should remain here.

I've been working on this over the next few days, cleaning up the
code, and making permutation groups act over an "arbitrary" domain.
I'll be posting these in the next few days.

--Mike

--
You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to sage-combinat-devel+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.


--
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