[Tutor] print to file probelm

[John Collins]

Hi,
I'm a baffled beginner. The script below is one of a suite of scripts 
written by Simon Tatham a decade ago;

http://www.chiark.greenend.org.uk/~sgtatham/polyhedra/
http://www.chiark.greenend.org.uk/~sgtatham/polyhedra/polyhedra.tar.gz

OS: WinXP
Py Ver: 2.7
Script: canvas.py

It reads from a file name in the command line and should print to a file 
name also specified in the command line. It inputs and runs fine but 
outputs to the command prompt *screen* while creating and *empty* output 
file of the name specified? I cannot figure out why?


[the dashed lines below are not in the script(s)]
---
#!/usr/bin/env python

# Read in a polyhedron description, and output a JavaScript list
# suitable for use in the "data" field of a canvas used by
# canvaspoly.js.

import sys
import os
import string
import random
from math import pi, asin, atan2, cos, sin, sqrt
from crosspoint import crosspoint

args = sys.argv[1:]

if len(args) > 0:
infile = open(args[0], "r")
args = args[1:]
else:
infile = sys.stdin

if len(args) > 0:
outfile = open(args[0], "w")
args = args[1:]
else:
outfile = sys.stdout

vertices = {}
faces = {}
normals = {}

lineno = 0
while 1:
s = infile.readline()
if s == "": break
sl = string.split(s)
lineno = lineno + 1
if sl[0] == "point" and len(sl) == 5:
vertices[sl[1]] = \
(string.atof(sl[2]), string.atof(sl[3]), string.atof(sl[4]))
elif sl[0] == "face" and len(sl) == 3:
if not vertices.has_key(sl[2]):
sys.stderr.write("line %d: vertex %s not defined\n" % \
(lineno, sl[2]))
else:
if not faces.has_key(sl[1]):
faces[sl[1]] = []
faces[sl[1]].append(sl[2])
elif sl[0] == "normal" and len(sl) == 5:
if not faces.has_key(sl[1]):
sys.stderr.write("line %d: face %s not defined\n" % \
(lineno, sl[1]))
else:
normals[sl[1]] = \
(string.atof(sl[2]), string.atof(sl[3]), string.atof(sl[4]))
else:
sys.stderr.write("line %d: unrecognised line format\n" % lineno)
continue
infile.close()

# Normalise the radius of our polyhedron so that it just fits
# inside the unit sphere.
maxlen = 0
for v in vertices.values():
vlen = sqrt(v[0]**2 + v[1]**2 + v[2]**2)
if maxlen < vlen: maxlen = vlen
for v in vertices.keys():
vv = vertices[v]
vertices[v] = (vv[0]/maxlen, vv[1]/maxlen, vv[2]/maxlen)

# Assign integer indices to vertices and faces.
vindex = {}
findex = {}
vlist = []
flist = []
for v in vertices.keys():
vindex[v] = len(vlist)
vlist.append(v)
for f in faces.keys():
findex[f] = len(flist)
flist.append(f)

s = "[%d" % len(vertices)
for i in range(len(vertices)):
v = vertices[vlist[i]]
s = s + ",%.17g,%.17g,%.17g" % (v[0], v[1], v[2])
s = s + ",%d" % len(faces)
for i in range(len(faces)):
f = faces[flist[i]]
n = normals[flist[i]]
s = s + ",%d" % len(f)
for v in f:
s = s + ",%d" % vindex[v]
s = s + ",%.17g,%.17g,%.17g" % (n[0], n[1], n[2])
s = s + "]"
print s
--

The other scripts run and output just fine. They do have some extra 
script of varying parameters that seem to be about reassigning the print 
command, possible with formatting of output in mind? Here are a those 
sections from two of the other scripts:


From mkpoints.py

def realprint(a):
for i in range(len(a)):
outfile.write(str(a[i]))
if i < len(a)-1:
outfile.write(" ")
else:
outfile.write("\n")

def pprint(*a):
realprint(a)
--
the final output lines are
--
# Output the points.
for x, y, z in points:
pprint(x, y, z)
--

