ASKSAGE: Sage Q&A Forum - Individual question feedhttp://ask.sagemath.org/questions/Q&A Forum for SageenCopyright Sage, 2010. Some rights reserved under creative commons license.Mon, 23 May 2011 02:14:50 -0500Getting range from things which aren't integers yet, but will behttp://ask.sagemath.org/question/8126/getting-range-from-things-which-arent-integers-yet-but-will-be/Consider the following:
sage: f(n)=ceil(sqrt(2*n)-1/2)
sage: g = lambda n: ceil(sqrt(2*n)-1/2)
Then we get
sage: [0..g(3)]
[0, 1, 2]
sage: [0..f(3)]
1068 else:
-> 1069 icount = int(math.ceil(float(count) - endpoint_tolerance))
TypeError: unable to simplify to float approximation
And I understand why this is. But it's still annoying. We should be able to avoid lambda functions if at all possible.
Similarly, trying workarounds involving numerical evaluation like
sage: f(n)=ceil(RR(sqrt(2*n)-1/2))
cause problems about numerically evaluating symbolic expressions - rightly, though it would be nice to have a way to hold that evaluation.
So my two questions are, in both of these cases, is there a reasonable way to fix Sage so that these things work?
An accepted answer will include a link to an existing or newly created Trac ticket that has a concrete idea.Sat, 21 May 2011 16:03:27 -0500http://ask.sagemath.org/question/8126/getting-range-from-things-which-arent-integers-yet-but-will-be/Answer by Kelvin Li for <p>Consider the following:</p>
<pre><code>sage: f(n)=ceil(sqrt(2*n)-1/2)
sage: g = lambda n: ceil(sqrt(2*n)-1/2)
</code></pre>
<p>Then we get </p>
<pre><code>sage: [0..g(3)]
[0, 1, 2]
sage: [0..f(3)]
1068 else:
-> 1069 icount = int(math.ceil(float(count) - endpoint_tolerance))
TypeError: unable to simplify to float approximation
</code></pre>
<p>And I understand why this is. But it's still annoying. We should be able to avoid lambda functions if at all possible.</p>
<p>Similarly, trying workarounds involving numerical evaluation like</p>
<pre><code>sage: f(n)=ceil(RR(sqrt(2*n)-1/2))
</code></pre>
<p>cause problems about numerically evaluating symbolic expressions - rightly, though it would be nice to have a way to hold that evaluation.</p>
<p>So my two questions are, in both of these cases, is there a reasonable way to fix Sage so that these things work? </p>
<p>An accepted answer will include a link to an existing or newly created Trac ticket that has a concrete idea.</p>
http://ask.sagemath.org/question/8126/getting-range-from-things-which-arent-integers-yet-but-will-be/?answer=12371#post-id-12371Calling `simplify` is a hack:
sage: f(x) = ceil(sqrt(2*x) - 1/2)
sage: [0 .. f(3).simplify()]
[0, 1, 2]Sat, 21 May 2011 17:53:39 -0500http://ask.sagemath.org/question/8126/getting-range-from-things-which-arent-integers-yet-but-will-be/?answer=12371#post-id-12371Comment by kcrisman for <p>Calling <code>simplify</code> is a hack:</p>
<pre><code>sage: f(x) = ceil(sqrt(2*x) - 1/2)
sage: [0 .. f(3).simplify()]
[0, 1, 2]
</code></pre>
http://ask.sagemath.org/question/8126/getting-range-from-things-which-arent-integers-yet-but-will-be/?comment=21683#post-id-21683Nice for this case! Of course, in general (say if there was something other than square root) that might not work; I'm looking for a general solution. We shouldn't need this.Mon, 23 May 2011 02:14:50 -0500http://ask.sagemath.org/question/8126/getting-range-from-things-which-arent-integers-yet-but-will-be/?comment=21683#post-id-21683