2008/12/29 John Cremona <john.crem...@gmail.com>: > There really are two different issues here. The one which William and > Michael concentrate on is that adding .n(100) to a 53-bit complex > number does not increase its precision in any meaningful sense, it > just pads with 47 bits of 0. > > But the second point is to do with Georg's original observation that > sage: type(CC(1/3 + 0.0*I)) > <type 'sage.rings.complex_number.ComplexNumber'> > sage: type(CC(1/3 + 0.0*I).n(100)) > <type 'sage.rings.real_mpfr.RealNumber'> > > or perhaps more clearly, > sage: z = CC(1/3 + 0.0*I) > sage: type(z) > <type 'sage.rings.complex_number.ComplexNumber'> > sage: type(z.n(10)) > <type 'sage.rings.real_mpfr.RealNumber'> > > so that the return type of .n() is real.
Looking at the code for numerical_approx() in sage.misc.functional, this happens because the attempt to coerce z into RealField(10) succeeds. To fix this (if it is agreed that it is a bug) that function would need to test the type of the input and return something of the same type (real/complex). John > > John Cremona > > 2008/12/29 mabshoff <michael.absh...@mathematik.uni-dortmund.de>: >> >> >> >> On Dec 29, 8:55 am, ggrafendorfer <georg.grafendor...@gmail.com> >> wrote: >> >> Hi Georg, >> >>> > You should do it the right way instead of the wrong way. It is a very >>> > bad idea to do stuff like "ln(CC(-5).n(prec=100))", which basically >>> > says "take -5, think of it as a complex number with 53 bits of >>> > precision, take the log, then view the answer as magically having 100 >>> > bits of precision by basically randomly making up the missing 47 >>> > bits". >>> >>> Dear William, >>> With "ln(CC(-5).n(prec=100))" I'm not taking the log of a number with >>> 53-bit precision hoping that it magically turns into a 100-bit >>> precision number, what you mean would be "ln(CC(-5)).n(prec=100)", >>> I'm taking the log of CC(-5).n(prec=100) which obviously should be a >>> 100-bit precision number, >> >> Look at "CC?" - the CC field is 53 bits of precision. If you want more >> looks at ComplexField? >> >>> But the main question actually was if it's a desired behauviour that CC >>> (-5).n(prec=100) is a real number: >>> >>> sage: type(CC(-5).n(prec=100)) >>> <type 'sage.rings.real_mpfr.RealNumber'> >>> >>> increasing precision of a complex number should not change it's type, >>> or? >> >> Well, you are asking for a numerical approximation here of "-5" in the >> complex field. I am not sure this is a bug when the value is returned >> in the "smaller" field. >> >>> Georg >> >> I am not 100% sure we are actually trying to solve the same issue: >> This is what you get: >> >> sage: a = CC(1/3).n(prec=200) >> sage: a >> 0.33333333333333300000000000000000000000000000000000000000000 >> >> and the precision is not 200 correct bits, but 53 correct bits and >> zeroes filled in. This is the point William was trying to make AFAIK. >> >> What you might want is this: >> >> sage: b=ComplexField(200) >> sage: b >> Complex Field with 200 bits of precision >> sage: b=1/3;b >> 1/3 >> sage: b.n(prec=200) >> 0.33333333333333333333333333333333333333333333333333333333333 >> >> In the above case you get 200 bits of precision. >> >> Cheers, >> >> Michael >> >> >> > --~--~---------~--~----~------------~-------~--~----~ 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 URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