From drawpoly.py
--
def realprint(a):
for i in range(len(a)):
outfile.write(str(a[i]))
if i < len(a)-1:
outfile.write(" ")
else:
outfile.write("\n")

def psprint(*a):
realprint(a)
--
the last two output lines are
--
psprint("showpage grestore")
psprint("%%EOF")
--

For the problem script, canvas.py, the output is a long single line 
beginning with a "[", containing a mixture of integers and signed real 
numbers separated only by a commas, and ending in a "]".


Any help to begin my understanding of print (re)assignments, and, fixing 
this script would be MOST welcome, thanks to you all!


Best Regards,
John. [Total newbie, time since first Python DL, <24hrs! Still use
   GWBasic!!! ... Really need to learn Python!]
_

[Tutor] greater precision?

[John Collins]

Hi,
OS: XP
Py: 2.7.2

I am running some old scripts, not written by me, that produce
substantial calculated values data as decimals, 12 significant
figures. AFAIK, the keys calls are;

from math import pi, asin, atan2, cos, sin, sqrt

from math import pi, asin, atan2, cos, sin, sqrt
from crosspoint import crosspoint

which are from the 1st and 2nd scripts, that are run to generate,
then manipulate, the numbers (actually, polygon descriptions!).
However, the 2nd script 'calls' a script called crosspoint.py,
trimmed of most comments this is;

# Python code to find the crossing point of two lines.
# This function is optimised for big-integer or FP arithmetic: it
# multiplies up to find two big numbers, and then divides them.

def crosspoint(xa1,ya1,xa2,ya2,xb1,yb1,xb2,yb2):
"Give the intersection point of the (possibly extrapolated) lines\n"\
"segments (xa1,ya1)-(xa2,ya2) and (xb1,yb1)-(xb2,yb2)."
dxa = xa2-xa1
dya = ya2-ya1
dxb = xb2-xb1
dyb = yb2-yb1
if dya * dxb == dxa * dyb:
return None
if dxa == 0:
return (xa1, (xa1 - xb1) * dyb / dxb + yb1)
if dxb == 0:
return (xb1, (xb1 - xa1) * dya / dxa + ya1)
if dya == 0:
return ((ya1 - yb1) * dxb / dyb + xb1, ya1)
if dyb == 0:
return ((yb1 - ya1) * dxa / dya + xa1, yb1)

det = dya * dxb - dyb * dxa
xtop = dxb * dxa * (yb1-ya1) + dya * dxb * xa1 - dyb * dxa * xb1
ytop = dya * dyb * (xa1-xb1) + dxb * dya * yb1 - dxa * dyb * ya1

return (xtop / det, ytop / det)


I am not sure what == means, nor if any 'special' maths functions are
called from crosspoint.py (to me, it appears not?), so, as I understand 
it, the


from math import

line *is* the 'math engine' if you will, and is the source of the 12
sig fig limit, yes?

One other odd thing that occurs, is when the scripts are run, a weird,
small, non ASCII file called crosspoint.pyc is created? Is this the
interpreter 'compiling' crosspoint.py ( either before, during, or
after?) the 2nd script calls it?

Sorry to bother, but if I can squeeze out *at least* 15 sig figs, (30
or more would be better!) I'd be a happy camper!
XNumbers addon for Excel allows over 200 sig figs by switching to base
256 IIRC. It is this with which I'd like to examine the output of these
pyto scripts at finer resolution, if that can be done in python???

Best Regards,
John Collins.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

[Tutor] greater precision?

[John Collins]

Hi,
OS: XP
Py: 2.7.2

I am running some old scripts, not written by me, that produce
substantial calculated values data as decimals, 12 significant
figures. AFAIK, the keys calls are;

from math import pi, asin, atan2, cos, sin, sqrt

from math import pi, asin, atan2, cos, sin, sqrt
from crosspoint import crosspoint

which are from the 1st and 2nd scripts, that are run to generate,
then manipulate, the numbers (actually, polygon descriptions!).
However, the 2nd script 'calls' a script called crosspoint.py,
trimmed of most comments this is;

