On Jul 31, 4:27 pm, Mitesh Patel 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)')
> ['MPFI', 'g
On Jul 31, 4:27 pm, Mitesh Patel 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)')
> ['MPFI', 'g
On Jul 29, 9:12 pm, kcrisman 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 use it. But most
On Jul 28, 5:47 pm, Burcin Erocal 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 opened the
On Jul 28, 2:21 am, kcrisman wrote:
> On Jul 27, 1:17 am, Henryk Trappmann 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 for n in ()
/opt/sage-
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 nhttp://groups.google.com/group/sage-devel
URL: http:
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 thi
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, sen
On Nov 11, 12:23 pm, Tim Joseph Dumol 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//4.0.3/
Thank you a lot, now I compiled sage-4.2 and indeed all the humble
plot behaviour is gone :) :) :)
n track down
> > what a best fix might be? Thanks.
>
> > - kcrisman
>
> > On Nov 8, 3:02 pm, Henryk Trappmann wrote:
> >> Did anyone notice that the plot scale sometimes does not contain any
> >> number or sometimes only contains one number? Unfortunately I
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, vis
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, visi
On 22 Aug., 09:50, "Nicolas M. Thiery"
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 possible, try to evaluate
On 21 Aug., 14:06, David Joyner 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 principle.
Som
On 21 Aug., 14:06, David Joyner 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 principle.
Som
No, not yet. I thought I first need a person that would kinda mentor
it.
On 21 Aug., 13:14, David Joyner 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
>
> Trappmann wrote:
>
>
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
pickl
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 before
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);
:
0.0026041
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 wrote:
> Now a new version is out, picklable, coerceable and 100% coverage,
> though not comletely co
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: RR.coerce_ma
On Mar 31, 4:35 pm, William Stein 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 to be stored s
On Mar 31, 4:35 pm, William Stein 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 with a __call__
On Mar 31, 12:34 pm, David Roe 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 implements the __
On Mar 31, 10:49 am, Franco Saliola 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, as well.
On Mar 31, 10:41 am, Franco Saliola 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 cod
On Mar 31, 9:55 am, Robert Bradshaw
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.
--~--~-~--~~~---~--~~
To post to this gr
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 M.
sage repository (and how is this be done). So that if people are
interested in the current state they just need to take a look at the
sage repository, and can give early feedback.
Regards,
Henryk
On Mar 27, 4:25 am, "Nicolas M. Thiery"
wrote:
> On Thu, Mar 26, 2009 at 05:58:17AM -0700
On Mar 26, 3:52 pm, William Stein 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 returns a power
On Mar 26, 5:07 am, mabshoff 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, composition, shift, differentiat
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, sen
On Mar 25, 8:44 pm, John H Palmieri 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, you know I am German.
On Mar 25, 8:08 pm, mabshoff 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 to
retest.
My class
On Mar 25, 5:20 pm, John H Palmieri wrote:
> On Mar 25, 6:05 am, Henryk Trappmann 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 not w
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?
http://github.com/bo198214/hyperops/raw/a5b716d48751778ffccff6769a96d9bea428b4d1/powerseries.py
On Mar 25, 4:58 pm, William Stein wrote:
> On Wed, Mar 25, 2009 at 6:14 AM, Henryk Trappmann
>
>
>
> wrote:
>
> > On Mar 9, 5:42 am, "Nicolas M. Thiery"
> &
On Mar 9, 5:42 am, "Nicolas M. Thiery"
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 powerseries package and
Because Bourbaki and Serre said so?
Sorry guys but thats the strangest justificiation Iv ever heard.
At the first place for me is understandability, which is often coupled
with common use.
Imho the \mathbb notation is the most widespread and most recognized
variant.
Another important aspect is una
On Mar 23, 8:57 pm, Robert Bradshaw
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 is that the curve shall lo
On Mar 22, 3:45 pm, Carl Witty 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: arctan(x),lambda x:
> arc
Another evil example:
parametric_plot((lambda x: arctan(x),lambda x: arctan(x)**2),
(-1000,1000))
It seems that the plot algorithm is somehow deficient in those cases.
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsub
Oh, thank you. I wasnt aware of it.
On Mar 22, 11:11 am, Mike Hansen wrote:
> On Mar 22, 3:03 am, Henryk Trappmann wrote:
>
> > sage: a = float(1-2**(-50))
> > sage: repr(a)
> > '0.99911'
> > sage: print(a)
> > 1.0
>
> >
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
sage-devel-unsubscr...@googleg
On Mar 22, 2:54 am, Jason Grout 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 points, why can it slow down so
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 arg
On Mar 21, 11:50 pm, Robert Bradshaw
wrote:
> I have actually already implemented this--I should get my code
> cleaned up and attach it to a ticket. (I put it on old waiting for
> fast_callable to handle complex inputs, but that's not a requirement).
Where can I get your code?
And what exact
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 ha
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)
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
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 n
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, 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 s
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 = PowerSeriesRing
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 coer
On 1 Jun., 18:56, Carl Witty <[EMAIL PROTECTED]> wrote:
> Sage has such a decision procedure built in to its implementation of
> QQbar, the algebraic numbers.
But I have to say they are quite hidden in the reference manual.
Thank you for this hint. I also found AA the algebraic reals if your
comp
> 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
> 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 expr
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 precis
> > 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
>
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 =
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) == RR(log(2
66 matches
Mail list logo
