[sage-support] Re: Does the digits method have an inverse?
2008/10/22 Timothy Clemans [EMAIL PROTECTED]:
def from_digits(lis):
return ZZ(''.join([str(i) for i in lis[::-1]]))
Or even
sage: n = 150
sage: dig = n.digits()
sage: PolynomialRing(ZZ,'x')(dig)(2)
150
but I agree that this should be a provided function.
NB trac ticket #2796 may soon change the default base in digits from 2 to 10.
John Cermona
On Wed, Oct 22, 2008 at 12:35 AM, Jason Merrill [EMAIL PROTECTED] wrote:
sage: 1492.digits(10)
[2, 9, 4, 1]
Now is there an easy way to take this list and get back the integer
1492?
Regards,
JM
--~--~-~--~~~---~--~~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-support] Re: multiply a list by a constant
On Oct 21, 2008, at 10:17 PM, pong wrote:
Thanks to both Dan and William. However, Dan's result puzzled me.
Aren't they suggested that the for loop is faster?
Here is what I got:
sage: timeit('list(2*vector([random() for j in range(10)]))')
625 loops, best of 3: 332 µs per loop
sage: timeit('[2*random() for j in range(10)]')
125 loops, best of 3: 8.3 ms per loop
A more precise benchmark (ignoring vector/list creation) would
probably be:
sage: L = [random() for j in range(10)]
sage: v = vector(L)
sage: timeit(2*v)
625 loops, best of 3: 1.76 µs per loop
sage: timeit([2*a for a in L])
25 loops, best of 3: 29.2 ms per loop
To explain your timings, note
sage: parent(random())
type 'float'
sage: parent(vector([random() for j in range(10)]))
Vector space of dimension 10 over Real Double Field
sage: parent(2)
Integer Ring
In your first loop, it's creating a RDF vector and then multiplying
by 2 via
sage: cm = sage.structure.element.get_coercion_model()
sage: cm.explain(2, v)
Action discovered.
Left scalar multiplication by Integer Ring on Vector space of
dimension 10 over Real Double Field
Result lives in Vector space of dimension 10 over Real Double Field
Vector space of dimension 10 over Real Double Field
in other words, it turns 2 into an RDF, then multiplies every
element (in fast compiled code) of the RDF vector. In the second
case, it's having to re-discover the float-Integer operation each
time (as the result is a float) which happens to be the worst-case
scenario. Note with RDF rather than floats
sage: timeit([2*a for a in v])
625 loops, best of 3: 20.9 µs per loop
(still not the speed of a vector-element multiply, but much better).
There is a ticket or two related to improving this, e.g. #3938 and
#2898.
which suggested otherwise. Also how does timeit determine how many
loops to perform in a test?
In my experience (haven't looked at the code) it keeps timing until
it hits about a second, going by powers of 5.
Also, instead of doing your own loops, you can use %timeit:
sage: %timeit [2*random() for j in range(10)]
10 loops, best of 3: 6.87 µs per loop
sage: %timeit list(2*vector([random() for j in range(10)]))
1 loops, best of 3: 112 µs per loop
Note that the 2 is not getting preparsed, and so one is doing python-
int * python-float. Also, in the second example, the bulk of the time
is in the conversion, not the multiply
sage: sage: %timeit list(2*vector([random() for j in range(10)]))
1 loops, best of 3: 173 µs per loop
sage: %timeit list(vector([random() for j in range(10)]))
1 loops, best of 3: 167 µs per loop
Using list comprehensions is almost always a good choice in Sage/
Python;
as I understand (and as we see above), they're very well-optimized.
Yes, though using vectors can be faster too, and if one's list really
is a vector than it can make much easier to read code than
manipulating lists.
- Robert
--~--~-~--~~~---~--~~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-support] Is interact partly broken in 3.1.4 (or before)?
In 3.1.4 and 3.2.alpha0 I get very weird behavior in @interact. First, when a worksheet opens up, there is the usual long and annoying automatic evaluation of the @interact cells (which I feel is not a feature, though perhaps not a bug... but I couldn't find where this was mentioned before in the lists or Trac). At the end of this, in both versions I get long error message ending with ValueError: invalid literal for int() with base 10: 'NaN' in cells with no errors. The NaN error could be specific to my cells, but there should not be any error. Then, upon Shift-Entering the @interact cell, I *do* get the correct graphic, but there are no sliders! I only get the variable names, but not the sliders. I have not tried this with other input types, so it is possible it is only the sliders this happens for. I'm sorry I can't diagnose this any further; my previous version is 3.0.6, and that works fine, so whatever this is was introduced between there and 3.1.4. V. 3.0.6 still works even after I get the errors on the newer versions, so it's not my browser. Since I haven't heard anyone mention this before, though, I suppose it could have something to do with my specific computer, OSX.4 PPC. Thanks, - kcrisman --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Is interact partly broken in 3.1.4 (or before)?
On Wed, Oct 22, 2008 at 12:58 PM, kcrisman [EMAIL PROTECTED] wrote: In 3.1.4 and 3.2.alpha0 I get very weird behavior in @interact. First, when a worksheet opens up, there is the usual long and annoying automatic evaluation of the @interact cells (which I feel is not a feature, though perhaps not a bug... but I couldn't find where this was mentioned before in the lists or Trac). The automatic evaluation of all @interact cells is a feature. Do you wish that this did not occur, and that users had to explicitly hit shift-enter (or click some button) to fire up any interact? It would be easy to change the implementation to have that behavior (in fact, that would be a lot easier to do than the current implementation). At the end of this, in both versions I get long error message ending with ValueError: invalid literal for int() with base 10: 'NaN' in cells with no errors. The NaN error could be specific to my cells, but there should not be any error. Then, upon Shift-Entering the @interact cell, I *do* get the correct graphic, but there are no sliders! I only get the variable names, but not the sliders. I have not tried this with other input types, so it is possible it is only the sliders this happens for. I'm sorry I can't diagnose this any further; my previous version is 3.0.6, and that works fine, so whatever this is was introduced between there and 3.1.4. V. 3.0.6 still works even after I get the errors on the newer versions, so it's not my browser. Since I haven't heard anyone mention this before, though, I suppose it could have something to do with my specific computer, OSX.4 PPC. Why don't you post a link to your worksheet? William --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Odd behavior of gradient()
The reference manual shows the following example for the gradient()
function:
sage: x,y = var('x y')
sage: f = x^2+y^2
sage: f.gradient()
(2*x, 2*y)
However, if instead I enter:
sage: x,y,n = var('x y n')
sage: f = x^n+y^n
sage: f.gradient()
(y^n*log(y) + x^n*log(x), n*x^(n - 1), n*y^(n - 1))
(not what I wanted, but I can understand what happened.)
So I tried:
sage: f(x,y) = x^n+y^n
sage: f.gradient()
((x, y) |-- y^n*log(y) + x^n*log(x), (x, y) |-- n*x^(n - 1), (x, y)
|-- n*y^(n - 1))
So even if I specify that f is a function of x and y,
gradient() still insists on also differentiating w.r.t. n
How do I tell gradient() that n is a constant?
Thanks in advance for insights.
Jim Clark
--~--~-~--~~~---~--~~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-support] Re: Odd behavior of gradient()
Jim Clark wrote:
The reference manual shows the following example for the gradient()
function:
sage: x,y = var('x y')
sage: f = x^2+y^2
sage: f.gradient()
(2*x, 2*y)
However, if instead I enter:
sage: x,y,n = var('x y n')
sage: f = x^n+y^n
sage: f.gradient()
(y^n*log(y) + x^n*log(x), n*x^(n - 1), n*y^(n - 1))
(not what I wanted, but I can understand what happened.)
So I tried:
sage: f(x,y) = x^n+y^n
sage: f.gradient()
((x, y) |-- y^n*log(y) + x^n*log(x), (x, y) |-- n*x^(n - 1), (x, y)
|-- n*y^(n - 1))
So even if I specify that f is a function of x and y,
gradient() still insists on also differentiating w.r.t. n
How do I tell gradient() that n is a constant?
Good point. Right now, the gradient function looks like this:
from sage.modules.free_module_element import vector
l=[self.derivative(x) for x in self.variables()]
return vector(l)
That second line should probably be
l=[self.derivative(x) for x in self.arguments()]
and then your last example should work.
Jason
--~--~-~--~~~---~--~~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-support] Re: Odd behavior of gradient()
Jason Grout wrote:
Jim Clark wrote:
The reference manual shows the following example for the gradient()
function:
sage: x,y = var('x y')
sage: f = x^2+y^2
sage: f.gradient()
(2*x, 2*y)
However, if instead I enter:
sage: x,y,n = var('x y n')
sage: f = x^n+y^n
sage: f.gradient()
(y^n*log(y) + x^n*log(x), n*x^(n - 1), n*y^(n - 1))
(not what I wanted, but I can understand what happened.)
So I tried:
sage: f(x,y) = x^n+y^n
sage: f.gradient()
((x, y) |-- y^n*log(y) + x^n*log(x), (x, y) |-- n*x^(n - 1), (x, y)
|-- n*y^(n - 1))
So even if I specify that f is a function of x and y,
gradient() still insists on also differentiating w.r.t. n
How do I tell gradient() that n is a constant?
Good point. Right now, the gradient function looks like this:
from sage.modules.free_module_element import vector
l=[self.derivative(x) for x in self.variables()]
return vector(l)
That second line should probably be
l=[self.derivative(x) for x in self.arguments()]
and then your last example should work.
I've posted a patch to http://trac.sagemath.org/sage_trac/ticket/4343
Can you apply the patch and test it out?
Here is the new behavior:
sage: f(x,y) = x^n+y^n
sage: f.gradient()
((x, y) |-- n*x^(n - 1), (x, y) |-- n*y^(n - 1))
sage: f.gradient([y,x])
((x, y) |-- n*y^(n - 1), (x, y) |-- n*x^(n - 1))
Thanks,
Jason
--~--~-~--~~~---~--~~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-support] Re: Is interact partly broken in 3.1.4 (or before)?
The automatic evaluation of all @interact cells is a feature. Do you wish that this did not occur, and that users had to explicitly hit shift-enter (or click some button) to fire up any interact? It would be easy to change the implementation to have that behavior (in fact, that would be a lot easier to do than the current implementation). Like I said, I wasn't sure if that was a feature or not. One reason I feel it is a bug is because if the @interact cell depends on *non*- interact cells (e.g. if you defined some function earlier and then use it interactively) you just get error messages upon startup. But I wouldn't want to try to sway either way; it just makes loading things up long. If it was easy to have a evaluate all interact button like the pretty print one, that might help, but others may find the auto- evaluate useful, so I don't know what the 'right' answer is. Why don't you post a link to your worksheet? http://www.math.uchicago.edu/~crisman/Weird_Interact_Behavior_Test.sws But even the following code does it. @interact def _(k=slider(0,5,1,1)): P1=plot(lambda x: x^k, 0,1) show(P1) Interestingly, with just one @interact cell, I get the graph but can't do slider; once there are two or more @interact cells, at least one gives these weird error messages involving NaN, etc, which Shift- Entering clears up (still without slider). So maybe there are two separate issues, I'm not sure. - kcrisman --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Odd behavior of gradient()
On Oct 22, 2008, at 5:28 PM, Jason Grout wrote: I've posted a patch to http://trac.sagemath.org/sage_trac/ticket/4343 Can you apply the patch and test it out? Here is the new behavior: sage: f(x,y) = x^n+y^n sage: f.gradient() ((x, y) |-- n*x^(n - 1), (x, y) |-- n*y^(n - 1)) sage: f.gradient([y,x]) ((x, y) |-- n*y^(n - 1), (x, y) |-- n*x^(n - 1)) Thanks for the quick response, Jason. As for applying the patch... I run sage from a binary distribution that I downloaded. I know I can manually edit the calculus.py file in the executable path on my system. Will a changed file be picked up automatically when I run sage? Again, thanks. Jim --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Odd behavior of gradient()
Jim Clark wrote:
On Oct 22, 2008, at 5:28 PM, Jason Grout wrote:
I've posted a patch to http://trac.sagemath.org/sage_trac/ticket/4343
Can you apply the patch and test it out?
Here is the new behavior:
sage: f(x,y) = x^n+y^n
sage: f.gradient()
((x, y) |-- n*x^(n - 1), (x, y) |-- n*y^(n - 1))
sage: f.gradient([y,x])
((x, y) |-- n*y^(n - 1), (x, y) |-- n*x^(n - 1))
Thanks for the quick response, Jason. As for applying the patch...
I run sage from a binary distribution that I downloaded.
I know I can manually edit the calculus.py file in the executable
path on my system.
Will a changed file be picked up automatically when I run sage?
You have to do sage -b first.
The -b makes Sage rebuild itself to incorporate changes. The first time
you run it, it will take a while (maybe 20 minutes?). After that,
depending on the changes you make, it will take seconds.
If you're not sure how to apply the patch, probably the easiest way to
apply the patch is to do the following at the sage command line:
hg_sage.apply('http://trac.sagemath.org/sage_trac/attachment/ticket/4343/gradient.patch?format=raw')
Then quit out of Sage, run sage -b, then start sage back up again.
Thanks,
Jason
--~--~-~--~~~---~--~~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-support] Re: Odd behavior of gradient()
On Wed, Oct 22, 2008 at 7:17 PM, Jason Grout
[EMAIL PROTECTED] wrote:
Jim Clark wrote:
On Oct 22, 2008, at 5:28 PM, Jason Grout wrote:
I've posted a patch to http://trac.sagemath.org/sage_trac/ticket/4343
Can you apply the patch and test it out?
Here is the new behavior:
sage: f(x,y) = x^n+y^n
sage: f.gradient()
((x, y) |-- n*x^(n - 1), (x, y) |-- n*y^(n - 1))
sage: f.gradient([y,x])
((x, y) |-- n*y^(n - 1), (x, y) |-- n*x^(n - 1))
Thanks for the quick response, Jason. As for applying the patch...
I run sage from a binary distribution that I downloaded.
I know I can manually edit the calculus.py file in the executable
path on my system.
Will a changed file be picked up automatically when I run sage?
You have to do sage -b first.
The -b makes Sage rebuild itself to incorporate changes. The first time
you run it, it will take a while (maybe 20 minutes?). After that,
depending on the changes you make, it will take seconds.
Actually it should now be very fast the first time, even for
binary installs. If not, please let me know.
If you're not sure how to apply the patch, probably the easiest way to
apply the patch is to do the following at the sage command line:
hg_sage.apply('http://trac.sagemath.org/sage_trac/attachment/ticket/4343/gradient.patch?format=raw')
Then quit out of Sage, run sage -b, then start sage back up again.
William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-support] Re: Is interact partly broken in 3.1.4 (or before)?
I have noticed similar things as well; sometimes I have to reload to get interact cells to appear correctly. The automatic evaluation of interact cells bothers me; I think it would be better if this was changed. Is it not enough to use #auto? - William's comments suggest things are more complicated, but if not #auto already provides the same mechanism. -Marshall On Oct 22, 7:45 pm, kcrisman [EMAIL PROTECTED] wrote: The automatic evaluation of all @interact cells is a feature. Do you wish that this did not occur, and that users had to explicitly hit shift-enter (or click some button) to fire up any interact? It would be easy to change the implementation to have that behavior (in fact, that would be a lot easier to do than the current implementation). Like I said, I wasn't sure if that was a feature or not. One reason I feel it is a bug is because if the @interact cell depends on *non*- interact cells (e.g. if you defined some function earlier and then use it interactively) you just get error messages upon startup. But I wouldn't want to try to sway either way; it just makes loading things up long. If it was easy to have a evaluate all interact button like the pretty print one, that might help, but others may find the auto- evaluate useful, so I don't know what the 'right' answer is. Why don't you post a link to your worksheet? http://www.math.uchicago.edu/~crisman/Weird_Interact_Behavior_Test.sws But even the following code does it. @interact def _(k=slider(0,5,1,1)): P1=plot(lambda x: x^k, 0,1) show(P1) Interestingly, with just one @interact cell, I get the graph but can't do slider; once there are two or more @interact cells, at least one gives these weird error messages involving NaN, etc, which Shift- Entering clears up (still without slider). So maybe there are two separate issues, I'm not sure. - kcrisman --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Is interact partly broken in 3.1.4 (or before)?
Marshall Hampton wrote: I have noticed similar things as well; sometimes I have to reload to get interact cells to appear correctly. The automatic evaluation of interact cells bothers me; I think it would be better if this was changed. Is it not enough to use #auto? - William's comments suggest things are more complicated, but if not #auto already provides the same mechanism. +1 to interact cells not auto-evaluating, since we can already do this with #auto. Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] RQ / QR Decomposition for General Rings
Hi, I need to do an RQ decomposition (though QR would be a start) for a matrix with entries in Laurent series ring over a finite field. A matrix over ZZ and other special rings could be sent to SciPy to do the decomposition, but Laurent series aren't quite so amenable. If anyone has some good ideas to do this, I would appreciate it. Most of the algorithms I have seen take the norm of a vector to normalize the rows of Q. There's not a square root in the Laurent series ring, so one might need to just use the sum of squares of the entries of the vector. The rows of Q won't be normalized in that case, but that's fine for what I need. -Salman --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