# Python code to find the crossing point of two lines.
# This function is optimised for big-integer or FP arithmetic: it
# multiplies up to find two big numbers, and then divides them.

def crosspoint(xa1,ya1,xa2,ya2,xb1,yb1,xb2,yb2):
"Give the intersection point of the (possibly extrapolated) lines\n"\
"segments (xa1,ya1)-(xa2,ya2) and (xb1,yb1)-(xb2,yb2)."
dxa = xa2-xa1
dya = ya2-ya1
dxb = xb2-xb1
dyb = yb2-yb1
if dya * dxb == dxa * dyb:
return None
if dxa == 0:
return (xa1, (xa1 - xb1) * dyb / dxb + yb1)
if dxb == 0:
return (xb1, (xb1 - xa1) * dya / dxa + ya1)
if dya == 0:
return ((ya1 - yb1) * dxb / dyb + xb1, ya1)
if dyb == 0:
return ((yb1 - ya1) * dxa / dya + xa1, yb1)

det = dya * dxb - dyb * dxa
xtop = dxb * dxa * (yb1-ya1) + dya * dxb * xa1 - dyb * dxa * xb1
ytop = dya * dyb * (xa1-xb1) + dxb * dya * yb1 - dxa * dyb * ya1

return (xtop / det, ytop / det)


I am not sure what == means, nor if any 'special' maths functions are
called from crosspoint.py (to me, it appears not?), so, as I understand 
it, the


from math import

line *is* the 'math engine' if you will, and is the source of the 12
sig fig limit, yes?

One other odd thing that occurs, is when the scripts are run, a weird,
small, non ASCII file called crosspoint.pyc is created? Is this the
interpreter 'compiling' crosspoint.py ( either before, during, or
after?) the 2nd script calls it?

Sorry to bother, but if I can squeeze out *at least* 15 sig figs, (30
or more would be better!) I'd be a happy camper!
XNumbers addon for Excel allows over 200 sig figs by switching to base
256 IIRC. It is this with which I'd like to examine the output of these
pyto scripts at finer resolution, if that can be done in python???

Best Regards,
John Collins.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] greater precision?

[John Collins]

Hi Dave

Did you really leave two very-similar messages 3 minutes apart?  Or are
you using a broken gateway, like Google-groups, and it hiccoughed?

Sorry, I didn't intend to - flunky LH mouse microswitch!


Without knowing the type of the arguments being passed to the
crosspoint() function, we cannot say.  I can GUESS that they are int,
long, or float.  But you can find that out by examining the source
that's calling it.  Judging from the comments, I might guess they're int
or long, and if so, only the division being done in the function
produces floats.  If that's the case, then you're limited to float's
precision.  if they are some other type (eg. Decimal), then indeed there
might be special functions being called.


Well, the two scripts are only about an email page long each, shall
I post them?


That import gets you access to the particular symbols it imports.
Normal arithmetic on floats is already built in, and doesn't need an import.

Right! Thanks.

I'm assuming you're using CPython, and you say it's on XP.  So
presumably you're running an Intel (or Intel-compatible) processor with
binary floating point built-in.  That processor is the limit of float
values in normal use.  It's good to about 18 digits.

Sure, 32 bit uproc, intrinsic binary limit.

Exactly.  It's a side-effect of the first import of the module.  On
subsequent imports, the pyc file is used, unless the py file has been
modified meanwhile.

Ah! Thanks!

18 digits is what you should get if the code is as I describe.  But if
there are lots of fp operations you're not showing, then an error can
gradually get larger.  And with any finite precision, you have the risk
from things such as subtracting two nearly-equal values, which will
reduce the final precision.

AFAIK, it's all FP. inputs are integers, outputs range from
-2. to 2.

If you need more than 18, then go to the Decimal module, which lets you
set the precision to arbitrary levels.  You will see a substantial
slowdown, of course, if you set the precision very high.  if that
becomes a problem, consider CPython 3.3, which has optimized that
module.  But try not to change too many things at once, as there are
lots of changes between 2.7 and 3.3.

I think I'll need to from what you have said / pointed out - ie, for
in excess of 'machine' precision, one needs to change base 10 floats
to a higher base, do foo, then come back. Sounds daunting!

