[Tutor] greater precision?

[Dave Angel]

On 10/29/2012 06:32 AM, John Collins wrote:
> 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!
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.

>
>> <SNIP>
> Well, the two scripts are only about an email page long each, shall
> I post them?
>
Just post one of them.  Otherwise, things can get very confusing.
>> I'm assuming you're using CPython, and you say it's on
>>> 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!
>> 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.

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

>> <SNIP>
>
> AFAIK, it's all FP. inputs are integers, outputs range from
> -2.000000000000 to 2.000000000000

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.

>> 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!

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.

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.

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


-- 

DaveA