Fixed in http://trac.sagemath.org/ticket/16678.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send
Wow! It looks nice. Thank you for sharing this.
Kwankyu
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this
I was working on
krenn@brown:/local/data/krenn/sage/current6$ git branch --contains
* article-fsm-in-sage
and then wanted to push it on trac by:
krenn@brown:/local/data/krenn/sage/current6$ git-trac push 16705
Pushing to Trac #16705...
Guessed remote branch:
Dear all,
I'm in contact with Arne to craft a new IML release including all our
patches and would need some help to make sure everything is fine.
I've put a trac branch at u/jpflori/iml-1.0.4, a tarball and the
corresponding patches (on top of iml-1.0.3, just apply them in alphabetical
order)
The whole netlib Blas/lapack is under the original BSD license. As for the
examples.patch
I have no idea.
François
On 23/07/2014, at 21:52, Jean-Pierre Flori jpfl...@gmail.com wrote:
Dear all,
I'm in contact with Arne to craft a new IML release including all our patches
and would need
On Wednesday, July 23, 2014 12:00:20 PM UTC+2, François wrote:
The whole netlib Blas/lapack is under the original BSD license. As for the
examples.patch
So what should be done if we just want to include it?
Don't whant to think about licenses now.
(Note that for mysterious reason,
From the website:
http://www.netlib.org/blas/faq.html#2
and more precisely:
We only ask that proper credit be given to the authors.
François
On 23/07/2014, at 22:07, Jean-Pierre Flori jpfl...@gmail.com wrote:
On Wednesday, July 23, 2014 12:00:20 PM UTC+2, François wrote:
The whole netlib
On Wednesday, July 23, 2014 12:10:34 PM UTC+2, François wrote:
From the website:
http://www.netlib.org/blas/faq.html#2
and more precisely:
We only ask that proper credit be given to the authors.”
Would the line in the ChangeLog mentioning the inclusion be enough?
--
You received
I would put a line in SPKG.txt personally. I don't think the change log is
appropriate for credits of that kind.
On 23/07/2014, at 22:14, Jean-Pierre Flori jpfl...@gmail.com wrote:
On Wednesday, July 23, 2014 12:10:34 PM UTC+2, François wrote:
From the website:
On Wednesday, July 23, 2014 12:20:06 PM UTC+2, François wrote:
I would put a line in SPKG.txt personally. I don’t think the change log is
appropriate for credits of that kind.
I meant the IML ChangeLog (autotools stuff) file.
I could also add a line in the README there.
--
You received
In that case the README. The overzealous may add a note to the COPYING
file if there is one.
On 23/07/2014, at 22:23, Jean-Pierre Flori jpfl...@gmail.com wrote:
On Wednesday, July 23, 2014 12:20:06 PM UTC+2, François wrote:
I would put a line in SPKG.txt personally. I don't think the
On Wednesday, July 23, 2014 12:30:15 PM UTC+2, François wrote:
In that case the README.
Done, I've updated evrything.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an
On 2014-07-23, Daniel Krenn kr...@aon.at wrote:
I was working on
krenn@brown:/local/data/krenn/sage/current6$ git branch --contains
* article-fsm-in-sage
and then wanted to push it on trac by:
krenn@brown:/local/data/krenn/sage/current6$ git-trac push 16705
Pushing to Trac
in GF(2)xGF(3) addition is about 50 times (!) slower than in GF(7).
sage: c=cartesian_product([GF(2),GF(3)])
sage: %timeit c((1,1))+c((1,1))
1 loops, best of 3: 67.5 µs per loop
sage: d=GF(7)
sage: %timeit d(1)+d(1)
100 loops, best of 3: 1.44 µs per loop
This makes it next to useless for
Hello guys !
If anybody asks you whether Sage supports groups, here is an answer :
sage:
AG=cartesian_product([CyclicPermutationGroup(5),CyclicPermutationGroup(4),CyclicPermutationGroup(4)])
sage: AG.base_ring() # WTF ??? This has nothing to do here
sage: AG.construction() # same comment
sage:
On Wed, Jul 23, 2014 at 7:26 AM, Nathann Cohen nathann.co...@gmail.com wrote:
Hello guys !
If anybody asks you whether Sage supports groups, here is an answer :
sage:
AG=cartesian_product([CyclicPermutationGroup(5),CyclicPermutationGroup(4),CyclicPermutationGroup(4)])
Is this a confusion
Yo !!
Is this a confusion over categories, Nathann?
Or natural stupidity, your choice.
sage: G1 = CyclicPermutationGroup(5)
sage: G2 = CyclicPermutationGroup(4)
sage: D1 = G1.direct_product(G2,False)
sage: D2 = D1.direct_product(G2,False)
sage: D2.base_ring()
Integer
On Wed, Jul 23, 2014 at 7:56 AM, Nathann Cohen nathann.co...@gmail.com wrote:
Yo !!
Is this a confusion over categories, Nathann?
Or natural stupidity, your choice.
sage: G1 = CyclicPermutationGroup(5)
sage: G2 = CyclicPermutationGroup(4)
sage: D1 =
Cartesian product is a generic construction, so it should be clear that it
is much slower than the super-optimized routines for prime finite fields.
Do you need element-wise multiplication? If you are only interested in the
Abelian group structure then there is AbelianGroup([2,3]). Maybe you
Hell !!
Cartesian product is a generic construction, so it should be clear that it
is much slower than the super-optimized routines for prime finite fields.
It probably will never be as fast as those fields, but there is a waste of
time anyway.
Do you need element-wise
On Wed, 23 Jul 2014 08:59:24 -0400
David Joyner wdjoy...@gmail.com wrote:
first I assume means first factor in the product, and similarly for last.
I don't know why they don't work. They should return the set
associated to the first (resp., last) factor in the product.
The methods first and
Hello !
The methods first and last give the first and last element of an
enumeration:
I guess, but do we want them as methods of Group instances ?
This probably comes up for a cartesian product of cyclic permutation
groups, because those are considered finite enumerated sets:
Some
Hey everyone,
If anybody asks you whether Sage supports groups, here is an answer :
Well, the question should be whether Sage supports Cartesian products.
Right now the answer is not really beyond sets because I don't think anyone
has wanted it (maybe there's some tickets on this...?). With
Some of the history of parents and generators is discussed here
https://groups.google.com/d/msg/sage-devel/3c0vPGOWWMI/ys5hYhhdp3sJ
On Wednesday, July 23, 2014 12:04:49 PM UTC-4, Travis Scrimshaw wrote:
We do want to try and get away from the sometimes ambiguous gens() to
On Wednesday, July 23, 2014 12:04:49 PM UTC-4, Travis Scrimshaw wrote:
We do want to try and get away from the sometimes ambiguous gens() to
explicit_generators()
Unless you also envision an implicit_generators() that is a bad name.
Generators are almost always involve choices, deal
How is that related? I agree with Nicolas, gens() or generators() shall be
the most specific kind of generator. You can always have
whatever_generators() for generators of any kind of substructure in
addition.
On Wednesday, July 23, 2014 1:46:20 PM UTC-4, Travis Scrimshaw wrote:
On
I have yet another example of the brittleness of Sage binaries. See
trac#16694 http://trac.sagemath.org/ticket/16694 for details. Roughly, a
binary compiled with SAGE_FAT_BINARY=yes gives a defective Sage's R on
a machine differing from the original one.
I may have another one in preparation
More fun at http://trac.sagemath.org/ticket/16706.
If nobody raises its voice, I'll just forward the current archive there to
Arne for release.
Best,
JP
On Wednesday, July 23, 2014 12:35:38 PM UTC+2, Jean-Pierre Flori wrote:
On Wednesday, July 23, 2014 12:30:15 PM UTC+2, François wrote:
SAGE_FAT_BINRAY is quite fragile.
If you really want me to, I can break it on quite every system.
Are the machine really different?
Maybe its just a problem with R and can be fixed.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe
It's a good reason why we should try to move away from gens(), as I
stated above. Explicit is better than implicit to minimize the choices.
It's not a matter of just dealing with it.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To
SAGE_FAT_BINRAY is quite fragile.
If you really want me to, I can break it on quite every system.
Are the machine really different?
Maybe its just a problem with R and can be fixed.
I think that is quite likely and could be fixed with spkg-install or
whatever is used now...
--
You
On Sun, Jul 20, 2014 at 8:43 PM, Stefan Karpinski ste...@karpinski.org
wrote:
Yes, you can definitely do most of this with template metaprogramming,
although, as you say it's pretty tricky.
Some people, when confronted with a problem, think I know, I'll use
template metaprogramming. Now they
On Saturday, July 19, 2014 8:22:39 AM UTC-7, Nils Bruin wrote:
On Saturday, July 19, 2014 5:43:57 AM UTC-7, defeo wrote:
However, Julia multimethods are backed up by a powerful coercion
system, so I do not understand the step back criticism.
That comment wasn't made with respect to
On Wednesday, July 23, 2014 5:05:49 PM UTC-4, Travis Scrimshaw wrote:
Explicit is better than implicit to minimize the choices.
But adding explicit_ in front of everything is just a typing exercise, it
does not convey any information. explicit_generators(),
explicit_ring_generators(),
On Wed, Jul 23, 2014 at 5:47 PM, rjf fate...@gmail.com wrote:
On Saturday, July 19, 2014 8:22:39 AM UTC-7, Nils Bruin wrote:
On Saturday, July 19, 2014 5:43:57 AM UTC-7, defeo wrote:
However, Julia multimethods are backed up by a powerful coercion
system, so I do not understand the step
You've misunderstood me, by explicit_generators I mean group_generators(),
algebra_generators(), module_generators(), etc., i.e. being explicit about
what type of generators.
On Wednesday, July 23, 2014 7:18:37 PM UTC-7, Volker Braun wrote:
On Wednesday, July 23, 2014 5:05:49 PM UTC-4,
I use the following code but failed.
###
x=[1,2,3,4,5]
y=[2,3,4,5,6]
x=r(x)
y=r(y)
r.t_test(x,y,alternative=less)
###
It returns that error:object 48 not found
But it works if I didn't use alternative.
r.t_test(x,y) will return the result of two side
37 matches
Mail list logo