John.

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] greater precision?

[John Collins]

Hi Steve,
Thanks. From
>>>mkpoints.py 32 32.txt

here's a sample of the output

-0.396087591388 -0.781284022758 0.482400140683
-0.967387012461 -0.0838047084421 -0.239037944614
0.0208969821213 -0.489420208746 0.871797668848
0.887250003871 -0.258893773768 -0.38178717178
0.426352071227 -0.457758408728 -0.780180203927
0.612061168992 -0.280383142359 0.739436555016
-0.887250003871 0.258893773768 0.38178717178
-0.0971745158475 -0.994342015264 -0.0429076933695
-0.120898756509 -0.759794654167 -0.638823586113
-0.0208969821213 0.489420208746 -0.871797668848
0.482396765336 -0.834880934468 -0.265079584379
0.66383194755 0.726669941038 0.176855710123


from
>>>nfaces.py 32.txt 32fa.txt

here's a sample of the output

point vertex_0_2_12 -0.0288974102653 -0.851924110364 0.66948446135
point vertex_13_24_27 -0.122445373457 1.00045419254 0.398644871129
point vertex_0_7_15 -0.482610585141 -0.963539328269 0.1161816686
point vertex_3_10_17 0.848541556491 -0.639691741968 -0.213520247975
point vertex_1_6_14 -1.05498774772 0.248634080415 -0.00106786881656
point vertex_13_24_31 -0.291794484064 0.826881428947 0.637135994637
point vertex_1_6_25 -1.07023716261 -0.0479998647263 0.164643927545
point vertex_3_17_28 1.05498774772 -0.248634080415 0.00106786881656
point vertex_1_15_25 -0.975134617659 -0.4675255693 -0.073154040374
point vertex_4_8_10 0.291794484064 -0.826881428947 -0.637135994637
point vertex_9_19_20 -0.400242088946 0.638705226984 -0.778897359983
normal face_30 -0.617395768043 -0.35935879 -0.699844161834
face face_31 vertex_21_29_31
face face_31 vertex_13_21_31
face face_31 vertex_13_24_31
face face_31 vertex_6_24_31
face face_31 vertex_6_29_31
normal face_31 -0.426352071227 0.457758408728 0.780180203927


As you can see, there are exactly 12 significant figures.

BTW, I did not write either script, I can post them, if you think
doing so may show where it may be possible to escape to "decimal"
as you say, perhaps?


"Decimal" has a specific meaning in Python different to how you
appear to be using it. It looks to me like you are working with
floats rather than decimals.

Right.

from math import pi, asin, atan2, cos, sin, sqrt
from math import pi, asin, atan2, cos, sin, sqrt

Two different scripts.

"crosspoint" appears to be a custom Python program that we know
nothing about, apart from what you tell us.

I posted it in it's entirety.

"==" is used for equality testing:
x == 2
returns False, because x does not equal 2; but
x == 1
returns True, because x does currently equal 1.

Ah! Thanks!

Almost. The "from math import blah..." line extracts a bunch of maths
functions from the math library and makes them available to your
program.

I'm seeing this now. Python does minimal things, extras are called in
only as needed.

The number of significant figures is more fundamental that that; your
operating system understands about floating point numbers (so-called
"C doubles") with 53 *binary* significant figures, or about 17 *decimal*
figures. So I'm not sure why you think there are only 12.

Sure. But see the above, from Py 2.7.2, it's precisely 12 sig.figs.!

You need to show us how the output is generated in the first place.

Done, above.

Not a chance without some major changes to your program.

I was afraid of this.

I can't say how major without seeing more of your program.

Well, OK, here's the first, mkpoints.py
#!/usr/bin/env python

# Distribute a set of points randomly across a sphere, allow them
# to mutually repel and find equilibrium.

import sys
import string
import random
from math import pi, asin, atan2, cos, sin, sqrt

args = sys.argv[1:]

if len(args) > 0:
n = string.atoi(sys.argv[1])
args = args[1:]
else:
n = 7

if len(args) > 0:
outfile = open(args[0], "w")
args = args[1:]
else:
outfile = sys.stdout

