[sage-support] Re: Confused about rmul and lmul
I wrote a patch according to your suggestion in http://trac.sagemath.org/sage_trac/ticket/10473 Thank you. -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
Re: [sage-support] Re: Need help using RealField to get 18000 digits of accuracy in infinite sum...
On Mon, Dec 13, 2010 at 12:16 PM, Chris Seberino wrote: > > OK thanks for your help. I think I got it. The effect of RealField > is like creating a new number type. I need to make sure all my real > are of the right type. It appears integers are fine as is. Yes, exactly. Exact types (e.g. integers, rationals, symbolic expressions) will get converted to the correct degree of precision. > Here is working code... > > def test(big): > my_pi = RealField(big)(pi) > ten = RealField(big)(10.0) > constant = 100 * sqrt(my_pi/log(ten)) > ten_thou = RealField(big)(1.0) > f(k) = ten^(-k^2/ten_thou) > the_sum = RealField(big)(sum(f(k) for k in range(-big, big + > 1))) > difference = the_sum - constant > return difference You can be a bit simpler then this. E.g. sage: R = RealField(1000) sage: constant = R(100 * sqrt(pi/log(10))) # everything exact before the cast sage: ten_thou = R(1) sage: f(k) = 10^(-k^2/ten_thou) # result will be in R because ten_thou is sage: the_sum = sum(f(k) for k in range(-1000, 1001)); the_sum 116.806521814573408154703961183569656583504707301922359958037591640215510813039244934779299244023546182097713963521073027455330258514764785349144281947839532827346835171962415366657291332526181608818055375581821843529213967899316532193194799347444658828139424420035706699509726059514135509142461539243 - Robert -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] Re: Having trouble getting *ultra* high precision in this infinite sum calculation...
On Dec 13, 4:52 pm, Greg Marks wrote: > Though it is hard to resist Thierry Dumont's invitation > to a large cup of coffee, my inclination would be to > compile an MPFR program for calculations of this sort. > Incidentally, range(-1,1) is not symmetric about 0. Good point. You'd need range(-1,10001). > In fact, there's no need for negative indices at all in > this particular sum. :-) Although it might make it easier than to double except at i=0. - kcrisman -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] Re: Having trouble getting *ultra* high precision in this infinite sum calculation...
Though it is hard to resist Thierry Dumont's invitation to a large cup of coffee, my inclination would be to compile an MPFR program for calculations of this sort. Incidentally, range(-1,1) is not symmetric about 0. In fact, there's no need for negative indices at all in this particular sum. Best regards, Greg Marks | Greg Marks | | Department of Mathematics and Computer Science | | St. Louis University | | St. Louis, MO 63103-2007 | | U.S.A. | || | Phone: (314)977-7206 | | Fax: (314)977-1452 | | Web: http://math.slu.edu/~marks| -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] Re: Need help using RealField to get 18000 digits of accuracy in infinite sum...
OK thanks for your help. I think I got it. The effect of RealField is like creating a new number type. I need to make sure all my real are of the right type. It appears integers are fine as is. Here is working code... def test(big): my_pi = RealField(big)(pi) ten= RealField(big)(10.0) constant = 100 * sqrt(my_pi/log(ten)) ten_thou = RealField(big)(1.0) f(k) = ten^(-k^2/ten_thou) the_sum= RealField(big)(sum(f(k) for k in range(-big, big + 1))) difference = the_sum - constant return difference I can see difference getting smaller for test(1000), test(2000), test(3000), etc. cs -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] Re: Need help using RealField to get 18000 digits of accuracy in infinite sum...
I meant like RealField(10)(10^(-k^2/1)) But I am not wise enough in the ways of RealField to know whether one would have to do RealField(10)(1) first... presumably those who know the underlying stuff might respond :) But at least this might help you get a start on what is going on. Certainly your sum is not going to be in the extended precision field until you actually put it there, which is your last step, and hence meaningless. I also don't know how much memory this would all take - likely the paper did something a little more sophisticated than this. - kcrisman On Dec 13, 2:50 pm, Chris Seberino wrote: > On Dec 13, 1:09 pm, kcrisman wrote: > > > I think you would have to let k be in that RealField, wouldn't you? > > Or at least f(k). That might be part of the issue. If you put the > > whole sum in RealField, the precision will be that of 1.0, I > > suppose (?) ... > > How do you put k in the RealField? Notice the variable I named > constant also has a "10.0". I don't know if that is a problem. Is > there an easy way to just make EVERYTHING have high precision to be > safe? I tried eliminating my definitions and doing all on one line > but it didn't improve things... > > RealField(10)( sum(10^(-k^2/1.0) for k in range(-1,1)) > - 100*sqrt(pi/log(10.0)) ) > > cs -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] Re: Need help using RealField to get 18000 digits of accuracy in infinite sum...
On Dec 13, 1:09 pm, kcrisman wrote: > I think you would have to let k be in that RealField, wouldn't you? > Or at least f(k). That might be part of the issue. If you put the > whole sum in RealField, the precision will be that of 1.0, I > suppose (?) ... How do you put k in the RealField? Notice the variable I named constant also has a "10.0". I don't know if that is a problem. Is there an easy way to just make EVERYTHING have high precision to be safe? I tried eliminating my definitions and doing all on one line but it didn't improve things... RealField(10)( sum(10^(-k^2/1.0) for k in range(-1,1)) - 100*sqrt(pi/log(10.0)) ) cs -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] Re: Need help using RealField to get 18000 digits of accuracy in infinite sum...
On Dec 13, 1:39 pm, Chris Seberino wrote: > In a previous post I was told to use RealField if I wanted very high > degrees of accuracy. > > I'm still now sure I'm using RealField right and would appreciate any > help debugging my puzzle. > > sage: constant = 100*sqrt(pi/log(10.0)) > sage: f(k) = 10^(-k^2/1.0) > sage: N = 1 > sage: RealField(10)(sum(f(k) for k in range(-N, N))- constant) I think you would have to let k be in that RealField, wouldn't you? Or at least f(k). That might be part of the issue. If you put the whole sum in RealField, the precision will be that of 1.0, I suppose (?) ... > The infinite sum should agree with the constant to over 18000 digits. > As I increase the value of N and the size of the mantissa I can't > seem to ever get more than around 13 digits of agreement. > > (Context can be found at top of page 2 of this > paper:http://arxiv.org/abs/math.GM/0409014/) > > Sincerely, > > Chris -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] Need help using RealField to get 18000 digits of accuracy in infinite sum...
In a previous post I was told to use RealField if I wanted very high degrees of accuracy. I'm still now sure I'm using RealField right and would appreciate any help debugging my puzzle. sage: constant = 100*sqrt(pi/log(10.0)) sage: f(k) = 10^(-k^2/1.0) sage: N = 1 sage: RealField(10)(sum(f(k) for k in range(-N, N))- constant) The infinite sum should agree with the constant to over 18000 digits. As I increase the value of N and the size of the mantissa I can't seem to ever get more than around 13 digits of agreement. (Context can be found at top of page 2 of this paper: http://arxiv.org/abs/math.GM/0409014/ ) Sincerely, Chris -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] Re: Having trouble getting *ultra* high precision in this infinite sum calculation...
On Dec 13, 2:47 am, Simon King wrote: > sage: 2*sum(10^(-k^2/d) for k in range(1,2)) > 2.02019722722490674759723772962542922944721452394745083...e-1 > So there is a small progress in the summation! But I have no idea > whether at the end of the day the small progress will be enough to > cover the big difference -1.27897692436818e-13 to your theoretical > result. Thanks. I agree. Because your result is s small I'm also not sure where the problem lies. I happen to know from that paper that the 2 sides of the candidate identity agree to 18,000 digits before the error occurs!!! cs -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
Re: [sage-support] bug in automorphism group of block designs?
The procedure I am calling does not use GAP or nauty.
The algorithms nauty uses were written, from scratch, in Cython
by Robert Miller. I'm not sure what the problem is since the
same command seems to work correctly in other examples.
On Mon, Dec 13, 2010 at 4:56 AM, William Laffin wrote:
> No doubt coming from the automorphism moving blocks no?
> In gap try this:
>>LoadPackage("Design");
>
>>b:=BlockDesign(9,[
> [1,2,3],
> [4,5,6],
> [7,8,9],
> [1,5,9],
> [2,6,7],
> [3,4,8],
> [3,5,7],
> [1,6,8],
> [2,4,9],
> [1,4,7],
> [2,5,8],
> [3,6,9]]);;
>>g:=AutomorphismGroup(b);
>
> What set is g acting on? I can't tell, I'm on windows right now, and
> the linux machine i have access too does not have nauty or design
> configured correctly with GAP. But I'm pretty sure your error comes
> from nauty giving the permutation group on blocks and not points.
>
>
> On Thu, Dec 2, 2010 at 2:16 PM, David Joyner wrote:
>> Hi:
>>
>> I'l not sure why the following error arises.
>>
>>
>> sage: from sage.combinat.designs.block_design import steiner_triple_system
>> sage: sts = steiner_triple_system(9)
>> sage: sts.block_design_checker(2,9,3,1)
>> True
>> sage: sts.parameters()
>> (2, 9, 3, 1)
>> sage: B = sts.blocks()
>> sage: sts.points()
>> [0, 1, 2, 3, 4, 5, 6, 7, 8]
>> sage: BD = BlockDesign(9, B)
>> sage: BD.automorphism_group()
>> ---
>> TypeError Traceback (most recent call last)
>>
>> .
>>
>> TypeError: permutation PermList([1, 2, 4, 3, 8, 12, 11, 5, 9, 10, 7,
>> 6]) not in SymmetricGroup(9)
>>
>>
>>
>> Does anyone on this list have an idea?
>>
>> - David Joyner
>>
>> --
>> To post to this group, send email to sage-support@googlegroups.com
>> To unsubscribe from this group, send email to
>> sage-support+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/sage-support
>> URL: http://www.sagemath.org
>>
>
--
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to
sage-support+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org
Re: [sage-support] Re: Having trouble getting *ultra* high precision in this infinite sum calculation...
Why not compute in QQ? Sage is done for this...: sage: s1=sum(10^(-q^2/1) for q in range(-1,1)) (wait some time...) sage: s2=sum(10^(-k^2/1) for k in range(-2,2)) (drink a large cup of coffee).. then: sage: t=s1-s2 sage: float(t) 0.0 ok, let's try more precise: sage: R=RealField(1000) sage: R(t) -1.02019. e-1000 e-1000! ah, ah! sage: R=RealField(100) sage: R(t) -1.0201972272249067475972377296e-1 ok. sage: R=RealField(53) sage: R(t) -1.02019722722491e-1 ok! BUT: sage: RDF(t) 0.0 RDF and RealField(53) have the same mantissa, but not the same exposant size! Yours t.d. Le 13/12/2010 09:47, Simon King a écrit : Hi Chris, disclaimer: I am no expert in numerics. On 13 Dez., 07:34, Chris Seberino wrote: Why isn't the error improving as I increase the number of terms that are summed? Am I doing something wrong in Sage? (Yes it is possible that this infinite sum converges unimaginably slowly so I wanted to check first I wasn't doing something dumb.) I think you use a precision that is too small The summands are of course very small. So, comparing the two results in a field with 53 digits precision may be pointless: sage: sum(10^(-k^2/1.0) for k in range(-2,2)) == sum(10^(-k^2/1.0) for k in range(-1,1)) True Note that the denominator "1.0" in your exponent belongs to RR, which by default has 53 digits precision. Let us raise it to 6000: sage: d = RealField(6000)(1) sage: d.precision() 6000 Unfortunately, the sums are now taking a very long time to compute. But we are only interested in their difference. So, it suffices to do (still taking about one minute): sage: 2*sum(10^(-k^2/d) for k in range(1,2)) 2.02019722722490674759723772962542922944721452394745083...e-1 So there is a small progress in the summation! But I have no idea whether at the end of the day the small progress will be enough to cover the big difference -1.27897692436818e-13 to your theoretical result. Cheers, Simon -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] Re: Confused about rmul and lmul
On Dec 11, 1:36 pm, Jason Grout wrote: > > I think it may have just been a copy-paste error from the lmul function. There is an error in lmul, but there is also an inconsistency between the manual and the docstring for rmul (that is, if I'm reading them correctly): According to the manual, r*s returns the value of s._rmul_(r). According to the docstring for _rmul_, it is s*r which should return the value of s._rmul_(r). Perhaps Kwankyu and I are misunderstanding one or both of the sources. In any case, the real question of which method gets called can be easily tested using the Localization example [1] from the same manual page. I changed _rmul_ and left _lmul_ alone, so we have def _rmul_(self, c): return LocalizationElement(self.parent(), c**2 * self._value) def _lmul_(self, c): return LocalizationElement(self.parent(), self._value * c) sage: S = Localization([2]); S Integer Ring localized at [2] sage: s = S(1/2) sage: r = 5 sage: s*r LocalElt(5/2) sage: r*s LocalElt(25/2) So it seems that (with R the base of S, r in R and s in S), s*r returns the value of s._lmul_(r) and r*s returns the value of s._rmul_(r). best, Niles [1] -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
[sage-support] Re: show()ing 3-tuples of matrices as images?
Very nice, thanks for sharing that! -Marshall On Dec 12, 9:26 pm, Dan Drake wrote: > On Fri, 10 Dec 2010 at 10:09AM -0800, jvkersch wrote: > > On Dec 9, 9:57 pm, Dan Drake wrote: > > > *facepalm* That was stupid -- matrix_plot() already accepts numpy arrays > > > of shape (x,y,3) and plots them as a color image exactly the way I want. > > > No need to mess around with pylab.imshow(). > > > > Sorry for the noise. > > > Actually, your message gave me some good ideas of how to visualize the > > SVD decomposition in my linear algebra class, so not noise at all :) > > Here's a published version:https://sagenb.kaist.ac.kr:8066/home/pub/23 > > Enjoy. > > Dan > > -- > --- Dan Drake > - http://mathsci.kaist.ac.kr/~drake > --- > > signature.asc > < 1KViewDownload -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
Re: [sage-support] Re: New Magma Calculator Interface - magma_free() needs update
And is this (see attatched version) is correct now?
Example 1:
> magma_free('P := PolynomialRing(IntegerRing());\nFactorization(x^8
- 1);')
Result is:
[
,
,
,
]
Example 2:
> magma_free("Factorization(9290348092384)")
Result is:
[ <2, 5>, <290323377887, 1>
12.12.2010 18:40, Ugur пишет:
> Hey thanks for the new code. But unfortunately, if I understood
> correctly, the new code just takes the last line of the output :
> ( E.g., compare results of magma_free('[[a,b,c]:a,b,c in [1..20] |
> a^2+b^2 eq c^2 and a le b];') both in Sage and in Magma-Calc. There
> might be another problem, but for the time being, I can report this
> problem.
>
> On Dec 12, 3:10 am, "Alexey U. Gudchenko" wrote:
>> 12.12.2010 02:31, Ugur пишет:
>>
>>> As the layout of Magma's website have changed, the code for
>>> magma_free() should be updated. Just want to bring to your attention.
>>
>> I have edit file according new redesign of Magma's website
>>
>> Sage-4.6.3/local/lib/python2.6/site-packages/sage/interfaces/magma_free.py
>>
>> In atachment there is result.
>>
>> It work for example as in documentation:
>>
>>> print magma_free("Factorization(9290348092384)")
>>
>> [ <2, 5>, <290323377887, 1> ]
>>
>> I don't understand Magma and can't know more difucult examples, so it
>> must be verified !!!
>>
>> magma_free.py
>> 3KViewDownload
>
--
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to
sage-support+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org
#*
# Copyright (C) 2007 William Stein
#
# Distributed under the terms of the GNU General Public License (GPL)
#
#This code is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
#General Public License for more details.
#
# The full text of the GPL is available at:
#
# http://www.gnu.org/licenses/
#*
class MagmaExpr(str):
def __repr__(self):
return str(self)
def magma_free_eval(code, strip=True, columns=0):
"""
Use the free online MAGMA calculator to evaluate the given
input code and return the answer as a string.
LIMITATIONS: The code must evaluate in at most 20 seconds
and there is a limitation on the amount of RAM.
EXAMPLES:
sage: magma_free("Factorization(9290348092384)") # optional - internet
[ <2, 5>, <290323377887, 1> ]
"""
import urllib, httplib
server = "magma.maths.usyd.edu.au"
processPath = "/calc/process.xml"
refererPath = "/calc/"
refererUrl = "http://%s%s"; % ( server, refererPath)
code = "SetColumns(%s);\n"%columns + code
params = urllib.urlencode({'input':code})
headers = {"Content-type": "application/x-www-form-urlencoded", "Accept":"Accept: text/html, application/xml, application/xhtml+xml", "Referer": refererUrl}
conn = httplib.HTTPConnection(server)
conn.request("POST", processPath, params, headers)
response = conn.getresponse()
results = response.read()
conn.close()
# Result is in form:
#
#
#
# 60
# 341657781
# 2.17-1
# 0.320
# 9.53MB
#
#
#[ <2, 5>, <290323377887, 1> ]
#
#
# "Factorization(9290348092384)"
# results = """603416577812.17-10.3209.53MB[ <2, 5>, <290323377887, 1> ]"""
# "P := PolynomialRing(IntegerRing());\nFactorization(x^8 - 1);"
# results = """6037691963792.17-10.2709.53MB[,,,]"""
from xml.dom.minidom import parseString
xmlDoc = parseString(results)
res = u""
# oHeaders = xmlDoc.getElementsByTagName('headers') # for version and timing
reslutsNodeList = xmlDoc.getElementsByTagName('results')
if len(reslutsNodeList) > 0:
reslutsNode = reslutsNodeList[0]
lines = reslutsNode.getElementsByTagName('line')
if len(reslutsNodeList) > 0:
for line in lines:
textNode = line.childNodes[0]
res += textNode.data + "\n"
class MagmaExpr(str):
def __repr__(self):
return str(self)
return MagmaExpr(res)
class MagmaFree:
"""
Evaluate MAGMA code without requiring that MAGMA be installed
on your computer by using the free online MAGMA calculator.
EXAMPLES:
sage: magma_free("Factorization(9290348092384)") # optional - internet
[ <2, 5>, <290323377887, 1> ]
"""
def eval(self, x, **kwds):
return magma_free_eval(x)
def __call__(self, code, strip=True, columns=0):
return magma_free_eval(code, st
[sage-support] Re: Having trouble getting *ultra* high precision in this infinite sum calculation...
Hi Chris, disclaimer: I am no expert in numerics. On 13 Dez., 07:34, Chris Seberino wrote: > Why isn't the error improving as I increase the number of terms that > are summed? Am I doing something wrong in Sage? (Yes it is possible > that this infinite sum converges unimaginably slowly so I wanted to > check first I wasn't doing something dumb.) I think you use a precision that is too small The summands are of course very small. So, comparing the two results in a field with 53 digits precision may be pointless: sage: sum(10^(-k^2/1.0) for k in range(-2,2)) == sum(10^(-k^2/1.0) for k in range(-1,1)) True Note that the denominator "1.0" in your exponent belongs to RR, which by default has 53 digits precision. Let us raise it to 6000: sage: d = RealField(6000)(1) sage: d.precision() 6000 Unfortunately, the sums are now taking a very long time to compute. But we are only interested in their difference. So, it suffices to do (still taking about one minute): sage: 2*sum(10^(-k^2/d) for k in range(1,2)) 2.02019722722490674759723772962542922944721452394745083...e-1 So there is a small progress in the summation! But I have no idea whether at the end of the day the small progress will be enough to cover the big difference -1.27897692436818e-13 to your theoretical result. Cheers, Simon -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
