Consider this:
sage: R100=RealField(100)
sage: x= R100(8/3)
sage: R=RealField()
sage: R(x)
2.67
sage: RDF(x)
2.667
The documentation says that in RealField() and RDF, numbers are
represented with the same precision of 53 bits.
So, R(x) and RDF(x) should give the same result
> Cool. I'd be happy to review that after Wednesday (when I have an
> application due). I can provide the perspective of someone who works mostly
> within sage.rings rather than sage.combinat.
sounds good, thanks! The ticket 8327 depends on ticket #8651 which
again depends on ticket #8648. If yo
Cool. I'd be happy to review that after Wednesday (when I have an
application due). I can provide the perspective of someone who works mostly
within sage.rings rather than sage.combinat.
David
On Sat, Oct 16, 2010 at 18:17, Christian Stump wrote:
> > Is there a reason you can't use finite cyclo
> Is there a reason you can't use finite cyclotomic fields? These exist in
> Sage and are reasonably well optimized. And GAP supports matrix groups over
> them, though as David Joyner mentioned, I don't think that functionality is
> wrapped from Sage. Defining matrix groups over finite cyclotomi
> Does this help?
>
> sage: K = CyclotomicField(12) # 12 = 4*3
> sage: K.gens()
> (zeta12,)
> sage: z = K.gens()[0]
> sage: z
> zeta12
> sage: E3 = z^4
> sage: E4 = z^3
> sage: gens = [ matrix( K, 2, [ E3, 0, 0, E4 ] ), matrix( K, 2, [ -E3,
> 0, 0, -1 ] ) ]
> sage: G = MatrixGroup( gens )
> sage
Is there a reason you can't use finite cyclotomic fields? These exist in
Sage and are reasonably well optimized. And GAP supports matrix groups over
them, though as David Joyner mentioned, I don't think that functionality is
wrapped from Sage. Defining matrix groups over finite cyclotomic fields
On Sat, Oct 16, 2010 at 5:12 PM, Christian Stump
wrote:
>> This would be an infinite group which I think is not implemented in Sage or
>> GAP.
>> I can't even imagine a way that GAP could help, but it can't hurt to
>> ask in the GAP support list. Maybe there is an "approximation" someone could
>>
You can either inherit from sage.rings.commutative_ring.CommutativeRing, or
modify FreeModule to work better with the category framework. The first is
probably the easier option.
David
On Sat, Oct 16, 2010 at 16:27, Christian Stump wrote:
> > What are you inheriting from? FreeModule is checking
> This would be an infinite group which I think is not implemented in Sage or
> GAP.
> I can't even imagine a way that GAP could help, but it can't hurt to
> ask in the GAP support list. Maybe there is an "approximation" someone could
> think of that might help. Please be as specific as possible w
This would be an infinite group which I think is not implemented in Sage or GAP.
I can't even imagine a way that GAP could help, but it can't hurt to
ask in the GAP support list. Maybe there is an "approximation" someone could
think of that might help. Please be as specific as possible when formula
> In addition to what David Roe said, if I remember correctly MatrixGroups in
> Sage are implemented for matrices over finite fields. At some point I think it
> calls GAP for the computations.
>
> If your field is not finite, it might be better to use GAP directly
> since Sage only
> has infinite m
> What are you inheriting from? FreeModule is checking to see if you're
> inheriting from sage.rings.commutative_ring.CommutativeRing. This was
> written long before categories became available.
No I don't - should I? Or is there another way to get around this?
At the moment, I inherit only fro
In addition to what David Roe said, if I remember correctly MatrixGroups in
Sage are implemented for matrices over finite fields. At some point I think it
calls GAP for the computations.
If your field is not finite, it might be better to use GAP directly
since Sage only
has infinite modular (matri
What are you inheriting from? FreeModule is checking to see if you're
inheriting from sage.rings.commutative_ring.CommutativeRing. This was
written long before categories became available.
David
On Sat, Oct 16, 2010 at 14:27, Christian Stump wrote:
> Hello,
>
> I am trying to define a matrix gr
Hi Francois,
On Fri, 15 Oct 2010 21:46:36 +0200
Francois Maltey wrote:
> You wrote (I cut a lot)
> > Yup, I see what you are talking about - e.g.
> >
> > if (x.is_equal(_ex1)) // log(1) -> 0
> > return _ex0;
> >
> > Although it might be nice to stay relatively cl
Hi Francois,
On Mon, 11 Oct 2010 18:12:57 +0200
Francois Maltey wrote:
> // 1 // And what do you think about log ? Look at these test :
>
> exp(x).operator() == exp # is True, and all(?) trigonometric
> functions are fine
> log(x).operator() == ln # is True, yes the alias ln is better than
> t
Hello,
I am trying to define a matrix group generated by matrices over a
field which I have defined. At the moment, I am stuck with the the
question of how to make the base_ring an instance of CommutativeRing?
In particular, I get that the __init__ in free_module.pyc asks
isinstance(base_ring, com
Hi Burcin,
On Sat, Oct 16, 2010 at 11:21 PM, Burcin Erocal wrote:
> We might be able to overcome this with a "bug-wrangler" team,
I would have thought "weed-wrangler" or "pest-wrangler". You know,
Sage and horticulture :-)
> people
> who volunteer to
>
> - look at newly submitted tickets, not
Hi, Burcin!
I think this is a great Idea!
I'm short on time in the next months, but
If I'm free again, could help with this.
greez,
Stefan
On 16 Okt., 14:21, Burcin Erocal wrote:
> Hi,
>
> Motivated by the call for the bug days, here is an idea to manage the
> rapidly increasing number of "new"
Hi!
Burcin asked me to make a new version of ortho polys some time ago,
and since Ticket #9808 for upgrading numpy and scipy finally got a
positive review, I can now finish this task.
Please feel free to look at the new version. The new version is a lot
faster as the old implementation with maxim
Nice, this worked perfectly..
Thanks.
t.
Le 16/10/2010 08:01, Thierry Dumont a écrit :
Message original
Sujet: Re: [sage-devel] User identification, did something change ?
Date : Mon, 11 Oct 2010 11:12:50 -0700
De : Mike Hansen
Répondre à : sage-devel@googlegroups.com
Pour :
Hi,
Motivated by the call for the bug days, here is an idea to manage the
rapidly increasing number of "new" tickets on trac.
Many of the bugs on trac are
- duplicates,
- already fixed, which can be closed after adding a doctest or
- has not been seen by a developer who can fix it since kee
Dear Sage Devel Community,
Please send me an offlist email at wst...@gmail.com if you're very
interested in being invited to an upcoming "Bug Days" in Seattle, all
expenses paid. This will be a roughly 5 day workshop in which about 10-15
Sage developers gather to greatly improve the quality of S
23 matches
Mail list logo