points = []

def realprint(a):
for i in range(len(a)):
outfile.write(str(a[i]))
if i < len(a)-1:
outfile.write(" ")
else:
outfile.write("\n")

def pprint(*a):
realprint(a)

for i in range(n):
# Invent a randomly distributed point.
#
# To distribute points uniformly over a spherical surface, the
# easiest thing is to invent its location in polar coordinates.
# Obviously theta (longitude) must be chosen uniformly from
# [0,2*pi]; phi (latitude) must be chosen in such a way that
# the probability of falling within any given band of latitudes
# must be proportional to the total surface area within that
# band. In other words, the probability _density_ function at
# any value of phi must be proportional to the circumference of
# the circle around the sphere at that latitude. This in turn
# is proportional to the radius out from the sphere at that
# latitude, i.e. cos(phi). Hence the cumulative probability
# should be proportional to the integral of that, i.e. sin(phi)
# - and since we know the cumulative probability needs to be
# zero at -pi/2 and 1 at +pi/2, this tells us i

Re: [Tutor] greater precision?

[John Collins]

Hi Peter,
Thanks.

[On modern hardware] Python uses IEEE 754 double-precision
 internally which gives 15 to
17 digits. But of course errors may accumulate.

As in my previous, this script seems to output precisely 12 significant
not 15 and not 17. ??? 15 and I'd be happier right now, as it matches
Excel's precision there, 'as it is'.

Equality.

Right, in a 1,0 sense.

Because of rounding errors this is a dangerous operation for floating point
numbers:

print 1.0 == .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1

False

I take it that is because binary for .1 is a repeating sequence, yes?

It is a toolbox rather than an engine.

Ah ha! *Now* I'm getting it!

math is basically a wrapper around the C library, and these functions all
use C's double and [most of the time] your hardware's floating point unit.

Right!

Yes, Python compiles the source to bytecode before it executes it, and for
all modules except the main script this bytecode is cached in a .pyc file.

That nails it (as I was wondering, just now, why the primary scripts
remained intact).

As you correctly observed crospoints() uses only +-*/ and ==, so you can
feed it every type that supports these operations (this is called "duck
typing"). For example:



from fractions import Fraction
from crosspoint import crosspoint
crosspoint(Fraction(0, 1), Fraction(1, 3), Fraction(1, 1), Fraction(1,

3), Fraction(5, 7), Fraction(0, 1), Fraction(5, 7), Fraction(1, 1))
(Fraction(5, 7), Fraction(1, 3))

p = crosspoint(Fraction(0, 1), Fraction(1, 3), Fraction(1, 1),

Fraction(1, 3), Fraction(5, 7), Fraction(0, 1), Fraction(5, 7), Fraction(1,
1))

print "%s, %s" % p

5/7, 1/3

Yay, infinite precision ;)

You just lost me.

Of more practical relevance may be something like gmpy


I've just had a peek. Looks like what I need. Haven't a clue if I'll
understand how to 'patch it in' to the scripts. Doco read time!
John.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] greater precision?

[John Collins]

Hi Dave,
Thanks, more insights!

I was only concerned that there was some correction in one of the
messages.  And since there was only 3 minutes between them, i didn't
know which might be the corrected one.  They showed up here out of
order.  I responded to the one with the later timestamp.

No, mia culpa.

Just post one of them.  Otherwise, things can get very confusing.

Done.

Actually, it's 64 bits.  32 bit fp wouldn't get you anywhere near 18 digits.

Darn, of course, you're right! Senior moment for me!

Since the inputs to that function are ints, then the output will be IEEE
floats.  that also means that the == comparisons in the crosspoint()
function are precise.

THAT is a very valuable insight Dave, thanks!

Actually, the base change is already happening.  Using Decimal would
probably reduce the number of base changes.  And if you create the
numbers as Decimal objects, then they'll propagate through the
crosspoint() function correctly.However, even though the decimal
module supports log and sqrt, I don't know how to do trig with it.

Well, as trig is *core essential* to polyhedra maths, I *have* to
use *lots* of it!

