Travis Scrimshaw tsc...@ucdavis.edu writes:
Martin,
You mentioned that you had code for variants of RSK, could you
repost/reference that?
I have no time until next week for cleaning but it's a start.
The domino insertion is currently only there as code for fricas (done by
a student,
Hi --
I just got back to the problem that I would like to have the maximal
elements in what is currently called PairwiseCompatibleSubsets (and
this is at least the n-th time I am getting back to this). So I wonder
if anyone is going to look at this within finite time, or if I should
find a
Hi Travis,
I've upgraded, so feel free to push your changes and I'll rebase #13605 as
needed.
I don't have anything to push, I am fine with the queue as is...
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To post to this group, send
On 2012-11-27, Travis Scrimshaw tsc...@ucdavis.edu wrote:
--=_Part_468_5000489.1354057101700
Content-Type: text/plain; charset=ISO-8859-1
Hey everyone,
I've been trying to figure out how to handle generalized
permutations (a.k.a. two-line arrays, bi-words, ...) since we want
Helloo everybody !!!
since we want Permutation() to only accept input from 1 to n. In
particular
Well, I do not want Permutations to be defined on 1...n only. First,
because I ideally would like them to be defined on 0...(n-1), and then
because of course I would like them to be
Right. It's probably better to use IterableFunctionCall: then it would
not fill up the memory at construction time. Of course the fill up
will eventually occur when running through the CartesianProduct; but
then the caller is just getting what he asked for :-)
In fact, Vincent's
On 11/28/12 5:35 AM, Dima Pasechnik wrote:
On 2012-11-27, Travis Scrimshaw tsc...@ucdavis.edu wrote:
--=_Part_468_5000489.1354057101700
Content-Type: text/plain; charset=ISO-8859-1
Hey everyone,
I've been trying to figure out how to handle generalized
permutations (a.k.a. two-line
On 2012-11-28, Anne Schilling a...@math.ucdavis.edu wrote:
On 11/28/12 5:35 AM, Dima Pasechnik wrote:
On 2012-11-27, Travis Scrimshaw tsc...@ucdavis.edu wrote:
--=_Part_468_5000489.1354057101700
Content-Type: text/plain; charset=ISO-8859-1
Hey everyone,
I've been trying to figure out
Helloo !!
I guess it's a perfect illustration of **limits** of the object-oriented
approach.
RSK takes (p,q) in PxQ and outputs (a,b) in AxB.
Does this mean we have to knock ourselves out creaing classes for each
pair of classes P,Q we have?
NOooo ! We have
On 2012-11-28, Nathann Cohen nathann.co...@gmail.com wrote:
--bcaec5171ecd442ad804cf90b70b
Content-Type: text/plain; charset=ISO-8859-1
Helloo !!
I guess it's a perfect illustration of **limits** of the object-oriented
approach.
RSK takes (p,q) in PxQ and outputs (a,b) in AxB.
Hi there,
I found this:
sage: c = CartanType([[A,2]])
sage: c.is_irreducible()
False
And it has further nasty consequences:
sage: c.cartan_matrix()
---
ValueErrorTraceback
On Wed, Nov 28, 2012 at 12:58:38PM -0800, JesusTorrado wrote:
I found this:
sage: c = CartanType([[A,2]])
sage: c.is_irreducible()
False
And it has further nasty consequences:
Argl, corner case. Do you have a practical use case, or is it for the
sake of having robust
So --
The questions left are:
- Do we want printing options ? Currently, we have names and
bracket to specify the print output. If we don't want to modify the
printing options in object instances, I would actually more even
concerned about various embeddings...
- Do we want also indexing access
While UniversalCyclotomicField is a tad better than UCF, I think its still
a total failure in terms of tab discoverability. Why not just use
CyclotomicField() without specifying an integer? Or even allow both:
sage: UCF.E = CyclotomicField(embedding=lambda n: n-1)
On Wednesday, November 28,
While UniversalCyclotomicField is a tad better than UCF, I think its still a
total failure in terms of tab discoverability.
I do agree but the majority was for not having the function E in the
global namespace, so I removed it. On the other hand, we now have
UniversalCyclotomicField in there,
Why not just use
CyclotomicField() without specifying an integer? Or even allow both:
sage: UCF.E = CyclotomicField(embedding=lambda n: n-1)
I just got back to this comment concerning CyclotomicField() on the
ticket: http://trac.sagemath.org/sage_trac/ticket/8327#comment:2
--
You received
On Wednesday, November 28, 2012 10:27:51 AM UTC, Christian Stump wrote:
On the other hand, we now have
UniversalCyclotomicField in there, so people can still find it by tab
completion
Only if you accidentally start with U. I don't know about you, but I
would start with Cyclottab and never
Only if you accidentally start with U. I don't know about you, but I would
start with Cyclottab and never find the
UniversalGeneralizedFunctorialCyclotomics.
I am not saying this is my favorite solution, but this is a solution I
can live with (and I do start liking it better, now as I play
change To coerce from the category down to the parent -- To coerce
from
the abstraction layer to the parent. In this abstraction layer (which
is
close to the categories now available, but not quite the same), we would
have a list of methods for the parent class and the element
Op woensdag 28 november 2012 05:44:06 UTC+1 schreef kcrisman het volgende:
Sorry, what I mean is that the standard spkg would remain the same, and
the optional one would be the one you created and which would have
instructions to overwrite anything from the standard spkg, as well as of
I don't think 5MB is that much. Also, the more of boost we include the
easier it will be in the future to add new stuff.
Here is a nickel, kid, go and buy yourself some memory :-)
On Wednesday, November 28, 2012 2:27:35 AM UTC, Timo Kluck wrote:
Hi,
These two spkg updates need review:
On Wednesday, November 28, 2012 7:02:06 AM UTC-5, Volker Braun wrote:
I don't think 5MB is that much. Also, the more of boost we include the
easier it will be in the future to add new stuff.
Here is a nickel, kid, go and buy yourself some memory :-)
Well, fair enough, though in the
Hi Paul,
On 2012-11-28, Paul-Olivier Dehaye pauloliv...@gmail.com wrote:
change To coerce from the category down to the parent -- To coerce
from
the abstraction layer to the parent. In this abstraction layer (which
is
close to the categories now available, but not quite the same),
I
On Wednesday, November 28, 2012 1:05:16 PM UTC, kcrisman wrote:
Well, fair enough, though in the thread about the Sage Days in Africa it
seemed that that extra bit in the tarball could be an issue with low
bandwidth, and for making USB versions... not per se, but every little bit
helps, as
On Nov 28, 12:46 am, Christian Stump christian.st...@gmail.com
wrote:
- I now define the embedding as follows: the optional argument
embedding can be given a function n - k where 0 \leq k n, which I
then use to embed the UCF into QQbar. The advantage of this approach
is that I can also access
On Nov 28, 2:27 am, Christian Stump christian.st...@gmail.com wrote:
I do agree but the majority was for not having the function E in the
global namespace, so I removed it. On the other hand, we now have
UniversalCyclotomicField in there, so people can still find it by tab
completion and read
If you want a name that starts with Cyclo, would CyclotomicClosure
work? I don't think it's standard at all but it does conjure up a
picture of taking all cyclotomic fields together. I'm not even sure I
like it myself ...
Don't you think it's fine if we put a pointer in the documentation of
QQbar embeds into plenty of other fields than CC. I don't think it is
prescribed that embedding needs to specify an embedding into CC. For
instance:
sage: L.t=NumberField(x^6 + 6*x^5 + 15*x^4 + 20*x^3 + 15*x^2 + 6*x +
109)
sage: c=1/12*t^3 + 1/4*t^2 + 1/4*t - 5/12;
sage:
On Nov 28, 8:22 am, Christian Stump christian.st...@gmail.com wrote:
I see that for number field, the embedding is defined using
number_field_morphisms.create_embedding_from_approx
Ah, that explains the odd behaviour for
CyclotomicField(...,embedding=CC(17)) we saw before. I guess it's
You
don't have to tie your UCF implementation to the design choices made
presently for QQbar, so don't.
Yes, but see above. There is no reason to tie UCF to current design
decisions for QQbar. Especially because UCF embeds into fields that do
not contain an algebraic closure of Q.
I agree
You
don't have to tie your UCF implementation to the design choices made
presently for QQbar, so don't.
Yes, but see above. There is no reason to tie UCF to current design
decisions for QQbar. Especially because UCF embeds into fields that do
not contain an algebraic closure of Q.
I agree
On Nov 28, 9:03 am, Christian Stump christian.st...@gmail.com wrote:
What about making the mapping n - 0 \leq
emb(n) n one possibility to define the embedding into QQbar the way
it is currently done, and as well giving the possibility to embed it
similarly to the current embedding of
That's cute, but it makes for a much more complicated interface. I
don't think it provides anything extra either.
All I want to avoid is the problems that appear in the embeddings with
CyclotomicFields:
sage: CF1 = CyclotomicField(5)
sage: CF2 = CyclotomicField(5,embedding=CC(e^(4*pi*I/5)))
On Wed, Nov 28, 2012 at 2:21 AM, Volker Braun vbraun.n...@gmail.com wrote:
While UniversalCyclotomicField is a tad better than UCF, I think its still a
total failure in terms of tab discoverability. Why not just use
CyclotomicField() without specifying an integer? Or even allow both:
sage:
On Wed, Nov 28, 2012 at 9:34 AM, Nils Bruin nbr...@sfu.ca wrote:
On Nov 28, 9:03 am, Christian Stump christian.st...@gmail.com wrote:
What about making the mapping n - 0 \leq
emb(n) n one possibility to define the embedding into QQbar the way
it is currently done, and as well giving the
On Wed, Nov 28, 2012 at 2:59 AM, Paul-Olivier Dehaye
pauloliv...@gmail.com wrote:
change To coerce from the category down to the parent -- To coerce
from
the abstraction layer to the parent. In this abstraction layer (which
is
close to the categories now available, but not quite the
On 11/28/12 12:35 PM, Robert Bradshaw wrote:
Now that we're in bikeshedding territory, I guess my comment counts as much
as anyone else's :). It seems like it would be cleaner to make printing
options module-level options rather than options set in specific object
instances. Sure, it's not
Just FYI, Mathematica 9 is out today:
http://www.wolfram.com/mathematica/new-in-9/
Steven Wolfram's take on it:
http://blog.stephenwolfram.com/2012/11/mathematica-9-is-released-today/
Thanks,
Jason
--
You received this message because you are subscribed to the Google Groups
sage-devel
On 11/28/12 2:45 PM, Jason Grout wrote:
Steven Wolfram's take on it:
Sorry, *Stephen* Wolfram...
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group,
Op zondag 25 november 2012 02:09:46 UTC+1 schreef Keshav Kini het volgende:
Charles Bouillaguet charles.b...@gmail.com javascript: writes:
Hi all,
It would probably be safer to check if there are local change to the
sage library repos before applying the upgrade, and the upgrade
On 27 November 2012 15:12, kcrisman kcris...@gmail.com wrote:
How hard would it be to import contrib.foo as modular.foo
without causing problems? Because of course one wouldn't want one's
research stuff to have to live in a different namespace if it was for Sage
proper stuff.
This reminds me
Anybody recognise this bug? I don't see anything in Trac.
T=[(0, 2, '0'), (3, 3, '2'), (0, 2, '1')]
Gt = Graph(T)
Gt.loops()
[(3, 3, '2')]
versus
S=[(0, 2, '0'), (0, 2, '1'), (3, 3, '2')]
Gs = Graph(S)
Gs.loops()
[(3, 3, '2'), (3, 3, '2')]
Thanks,
Rob
--
You received this message because
Hey Rob,
I ran into something similar a little while back in sage-5.0
sage: G = Graph([(0,1,0),(0,1,0)])
sage: G.num_edges()
4
but IIRC, it was fixed in 5.3.
On Wed, Nov 28, 2012 at 8:02 PM, Rob Beezer goo...@beezer.cotse.net wrote:
Anybody recognise this bug? I don't see anything in Trac.
...we started a quarter century ago attacking core areas of
mathematics. -- true in more than one way.
So in Mathematica 9, one thing we’ve added is built-in integration
with the R statistics language. -- that's interesting. I think R has
really won in the realm of advanced statistics. You
44 matches
Mail list logo
