[skipping answering the numeric-specific questions since I am no math expert&nbsp; =) ]<br><br><div><span class="gmail_quote">On 6/15/06, <b class="gmail_sendername">Nick Maclaren</b> &lt;<a href="mailto:nmm1@cus.cam.ac.uk">nmm1@cus.cam.ac.uk
</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">As I have posted to comp.lang.python, I am not happy with Python's<br>
numerical robustness - because it basically propagates the 'features'<br>of IEEE 754 and (worse) C99.&nbsp;&nbsp;Yes, it's better, but I would like to<br>make it a LOT better.&nbsp;&nbsp;I already have a more robust version of 2.4.2,<br>but there are some problems, technical and political.&nbsp;&nbsp;I should
<br>appreciate advice.<br><br>1) Should I start off by developing a testing version, to give people<br>a chance to scream at me, or write a PEP?&nbsp;&nbsp;Because I am no Python<br>development expert, the former would help to educate me into its
<br>conventions, technical and political.</blockquote><div><br>I would do both.&nbsp; It is a lot easier to get something accepted when you have working code.&nbsp; But a PEP to vent possible arguments against the change along with any backwards-compatibility issues will be needed for something as major as changing how math works.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2) Because some people are dearly attached to the current behaviour,<br>warts and all, and there is a genuine quandary of whether the 'right'
<br>behaviour is trap-and-diagnose, propagate-NaN or whatever-IEEE-754R-<br>finally-specifies (let's ignore C99 and Java as beyond redemption),<br>there might well need to be options.&nbsp;&nbsp;These can obviously be done by<br>a command-line option, an environment variable or a float method.
<br>There are reasons to disfavour the last, but all are possible.&nbsp;&nbsp;Which<br>is the most Pythonesque approach?<br><br>3) I am rather puzzled by the source control mechanism.&nbsp;&nbsp;Are commit<br>privileges needed to start a project like this in the main tree?
<br>Note that I am thinking of starting a test subtree only.</blockquote><div><br>To work directly in Python's repository, yes, checkin privileges are needed.&nbsp; In order to get these, though, you usually either need to have been involved in python-dev for a while and be known to the group or have someone everyone trusts to watch over you as you do your work in a branch.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">4) Is there a Python hacking document?&nbsp;&nbsp;Specifically, if I want to<br>add a new method to a built-in type, is there any guide on where to
<br>start?</blockquote><div><br>The C API docs are at <a href="http://docs.python.org/">http://docs.python.org/</a> and there are some docs at <a href="http://www.python.org/dev/">http://www.python.org/dev/</a> in terms of intro to how development for Python tends to take place.
<br></div><br>-Brett<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">5) I am NOT offering to write a full floating-point emulator, though
<br>it would be easy enough and could provide repeatable, robust results.<br>&quot;Easy&quot; does not mean &quot;quick&quot; :-(&nbsp;&nbsp;Maybe when I retire.&nbsp;&nbsp;Incidentally,<br>experience from times of yore is that emulated floating-point would
<br>be fast enough that few, if any, Python users would notice.<br><br><br></blockquote></div>