Incidentally, I didn't suggest the fractions module, since you're
presumably going to be doing trig on the results, so I don't see the
benefit.

Yes. Core maths is +,-,*,/,sin,cos,tan (and their inverses), sqrt,
^2,^3, (ie, exponentials), etc off hand.

BTW, I misspoke earlier.  The module name is decimal.  The class name
within that module is Decimal.

A minor thing to me, a non programmer, but I do understand that being
very precise is very important to programmers, so thank you!
John.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] greater precision?

[John Collins]

Hi Dave,

Not true.  That's just what it was truncated to upon output.  If you
want to show 15 digits, then use formatted output instead of str()
inside the realprint() function.

BIG light bulb moment! I had no idea the str() statement was truncating!
I *did* search the script for "12" or "trunc" (being a newbie!) and saw
nothing. Hence my silly questions tonight!



def realprint(a):
 for i in range(len(a)):
 outfile.write(str(a[i]))
 if i < len(a)-1:
 outfile.write(" ")
 else:
 outfile.write("\n")



output.write("{0:.15f}".format(x))

You may want to play with the format a bit to get it the way you
actually want it.  Note that the format will happily output nonsense
digits beyond the end of the available precision, so you have to do your
own figuring before deciding what to display.

Hmm, well, I did modify the original script by setting the convergence
test value to 2.005e-16 up from 1e-6, s, I 'guess' 15 sig.figs.
will be OK. I'll have a go! That's 3 orders of magnitude better for
a few key strokes! Great! (maybe...)
John.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] greater precision?

[John Collins]

Hi Dave,

You just lost me.


If you don't use any transcendental functions, then a fraction has no
quantization error.  It's totally precise.


Ah ha! Another light bulb moment - two in one night! Thank you Dave,
and all!

John.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] greater precision?

[John Collins]

Hi Dave,

Not silly at all.  I didn't realize str(float) would truncate to 12
digits either.  I found out by experimenting (with 2.7) in the interpreter.

Very gracious of you to say, and generous of you to trouble yourself
to experiment - thank you very much!

Note that it may differ from version to version.  And that's another
reason to use format.

Excellent point!

But please don't just take the format string I supplied as "right."  It
is if you always want 15 decimal digits to the right of the decimal
point.  But if you have a number like 50 thousand, then many of those
digits to the right are invalid.
Indeed! As you saw, some outputs are, and really must be output as 
integers. A  1 with a decimal point followed by 15 0's would make a real 
mess of the face/vertex designation table. So I have to be careful where 
I invoke

output.write("{0:.15f}".format(x))
or similar, ie, that it operates only on the values I'd like output
that way.
Which raises a question. Is the command 'persistent'? In other words,
if I use it early on, but then wish to output integers, has it 'died
after use', do I need to 'kill it after use', or will python just
default back to what it sees next? I know this sounds silly, but to me
the command 'looks' like it's setting a 'hidden pyton variable' to
"15f" which may need to be explicitly revoked, or not,...???
John.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] greater precision?

[John Collins]

Hi Dave,

