On Wed, 31 Oct 2012 at 08:47AM -0700, mmarco wrote:
> My view: since this was revealed to my as a problem by a professor in
> my university, who had problems runnning in class something like this:
>
> for i in range(10):
> print cos(i).n()
>
> i think that the result should be, at least, some
On Oct 31, 8:47 am, mmarco wrote:
> for i in range(10):
> print cos(i).n()
...
> Besides, 0 should be converted to Integer(0) by the
> preparser, right? so the criterion of keeping the input type also
> points to the same direction.
*keeping* input types would still let your example fail, sin
On Wednesday, October 31, 2012 10:01:01 AM UTC-7, kcrisman wrote:
>
>
>
> On Wednesday, October 31, 2012 11:47:20 AM UTC-4, mmarco wrote:
>>
>> My view: since this was revealed to my as a problem by a professor in
>> my university, who had problems runnning in class something like this:
>>
>> f
On Wednesday, October 31, 2012 11:47:20 AM UTC-4, mmarco wrote:
>
> My view: since this was revealed to my as a problem by a professor in
> my university, who had problems runnning in class something like this:
>
> for i in range(10):
> print cos(i).n()
>
> i think that the result should
On Monday, October 29, 2012 10:25:39 PM UTC+1, Volker Braun wrote:
>
> Great! Can you make a trac account for yourself and a ticket with your
> patch?
I have just applied for an account. Let's see.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" gr
On 2012-10-29 16:39, Marco Streng wrote:
> 2012/10/28 Charles Bouillaguet :
>> Hi all,
>>
>> While playing with the quotient of a polynomial ring with an ideal, I
>> encountered several glitches.
>>
>> *) Trying to compute the inverse of something which is not invertible.
>>
>> I know it is kind o
My view: since this was revealed to my as a problem by a professor in
my university, who had problems runnning in class something like this:
for i in range(10):
print cos(i).n()
i think that the result should be, at least, something that has
the .n() procedure implemented. That is: Integer se
On 31 October 2012 13:39, Charles Bouillaguet wrote:
>
> > I think all that Marco meant was that for a general ring, there may be
> > no algorithm to decide invertibility. In this ring, of course there
> > is.
>
> Yes, but the NotImplemented exception was raised **in the case where a
> Groebner
>
>
> > I've updated #10133 with this apparent consensus. Note that in the
> > partial duplicate #10972 Burcin seemed to think that they should
> > return symbolic expressions, but Simon's argument seems reasonable to
> > me as well.
>
> ???
>
> The quote on that ticket is from you:
>
>
Rea
> I think all that Marco meant was that for a general ring, there may be
> no algorithm to decide invertibility. In this ring, of course there
> is.
Yes, but the NotImplemented exception was raised **in the case where a Groebner
basis could be computed**, and I maintain that it is not the most
On Wed, 31 Oct 2012 05:05:24 -0700 (PDT)
kcrisman wrote:
> On Wednesday, October 31, 2012 6:01:07 AM UTC-4, Volker Braun wrote:
> >
> > On Tuesday, October 30, 2012 11:08:15 PM UTC, Fredrik Johansson
> > wrote:
> >
> >> Returning a Sage Integer would be consistent with this:
> >
> >
> > I also t
On 10/31/12 6:51 AM, Raniere Gaia Silva wrote:
In the matrix's class diagram (see source:sage/matrix/docs.py) for dense
matrix are list the subclass
* Matrix_real_double_dense
* Matrix_complex_double_dense
which already are implemented. For sparse matrix it suggest the creation
of the subclass
On Wednesday, October 31, 2012 6:01:07 AM UTC-4, Volker Braun wrote:
>
> On Tuesday, October 30, 2012 11:08:15 PM UTC, Fredrik Johansson wrote:
>
>> Returning a Sage Integer would be consistent with this:
>
>
> I also think that returning a Sage integer is the appropriate thing to do.
>
>
I'v
In the matrix's class diagram (see source:sage/matrix/docs.py) for dense
matrix are list the subclass
* Matrix_real_double_dense
* Matrix_complex_double_dense
which already are implemented. For sparse matrix it suggest the creation of
the subclass
* Matrix_RDF_sparse
* Matrix_CDF_sparse
What I
Use lazy_import in sage/matrix/all.py, see
http://www.sagemath.org/doc/reference/sage/misc/lazy_import.html
On Wednesday, October 31, 2012 10:58:24 AM UTC, Raniere Gaia Silva wrote:
>
> Hi,
> I'm write a patch for the ticket 13601 and having troubles with the
> startup patchbot test.
> Any one
Hi,
I'm write a patch for the ticket 13601 and having troubles with the startup
patchbot test.
Any one can help me solve it?
{{{
== plugins.startup_modules ==
--- 5.4.rc2
+++ 5.4.rc2 + #13601
-real0m0.616s
-user0m0.488s
-sys0m0.120s
+real0m0.643s
+user0m0
Fair enough. I don't really have an objection to an Integer output. And
I'll certainly defer to people who actually work on that part of Sage. :-)
David
On Wed, Oct 31, 2012 at 4:01 AM, Volker Braun wrote:
> On Tuesday, October 30, 2012 11:08:15 PM UTC, Fredrik Johansson wrote:
>
>> Returnin
On Tuesday, October 30, 2012 11:08:15 PM UTC, Fredrik Johansson wrote:
> Returning a Sage Integer would be consistent with this:
I also think that returning a Sage integer is the appropriate thing to do.
--
You received this message because you are subscribed to the Google Groups
"sage-dev
On 2012-10-31, Julien Puydt wrote:
> Le 30/10/2012 22:58, David Roe a écrit :
>> I think this is a bug: the type of the result should be consistent.
>
> I think that if you expect a type foo but get a type bar which can be
> auto-coerced to type foo, then it's fine, even if not constant.
+1
Aft
Le 30/10/2012 22:58, David Roe a écrit :
I think this is a bug: the type of the result should be consistent.
I think that if you expect a type foo but get a type bar which can be
auto-coerced to type foo, then it's fine, even if not constant.
Snark on #sagemath
--
You received this message
20 matches
Mail list logo
