On Sat, Sep 10, 2011 at 11:45 AM, Dima Pasechnik wrote:
> well, on #11779 I am in minority, as some people refuse to acknowledge that
> exponentiation is often
> a binary operation (say, on positive reals)...
> If anyone is still willing to review this ticket, and not just demonstrate
> how stubb
well, on #11779 I am in minority, as some people refuse to acknowledge that
exponentiation is often
a binary operation (say, on positive reals)...
If anyone is still willing to review this ticket, and not just demonstrate
how stubborn they can be, this will be appreciated.
--
To post to this
On Tuesday, 6 September 2011 13:01:53 UTC+8, leif wrote:
>
> On 6 Sep., 06:36, Dima Pasechnik wrote:
> > On Tuesday, 6 September 2011 11:08:02 UTC+8, leif wrote:
> >
>
[...]
>
>
> Of course int(n)^-k should be int(1)/int(n)^k, yielding either a
> Python int or float, to stay "pythonic", or
On 6 Sep., 07:01, leif wrote:
> On 6 Sep., 06:36, Dima Pasechnik wrote:
>
> > On Tuesday, 6 September 2011 11:08:02 UTC+8, leif wrote:
>
> > > On 5 Sep., 17:44, Dima Pasechnik wrote:
> > > > Presently, int()^whatever stays Pythonic, no matter it causes a loss of
> > > > precision, or not.
>
> >
On 6 Sep., 06:36, Dima Pasechnik wrote:
> On Tuesday, 6 September 2011 11:08:02 UTC+8, leif wrote:
>
> > On 5 Sep., 17:44, Dima Pasechnik wrote:
> > > Presently, int()^whatever stays Pythonic, no matter it causes a loss of
> > > precision, or not.
>
> > Not true:
>
> > sage: 3r^ZZ(-3)
> > 0.03703
On 6 Sep., 06:05, rjf wrote:
> Presumably you must support intervals, since some of the M's do so,
> and Sage is supposed to be an alternative to them...
Sage does have real and complex interval arithmetic, partially backed
by MPFI.
-leif
--
To post to this group, send an email to sage-devel
On Tuesday, 6 September 2011 11:08:02 UTC+8, leif wrote:
>
> On 5 Sep., 17:44, Dima Pasechnik wrote:
> > Presently, int()^whatever stays Pythonic, no matter it causes a loss of
> > precision, or not.
>
> Not true:
>
> sage: 3r^ZZ(-3)
> 0.037037037037037035
> sage: 3r^QQ(-3)
> 1/27
>
wha
On Tue, Sep 6, 2011 at 1:51 PM, kcrisman wrote:
> What happens in Python 3.x, where I understand there *is* some kind of
> rational object? Maybe we should be oriented toward compatibility
> with that, if it's relevant. I didn't see a discussion of that in
> this thread, my apologies if I missed
On Sep 5, 4:43 pm, Jason Grout wrote:
> On 9/5/11 5:40 PM, rjf wrote:
>
> > One relatively clean resolution of some of the problems
> > is to replace every float -- on input -- to
> > an equivalent rational.
>
> It seems like we've had some big problems with this, in that maxima will
> sometim
On Sep 5, 11:43 pm, leif wrote:
> On 5 Sep., 18:33, William Stein wrote:
>
> > That said, for consistency with the rest of Sage, e.g., that int(1) +
> > Integer(2) is an Integer, we should have int(3)^Integer(2) be an
> > Integer.
>
> These are completely different things; see my previous post.
On 5 Sep., 18:33, William Stein wrote:
> That said, for consistency with the rest of Sage, e.g., that int(1) +
> Integer(2) is an Integer, we should have int(3)^Integer(2) be an
> Integer.
These are completely different things; see my previous post.
Btw., functions like e.g. gcd() do not preser
On 5 Sep., 17:44, Dima Pasechnik wrote:
> Presently, int()^whatever stays Pythonic, no matter it causes a loss of
> precision, or not.
Not true:
sage: 3r^ZZ(-3)
0.037037037037037035
sage: 3r^QQ(-3)
1/27
I'm strongly against making the result of exponentiation (of e.g.
Python ints) depend on th
On 5 Sep., 14:13, Simon King wrote:
> Hi Dima,
>
> On 5 Sep., 13:12, Dima Pasechnik wrote:
>
> > x if n==1...
>
> Oops...
>
> > To be precise, I can propose that
> > x^0 should be 1, (and not int(1)), then
> > x^n := x*x^{n-1} for n>0,
> > and then multiplication result will a Sage Integer.
>
>
On 9/5/11 5:40 PM, rjf wrote:
One relatively clean resolution of some of the problems
is to replace every float -- on input -- to
an equivalent rational.
It seems like we've had some big problems with this, in that maxima will
sometimes simplify things because it assumes an exact rational nu
On Sep 5, 9:31 am, Robert Bradshaw
wrote:
> On Mon, Sep 5, 2011 at 7:41 AM, rjf wrote:
> > is 4^(-2) (use various kinds of integers) integer rational float?
> > ditto for
> > 5^(-2) ?
>
> > Seems to me that the presence of python integers is an inconsistency
> > waiting to appear, and
> > th
On Mon, Sep 5, 2011 at 8:44 AM, Dima Pasechnik wrote:
>
>
> On Monday, 5 September 2011 22:41:50 UTC+8, rjf wrote:
>>
>> is 4^(-2) (use various kinds of integers) integer rational float?
>> ditto for
>> 5^(-2) ?
>>
>> Seems to me that the presence of python integers is an inconsistency
>> wait
On Mon, Sep 5, 2011 at 7:41 AM, rjf wrote:
> is 4^(-2) (use various kinds of integers) integer rational float?
> ditto for
> 5^(-2) ?
>
> Seems to me that the presence of python integers is an inconsistency
> waiting to appear, and
> the only proper use of python ints is as a sage integer which
By the way, the patch I propose on #11779 passes all (long) tests with Sage
4.7.1 on 64bit Linux.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at
On Monday, 5 September 2011 22:41:50 UTC+8, rjf wrote:
>
> is 4^(-2) (use various kinds of integers) integer rational float?
> ditto for
> 5^(-2) ?
>
> Seems to me that the presence of python integers is an inconsistency
> waiting to appear,
as brilliantly uncovered by our 2nd year und
is 4^(-2) (use various kinds of integers) integer rational float?
ditto for
5^(-2) ?
Seems to me that the presence of python integers is an inconsistency
waiting to appear, and
the only proper use of python ints is as a sage integer which happens
to be, at the moment,
small in magnitude.
Lis
this is now #11779
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Hi Dima,
On 5 Sep., 13:12, Dima Pasechnik wrote:
> x if n==1...
Oops...
> To be precise, I can propose that
> x^0 should be 1, (and not int(1)), then
> x^n := x*x^{n-1} for n>0,
> and then multiplication result will a Sage Integer.
Right, that would be sound.
> sage: int(3)^-3
> 0.0370370370
On Monday, 5 September 2011 18:45:42 UTC+8, Simon King wrote:
> Hi Dima, hi Rado,
>
> On 5 Sep., 11:58, Dima Pasechnik wrote:
> > I see no reason for int(3)^3 not to return a Sage Integer, and for
> int(3)^-3
> > not to return a QQ.
>
> I see a reason:
>
> x^n is recursively defined by
>
Hi Dima, hi Rado,
On 5 Sep., 11:58, Dima Pasechnik wrote:
> I see no reason for int(3)^3 not to return a Sage Integer, and for int(3)^-3
> not to return a QQ.
I see a reason:
x^n is recursively defined by
x if n==0
x*x^(n-1) otherwise
Hence, if x is a Python int then x^n should be a Python
One cannot always get an integer, e.g. 3^-3 cannot be an integer. So the
choices for type(int(3)^-3) are QQ or floats - currently Python's.
I see no reason for int(3)^3 not to return a Sage Integer, and for int(3)^-3
not to return a QQ.
I'll report on testing the Sage library after such a chang
25 matches
Mail list logo