Valid question.  However, there are no hidden variables used in format.
Each time you invoke the format method (it's a method of str), it starts
from scratch using only its current arguments.  i can't think of any
sense in which 'default' fits here, either.

Thanks, that's somewhat of a relief. In nfaces.py which outputs like
this

point vertex_11_22_27 0.482610585141 0.963539328269 -0.1161816686
point vertex_11_18_28 0.894075981233 0.461195737945 0.403417680839
face face_0 vertex_0_2_29
face face_0 vertex_0_25_29
face face_0 vertex_0_15_25
face face_0 vertex_0_7_15
face face_0 vertex_0_7_12
face face_0 vertex_0_2_12
normal face_0 -0.396087591388 -0.781284022758 0.482400140683
face face_1 vertex_1_15_30

there are nested outfile.write commands with logical tests! Best now
I try your suggestions - experiment, I can't break it(!), and if after a 
sleepless night, it's all pea soup, I'll log back in with this 
marvellous group of very knowledgeable and helpful folks!

You do really need to study the format spec, to see what other
parameters may be more useful.  What I supplied is great if all the
digits are to the right of the decimal.

Agreed.

Note, you can also use format on integers, in order to make a fixed
number of columns, for example.  Or to get leading zeroes.  Or whatever.

Interesting...

And realize that the format does not have to be "inside" the write.  So
you can format to a string, then post-process in some way, before
sending to the write method.

Very interesting!

Incidentally, One of numpy or gmpy is probably a very good idea for
you.  But as I have no experience with either, it just didn't occur to
me.  So I'm glad Peter mentioned one of them.  The only catch I know of
is it's an external dependency, meaning you have to download and install
it into the Python search path.

Yes! A while back, Ramit mentioned;
"P.S. If you want large amount of accuracy with number crunching, you
 may want to look into using fixed-precision or binary math libraries.
 Try looking at scipy/numpy or using Decimal instead of floating-point
 numbers. (This is just a suggestion and may be incorrect because I
 have not yet needed such accuracy. )"

Which I just searched for and dug up!

Right, I'm off to bash this script like a beginner, and see what
emerges! :) Thanks for so many insights in one night - terrific!
Wish I'd picked this language up *years* ago - it's so foreign to
me now, yet so beautifully useful!

Cheers, John.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] greater precision?

[John Collins]

Hello,
Just checked my py, and 15 was the report! Wish I had known
that factoid - thank you, for a very complete coverage of
the broader intrinsic 'machine' + system precision - it actually
makes sense  to me now - it's a calculation!

On 30/10/2012 2:02 AM, eryksun wrote:


A double has 53 bits of precisions, which is 53*log10(2) =~ 15.955
decimal digits. However, one often sees the numbers 15 and 17 quoted
for the precision. It depends. A double is guaranteed to accurately
store a string with 15 decimal digits (round trip). But each 15-digit
decimal string maps to many doubles:

 >>> from struct import unpack

 >>> format(unpack('d', '\x76\x99\x99\x99\x99\x99\xb9?')[0], '.15f')
 '0.100'
 >>> format(unpack('d', '\xbd\x99\x99\x99\x99\x99\xb9?')[0], '.15f')
 '0.100'

 >>> 0xbd - 0x76 + 1   # doubles that round to 0.100
 72

(Note: my Intel processor is little endian, so the least significant
byte is index 0 in the packed double, such as '\x76'.)

However, to exactly represent each double requires 17 decimal digits:

 >>> format(unpack('d', '\x76\x99\x99\x99\x99\x99\xb9?')[0], '.17f')
 '0.09951'
 >>> format(unpack('d', '\x77\x99\x99\x99\x99\x99\xb9?')[0], '.17f')
 '0.09952'

Python says the precision is 15 decimal digits:

 >>> import sys
 >>> sys.float_info.mant_dig   # bits of precision
 53
 >>> sys.float_info.dig# decimal digits
 15


Regs, John.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] greater precision?

[John Collins]

Thanks Mark. I 'stuck' with 2.7.2 for these old scripts,
unless I want to totally rewrite them. They are so elegant,
this would realy amount to starting from scratch. I get 15
reported, and that's going to be sufficient for these 'as
they are'. For more, it's a go back to year zero exercise
I feel.
John.
On 30/10/2012 2:15 AM, Mark Lawrence wrote:


It's 16 digits with 3.3.0.


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] greater precision?

[John Collins]

Hi Mark,
Thanks. I wouldn't know C if I fell over it. Until recently,
the *only* language I'd ever used was (HP, GW)BASIC aside
from Fortran 101, 3 decades ago!
John.

On 30/10/2012 2:45 AM, Mark Lawrence wrote:


If you're more comfortable with C you can use printf style formatting
see http://docs.python.org/2/library/stdtypes.html#string-formatting


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Two Scripts, Same Commands, One Works, One Doesn't

[John Collins]

Probably not applicable, but before deleting the original post, I 
distinctly remember seeing in amongst the text of the post, ".pfd"

as part of a larger string of text, and as distinct from ".pdf". I
wondered then if the OP's problem might be a typographical error?
I am a student not a tutor - this is wild speculation!
Best Regards,
John Collins.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor