On Jul 31, 4:27 pm, Mitesh Patel qed...@gmail.com wrote:
You could try using sage.misc.citation.get_systems:
sage: var('n, k');
sage: sum(1 / sum(k, k, 1, n), n, 1, infinity)
2
sage: from sage.misc.citation import get_systems
sage: get_systems('sum(1 / sum(k, k, 1, n), n, 1, infinity)')
On Jul 29, 9:12 pm, kcrisman kcris...@gmail.com wrote:
I will point out, though, that you clearly *do* use Maxima, since you
tried to do this in Sage, which uses Maxima heavily.
This may be, but I dont know about it.
I know that Sage uses Maxima, but neither do I know what Maxima is,
nor how to
On Jul 28, 5:47 pm, Burcin Erocal bur...@erocal.org wrote:
Can you open a ticket about these problems with the binomial (including
the either m or x-m must be an integer error mentioned in kcrisman's
message?
The bug in maxima for the evaluation of the sum should also be a
separate ticket.
I
On Jul 28, 2:21 am, kcrisman kcris...@gmail.com wrote:
On Jul 27, 1:17 am, Henryk Trappmann bo198...@googlemail.com wrote:
sage: sum(binomial(n,k)*binomial(k-1,j)*(-1)**(k-1-j),k,j+1,n)
In fact, the answer appears to always be 1 or 0. Is that true?
Yes, its 1 for n=j+1 and (of course) 0
sage: (n,k,j)=var('n,k,j')
sage: sum(binomial(n,k)*binomial(k-1,j)*(-1)**(k-1-j),k,j+1,n)
0
sage: (n,j)=(5,3)
sage: sum(binomial(n,k)*binomial(k-1,j)*(-1)**(k-1-j) for k in range(j
+1,n+1))
1
The symbolic sum being 0 is only trivially valid for nj+1.
--
To post to this group, send an email to
Take for example the following code:
sage: f = {0:1}
sage: for n in range(100): f[n+1] = sqrt(2.0)**f[n]
sage: line([(n,f[n]) for n in range(50,100)])
Then on the y-Axis every tick number is 2e except the topmost is
2.
One can not distinguish y values by their displayed numbers.
Another plot
Hallo,
it seems currently (sage 4.2) that the plot scale is not recomputed
when changing the aspect_ratio, but simply graphically resized. This
leads to possibly overlapping numbers, and looks somehow squeezed.
Example:
p = plot(lambda x: 10*x, (0,1)); p.set_aspect_ratio(1); p
--
To post to
The binomial is buggy again (sage 4.2):
In [143]: [binomial(1,1),binomial(1,2),binomial(1,3),binomial(1,4)]
Out[143]: [1, 0, 0, 0]
In [144]: [binomial(1.0,1),binomial(1.0,2),binomial(1.0,3),binomial
(1.0,4)]
Out[144]: [1.00, 0.000, NaN, NaN]
--
To post to this group,
On Nov 11, 12:23 pm, Tim Joseph Dumol t...@timdumol.com wrote:
The GCC error can be fixed by copying libgcc from the system libraries as
so:
$ cp /usr/lib/libgcc_s.so /opt/sage-4.2/local/lib/gcc-lib/uname/4.0.3/
Thank you a lot, now I compiled sage-4.2 and indeed all the humble
plot
track down
what a best fix might be? Thanks.
- kcrisman
On Nov 8, 3:02 pm, Henryk Trappmann bo198...@googlemail.com wrote:
Did anyone notice that the plot scale sometimes does not contain any
number or sometimes only contains one number? Unfortunately I have no
simple example
Did anyone notice that the plot scale sometimes does not contain any
number or sometimes only contains one number? Unfortunately I have no
simple example to reproduce. But its not a problem with too small or
too big numbers.
I think the plot function should guaranty that at least two numbers
are
oh thanks. The mpmath is even capable of the complex branches.
--~--~-~--~~~---~--~~
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,
has Sage the Lambert W function implemented?
I can not find it.
--~--~-~--~~~---~--~~
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,
On 21 Aug., 14:06, David Joyner wdjoy...@gmail.com wrote:
1. How do you know it has 100% coverage. Did you run some kind of script?
Yes, sage -coverage; William explained that to me.
2. I'm used to seeing __init__ immediately after the class
Ya the methods are not ordered according a certain
On 22 Aug., 09:50, Nicolas M. Thiery nicolas.thi...@u-psud.fr
wrote:
Henryk: in the mean time, could you please create a ticket on trac for
this
Yes, yes, I did already. See above (unfortunately the post seems to be
doubled, so if possible, would anyone delete the other post).
and, if
My last post on this topic is now nearly 5 months time ago:
http://groups.google.com/group/sage-devel/browse_thread/thread/49069f5090e0f4b9/eaabced82d61573b
I didnt get any reply to the formal powerseries code I proposed.
The code had 100% coverage and I put quite some effort into making it
No, not yet. I thought I first need a person that would kinda mentor
it.
On 21 Aug., 13:14, David Joyner wdjoy...@gmail.com wrote:
Did you create a ticket and a patch for it on trac?
If so, what is the trac number?
On Fri, Aug 21, 2009 at 6:40 AM, Henryk
Trappmannbo198...@googlemail.com
sage: version()
'Sage Version 4.0.1, Release Date: 2009-06-06'
sage: var('a d')
(a, d)
sage: A = matrix([[a,0],[1,d]])
sage: A.eigenvalues()
[d, a]
sage: A.jordan_form()
---
RuntimeError Traceback
Ah now I see, you mean though it displays 1/384 it is internally still
the above sum, which is computed when evaluated with n.
Well but then this contains imho 2 bugs:
1. 1**(a/b) should be the integer 1.
2. The display of a SymbolicArithmetic should show whats really there
and not reduce
sage: a = 1/(48*sqrt(1)) - 7/(96*1**(3/2)) + 3/(32*1**(5/2)) - 5/
(128*1**(7/2))
sage: a
1/384
sage: for k in range(5): print a.n(digits=10-k)
:
0.00260418
0.00260416669
0.0026041665
0.002604164
0.00260419
sage: b = 1/384
sage: for k in range(5): print b.n(digits=10-k);
:
Now a new version is out, picklable, coerceable and 100% coverage,
though not comletely complete yet.
But getting it to pickle was really *some* effort, 60 inner functions
had to converted to outer classes, but now it works.
However some strange effects occured with coercing:
sage:
Oh, forgot the link:
http://github.com/bo198214/hyperops/raw/157fa46ca4439d0e022c1c6249c5862d1d2569c2/formal_powerseries.py
Grateful for any comments.
On Apr 6, 1:49 pm, Henryk Trappmann bo198...@googlemail.com wrote:
Now a new version is out, picklable, coerceable and 100% coverage,
though
On Mar 31, 9:55 am, Robert Bradshaw rober...@math.washington.edu
wrote:
There is also _rmul_ and _lmul_ which are used to implement
multiplication by a scalar.
Thats great, I was wandering how to recognize scalar multplication.
Thank you Robert.
On Mar 31, 10:41 am, Franco Saliola sali...@gmail.com wrote:
On Sat, Mar 28, 2009 at 9:17 AM, Henryk Trappmann
I would guess that you are probably just loading/attaching some local
files to a Sage session. If that's correct, then that is the cause of
this problem. When you merge your code
On Mar 31, 10:49 am, Franco Saliola sali...@gmail.com wrote:
I'd rather it were named the more verbose, but significantly more
explicit, FormalPowerSeriesRing. This fits better with the naming of
all the other rings, and we do have tab completion after all.
I prefer FormalPowerSeriesRing,
On Mar 31, 12:34 pm, David Roe r...@math.harvard.edu wrote:
Having written a lazy p-adics class, my guess is that your pickling errors
have to do with the fact that you're storing a function. If you replace all
of the local functions that you're storing with callable classes (ie a class
that
On Mar 31, 4:35 pm, William Stein wst...@gmail.com wrote:
(1) You can't pickle objects with attributes that are functions. If
your code currently only works with attributes that are functions, it
will need to be rewritten. Note that callable objects are fine as
attributes (e.g., objects
On Mar 31, 4:35 pm, William Stein wst...@gmail.com wrote:
Note that callable objects are fine as
attributes (e.g., objects with a __call__ method defined).
Actually I dont see how to get it to work:
I want to give a function as initialization parameter to
FormalPowerSeries.
This function needs
Ok, here is a first shot that has 100% coverage (except dumps):
http://github.com/bo198214/hyperops/raw/09e1da3372d7b431cdf557ffe164df9f91c08e68/formal_powerseries.py
I finally decided to name it FPSRing, for Formal Power Series Ring. It
resides in sage.rings.formal_powerseries
I hope Nicolas
, Mar 26, 2009 at 05:58:17AM -0700, Henryk Trappmann wrote:
On Mar 26, 5:07 am, mabshoff mabsh...@googlemail.com wrote:
Well, I will not merge a second implementation as long as there is no
clear roadmap for resolving the problem.
The basic functionality of Mike's powerseries class is also
On Mar 26, 5:07 am, mabshoff mabsh...@googlemail.com wrote:
Well, I will not merge a second implementation as long as there is no
clear roadmap for resolving the problem.
The basic functionality of Mike's powerseries class is also contained
in my class.
That is add, multiply, power,
On Mar 26, 3:52 pm, William Stein wst...@gmail.com wrote:
2. Make sure your code has 100% doctest coverage.
I have two questions here.
1. I work intensely with functions defined inside of methods (because
one attribute of the power series is a function. It needs to be
defined whenever a method
On Mar 9, 5:42 am, Nicolas M. Thiery nicolas.thi...@u-psud.fr
wrote:
What's the status of the merge of your implementations of power
series? I need a couple functionalities not yet in Mike's
implementation, and mainly:
- conversion from a polynomial
- division
Actually I improved my
http://github.com/bo198214/hyperops/raw/a5b716d48751778ffccff6769a96d9bea428b4d1/powerseries.py
On Mar 25, 4:58 pm, William Stein wst...@gmail.com wrote:
On Wed, Mar 25, 2009 at 6:14 AM, Henryk Trappmann
bo198...@googlemail.com wrote:
On Mar 9, 5:42 am, Nicolas M. Thiery nicolas.thi...@u
Oh, then I have some questions.
First how shall the class finally be named (the current name
PowerSeriesI is rather a working title):
LazyPowerSeries (conflict with Mike Hansen's package),
InfinitePowerSeries, LIPS?
and into which package should it go: sage.rings ?
shall it inherit from Ring?
On Mar 25, 5:20 pm, John H Palmieri jhpalmier...@gmail.com wrote:
On Mar 25, 6:05 am, Henryk Trappmann bo198...@googlemail.com wrote:
Because Bourbaki and Serre said so?
Sorry guys but thats the strangest justificiation Iv ever heard.
I don't know quite where you heard it, because it's
On Mar 25, 8:08 pm, mabshoff mabsh...@googlemail.com wrote:
Why can't this code be patched into Mike's LazyPowerSeries class? I
really don't think we want the same thing implemented twice in Sage
with overlapping functionality.
For me its just too much effort to port all the functionality and
On Mar 25, 8:44 pm, John H Palmieri jhpalmier...@gmail.com wrote:
Meanwhile, your posts leave the impression of you insulting people
whom you've never met. I don't have any interest in responding to
you.
Sorry, if I was insulting. The topic of blind trust in authorities
just hit a button,
I just encountered the ambiguouty:
binomial(-1.0,2) == 1.0
binomial(-1,2) == 0
do we need 2 diferent names? I think the second form is also needed
somewhere.
But of course one needs the first form also for integers.
--~--~-~--~~~---~--~~
To post to this group,
On Mar 23, 8:57 pm, Robert Bradshaw rober...@math.washington.edu
wrote:
Do you mean something likehttp://trac.sagemath.org/sage_trac/ticket/
3813 , and if so, why isn't this used by default?
Ya thats for plot, I think we need a slightly different approach for
parametric_plot.
The common demand
On Mar 22, 2:54 am, Jason Grout jason-s...@creativetrax.com wrote:
I think the main reason is to give *massive* speedups (i.e., orders of
magnitude). Can you post an example of the problems you are experiencing?
I thought plotting are just some arithmetical operations for around
hundret
sage: a = float(1-2**(-50))
sage: repr(a)
'0.99911'
sage: print(a)
1.0
Is that intended?
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
On Mar 22, 3:45 pm, Carl Witty carl.wi...@gmail.com wrote:
You can get a nicer plot by either increasing the plot_points, or
decreasing the range:
parametric_plot((lambda x: arctan(x),lambda x:
arctan(x)**2),(-1000,1000),marker='.', plot_points=1)
parametric_plot((lambda x:
As I see there are no specific plot commands for complex functions.
There are 3 types that would be preferable:
1. parametric plot
2. contour plot
3. conformal plot
The parametric plot can be simulated with parametric_plot and the
contour plot with contour_plot.
However for these functions one
Is there any reason why plot converts the arguments of a function
allways to float?
This way it is impossible to zoom in, and sometimes there are strange
artifacts, like breaks in otherwise smooth functions.
Why not just take the number domain of the interval borders.
If it is QQ, then give as
Maybe its a bit off topic but in the line of thought:
I wonder whether the subset of the reals generated by
+,-,*,/,x^y,log_x y from {1} (that means it contains at least Q)
is decidable (i.e. whether we can decide equality for two given
expressions in the operations and 1).
For a start we could
On Oct 30, 6:06 pm, Ralf Hemmecke [EMAIL PROTECTED] wrote:
Formal Laurent series would also form a field.
For example the formal Laurent series are a field.
While this is certainly true mathematically, you might run into trouble
computationally.
In a (additive and commutative) monoid M
On Oct 30, 2:07 am, Mike Hansen [EMAIL PROTECTED] wrote:
Is your code posted anywhere? I'm sure we can come up with a way to
merge the two implementations.
Yes you can see it here:
http://github.com/bo198214/hyperops/tree/master/powerseries.py
it was originally developed for a different
On Oct 30, 9:44 am, Mike Hansen [EMAIL PROTECTED] wrote:
One of the main features that I need is the ability to handle
recursively/implicitly defined power series. This is currently not
possible in your code base because the series aren't lazy enough.
Yes thats true. Currently if I need
On Oct 30, 1:14 pm, Mike Hansen [EMAIL PROTECTED] wrote:
When I said recursively defined streams, I meant something a little
more general. For example, if f is a power series and g is exp(f),
then g satisfies g = \int g*f'. This translates to the following code
for the exponential of power
Hello,
I developed a package to work with infinite power series.
You can work with the power series mostly like with functions, the
actual value of a coefficient is computed when requested.
For example (the working title is PowerSeriesRingI, I like
infinite):
sage: PQ =
On Oct 30, 12:08 am, Mike Hansen [EMAIL PROTECTED] wrote:
On Wed, Oct 29, 2008 at 3:50 PM, Mike Hansen [EMAIL PROTECTED] wrote:
Hello,
On Wed, Oct 29, 2008 at 1:48 PM, Martin Rubey [EMAIL PROTECTED] wrote:
As far as I know, Mike Hansen ported Ralf Hemmecke's lazy power series,
too,
On 31 Mai, 15:59, William Stein [EMAIL PROTECTED] wrote:
At a bare minimum there is never a canonical (automatic)
coercion from elements of R to elements of S unless that coercion
is defined (as a homomorphism) on all of R.
I dont want to be heretical by why is it so important that coercion
But coercing symbolic constants into RR or CC is not a simple, (or
even well-defined?) matter. Just think of many-valued nested
radicals; or if a=sqrt(2), b=sqrt(3), c=sqrt(6), would a*b-c
simplify/coerce to 0? This is not stratightforward at all.
Is it?
I just would evaluate the
there is an obvious convention that by default we mean the positive
root.
We have to distinguish between solutions of polynomials and roots.
Roots are clearly defined mono-valued functions:
z.nth_root(n)=e^(log(z)/n)
however this function is not continuous in z, as log is not continuous
at the
Hello,
while the general rule of coercing in binary operations seems to be
towards the most unprecise,
for example
RealField(100)(1)*2 == RealField(100)(2) or
RealField(100)(1)*RealField(50)(1) == RealField(50)(1)
this rule seems to be broken when working with log(2)
not RR(1)*log(2) ==
On May 31, 3:59 pm, William Stein [EMAIL PROTECTED] wrote:
However, there is a natural homomorphism from
RR to the symbolic ring.
Hm, if this is the precondition then the coercion of say RealField(52)
to RealField(2) is not valid, because it is no homomorphism at all.
For example let R2 =
Wouldnt it then be more consistent coerce RealFields to higher
precision?
Suppose you write down an expression involving various digits of precision,
and in order to evaluate it Sage makes a sequence of *automatic*
coercions and outputs the result. Do you want an answer that has
many
On May 31, 10:55 pm, Carl Witty [EMAIL PROTECTED] wrote:
Actually, there's no homomorphism either way;
RR(R2(2)+R2(3)) != RR(R2(2)) + RR(R2(3))
Hm, thats an argument. I somehow thought that it is closer to a
homomorphism but perhaps this reasoning has no base.
IMHO, giving a+b the precision
59 matches
Mail list logo
