On 2014-04-28, Nathann Cohen wrote:
> Yes I do need the multiplication too. I am implementing constructions of
> MOLS and for some of them I need to do some computations on a field, then
> give everything to a function that needs group elements as input... So I
> need it to be a group and also to
Yes I do need the multiplication too. I am implementing constructions of
MOLS and for some of them I need to do some computations on a field, then
give everything to a function that needs group elements as input... So I
need it to be a group and also to see this as a field. Can we do that in
Sage ?
On Mon, Apr 28, 2014 at 11:55 AM, Dima Pasechnik wrote:
> On 2014-04-28, Nils Bruin wrote:
>> On Monday, April 28, 2014 12:56:48 AM UTC-7, jori.ma...@uta.fi wrote:
>>>
>>> It takes less than two minutes to run
>>>
>>> ./sage -c "n=121; l=range(1,n+1); x=matrix([[floor(n/lcm(i,j)) for i in l]
>>>
On 2014-04-28, Nathann Cohen wrote:
> Hello everybody !
>
> I need to use the elements of GF(8,'x') x Z/3Z as an additive group. Is
> there a way to do this with Sage ? I need that to add more combinatorial
> designs :-)
Do you need multiplication in GF(8)? If not, you can just construct
the corre
On 2014-04-28, Nils Bruin wrote:
> On Monday, April 28, 2014 12:56:48 AM UTC-7, jori.ma...@uta.fi wrote:
>>
>> It takes less than two minutes to run
>>
>> ./sage -c "n=121; l=range(1,n+1); x=matrix([[floor(n/lcm(i,j)) for i in l]
>> for j in l]).eigenvalues();"
>>
>> But with n=122 calculation
Turns out that I am an idiot, and that the warning is triggered by the
"degree=G([1,2])"
part of the expression I had overlooked. The branch now passes all tests,
and is in needs_review.
The only thing that needs to be discussed is this warning problem, and
whether we should create a new function
Hello again !
This time the branch passes all long tests in src/ except one, and I need
your advice. Here is the problem :
**
File "chain_complex.py", line 738, in
sage.homology.chain_complex.ChainComplex_class.grading_group
On Monday, April 28, 2014 9:14:17 AM UTC-7, Volker Braun wrote:
>
> Showing a deprecation warning for valid input isn't ideal ;-)
>
> How about we deprecate all list/tuple input and force the user to use
> G.linear_combination_of_smith_form_gens / G.linear_combination_of_gens.
>
list input is act
The current branch passes all tests in groups/ and modules/fg_pid/ :-)
Needs review !
Nathann
On 28 April 2014 18:29, Nathann Cohen wrote:
> Ahahaah. While writing that code, I met an infinite loop. Apparently
> testing if an element of a group is equal to +infinity calls
> __repr__... :-P
>
>
On Monday, April 28, 2014 12:56:48 AM UTC-7, jori.ma...@uta.fi wrote:
>
> It takes less than two minutes to run
>
> ./sage -c "n=121; l=range(1,n+1); x=matrix([[floor(n/lcm(i,j)) for i in l]
> for j in l]).eigenvalues();"
>
> But with n=122 calculation seems to get stuck.
>
> Well, 122=61*2, so
Ahahaah. While writing that code, I met an infinite loop. Apparently
testing if an element of a group is equal to +infinity calls
__repr__... :-P
Nathann
On 28 April 2014 18:16, Nathann Cohen wrote:
>> Showing a deprecation warning for valid input isn't ideal ;-)
>
> Indeed, indeed. Right now it
Hello guys !
I just created ticket #16261 about this and uploaded my branch. It's
funny that to make all tests pass I only had to add four
"linear_combination_of_smith_form_gens"...
Now the problem is that I have no idea how to change .short_name()
(which is called by __repr__), as I have no idea
Showing a deprecation warning for valid input isn't ideal ;-)
How about we deprecate all list/tuple input and force the user to use
G.linear_combination_of_smith_form_gens / G.linear_combination_of_gens.
On Monday, April 28, 2014 4:27:45 PM UTC+1, Nathann Cohen wrote:
>
> > Moreover, how are
> Showing a deprecation warning for valid input isn't ideal ;-)
Indeed, indeed. Right now it prints the following input, which I hope
will be taken seriously by those who should, and be ignored by those
who should :
sage: x = A([5]); x
doctest:1: DeprecationWarning: The default behaviour changed
Here's something I find really confusing about additive abelian groups:
sage: H = AdditiveAbelianGroup([0,2])
sage: H((2,0))
(0, 0)
sage: H(vector((2,0)))
(2, 0)
sage: H((1,0)).order()
2
sage: H(vector((1,0))).order()
+Infinity
This is terrible, and a symptom of what Nathann wants to fix. It sho
To be honest, I would prefer to do the opposite. Changing it now while
printing a message saying that the format changed, and removing the
message one year from now.
Nathann
On 28 April 2014 17:27, Nathann Cohen wrote:
>> Moreover, how are you going to deprecate it? When is a deprecation warnin
> Moreover, how are you going to deprecate it? When is a deprecation warning
> shown?
Ahahahah. That's an interesting question, but the current way being
bad, there is absolutely no way that it will stay like that forever
just because we don't know how to tell the users :-D
I had something a bit
On Monday, April 28, 2014 4:06:36 PM UTC+1, Nathann Cohen wrote:
>
> I believe that not so many have written such code, for the very same
> reason. But indeed if we change that we will need a deprecation step.
>
Moreover, how are you going to deprecate it? When is a deprecation warning
shown?
Hi!
On 2014-04-28, Nathann Cohen wrote:
>> The default repr is in terms of smith form gens, so IMHO it makes more sense
>> to default to a linear combination of smith form gens. Imagine some method
>> returns an abelian group, how are you going to construct elements?
>
> Well, obviously by changi
I mean ... Really, nobody cares what the smith form generators are.
It's a technical problem, the user does not even have to be aware of
that !
Nathann
On 28 April 2014 17:19, Nathann Cohen wrote:
>> The default repr is in terms of smith form gens, so IMHO it makes more sense
>> to default to a
> The default repr is in terms of smith form gens, so IMHO it makes more sense
> to default to a linear combination of smith form gens. Imagine some method
> returns an abelian group, how are you going to construct elements?
Well, obviously by changing repr, no ? O_o
Nathann
--
You received thi
The default repr is in terms of smith form gens, so IMHO it makes more
sense to default to a linear combination of smith form gens. Imagine some
method returns an abelian group, how are you going to construct elements?
--
You received this message because you are subscribed to the Google Group
On Monday, April 28, 2014 9:21:25 AM UTC-4, J.D. Quigley wrote:
>
>
>
> Hello,
>
> This is probably a very basic question, but any guidance would be
> appreciated. Is there a way to run a .sage file on Windows? I'm able to run
> .sws files by running Sage on VirtualBox and then importing the fi
> Hence it can break code that people have written privately.
I believe that not so many have written such code, for the very same
reason. But indeed if we change that we will need a deprecation step.
Don't you agree that this change would make sense ?
I just did the change I mentionned above, a
On Monday, April 28, 2014 2:59:05 PM UTC+1, Nathann Cohen wrote:
>
> > I would think that this is incompatible with the current syntax.
> Yes of course, that changes the default
Hence it can break code that people have written privately.
--
You received this message because you are subscribed
> I would think that this is incompatible with the current syntax.
Yes of course, that changes the default ! But I am not so sure that it
would break many things, as the current implementation is so
unreliable that you cannot "guess" what G accepts as input, unless you
made sure to define it with
On Monday, April 28, 2014 2:09:55 PM UTC+1, Nathann Cohen wrote:
>
> What do you think the implications of the following changes would be ?
> [...]
>
I would think that this is incompatible with the current syntax. If
anything, we should add a G.linear_combination_of_gens in addition to the
exi
> I don't think that will work if you are relying on the error message to
> indicate the wrong length of input. For example:
>
> sage: AdditiveAbelianGroup([6,2])
> Additive abelian group isomorphic to Z/2 + Z/6
>
> Now you will expect the element (1,0) to have order 6 but it has order 2.
No, thi
Hello,
This is probably a very basic question, but any guidance would be
appreciated. Is there a way to run a .sage file on Windows? I'm able to run
.sws files by running Sage on VirtualBox and then importing the file
through localhost:8000 (or by importing to sagenb.com), but I'm not able to
I don't think that will work if you are relying on the error message to
indicate the wrong length of input. For example:
sage: AdditiveAbelianGroup([6,2])
Additive abelian group isomorphic to Z/2 + Z/6
Now you will expect the element (1,0) to have order 6 but it has order 2.
John
On 28 April
> Its always going to be somewhat confusing to have both the original
> definition and a canonical form around. Feel free to add more descriptive
> construction methods for elements. The ctor argument convention is because
> that was chosen originally and I didn't want to break code when refactorin
Helloo !!!
> I think this is right. Allocating & copying such a huge matrix repeatedly
> would be terrible. Perhaps we should introduce an API function to
> "add_constraints", which takes a list of lists, or a matrix? If a solver
> doesn't support such a thing, we could fall b
On Monday, April 28, 2014 11:18:09 AM UTC+1, Nathann Cohen wrote:> Thats
it.
>
> The syntax is awful, do we agree on that ?
>
Its always going to be somewhat confusing to have both the original
definition and a canonical form around. Feel free to add more descriptive
construction methods for
On 28 April 2014 11:18, Nathann Cohen wrote:
> > Thats it.
>
> The syntax is awful, do we agree on that ?
>
> > -1, some method returns an abelian group and you don't know how it was
> > constructed without having to dig around.
>
> ?
>
> But when I create a group by myself which I want to be equ
> Thats it.
The syntax is awful, do we agree on that ?
> -1, some method returns an abelian group and you don't know how it was
> constructed without having to dig around.
?
But when I create a group by myself which I want to be equal to Z/2Z *
Z/3Z I end up with something different, isn't that
On Monday, April 28, 2014 11:11:45 AM UTC+1, Nathann Cohen wrote:
>
> > I think that the point is to allow creation of elements either with
> respect to the input generators (using vector) or with respect to the
> simplified generators (without vector). Since both sort of input look the
> same
> I think that the point is to allow creation of elements either with respect
> to the input generators (using vector) or with respect to the simplified
> generators (without vector). Since both sort of input look the same (tuples
> / lists) I am guessing that the trick of using "vector" is jus
On 28 April 2014 09:48, Nathann Cohen wrote:
> Okay, thanks to this "vector" trick I was able to do what I wanted. Do you
> believe that the syntax should be changed so that A(vector(whatever)) has
> the same result as A(whatever) ? "vector" does not add a very meaningful
> information here ...
>
The problem is now fixed by this ticket :
http://trac.sagemath.org/ticket/16257
If you can review it, it will be merged faster, possibly into the next
release :-)
Thanks for the report,
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-support" group
Hello everybody !
I need to use the elements of GF(8,'x') x Z/3Z as an additive group. Is
there a way to do this with Sage ? I need that to add more combinatorial
designs :-)
Thanks !
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-support" group.
To
Okay, thanks to this "vector" trick I was able to do what I wanted. Do you
believe that the syntax should be changed so that A(vector(whatever)) has
the same result as A(whatever) ? "vector" does not add a very meaningful
information here ...
Nathann
--
You received this message because you a
Hello !!
Using
>G.relabel( [ i+1 for i in range(G.order()) ], inplace=True )
> and repeat the same command once more causes the error below.
>
That is because of that (rom the doc of Graph.relabel) :
If ``perm`` is a dictionary ``d``, then each vertex ``v``
(which should be
It takes less than two minutes to run
./sage -c "n=121; l=range(1,n+1); x=matrix([[floor(n/lcm(i,j)) for i in l] for j in
l]).eigenvalues();"
But with n=122 calculation seems to get stuck.
Well, 122=61*2, so maybe it's because of a big factor? However, n=118=59*2
takes only about a minute. An
43 matches
Mail list logo
