ng an environment variable has considerable merit from
a sanity point of view, but calling a global function is also possible.
Any ideas?
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
sn't deal with comparisons (which can
be done only in a purely functional programming language).
|> While you're at it, the pickle modules need to be fixed so they
|> support NaN and Inf. ;)
Yup. On my list :-)
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
e it is correct, it is
NEVER a safe thing to do by default.
The reason is that it is correct only when you know for certain that the
sign of zero is meaningful. IEEE 754 gets this wrong by conflating true
zero, sign-unknown zero and positive zero. Inter alia, it means that
you get situations like:
t
|> processor to get equivalent data.
No, it could be done right. The unpickling would need to detect those
values and raise an exception. You have to allow for it even on the
same 'systems' because one Python might have been compiled with hard
underflow and one with soft. You
ro that has had its sign flipped by an
aritfact of the code. For example:
lim(x->0 from above) 0.001*b/(a-1.001*a)
I fully agree that infinity arithmetic is fairly well-defined for
most operations, but it most definitely is not in this case. It should
be reserved for when the operations
known to be a negative one. NaN is the only numerically respectable
result if the sign is not known, or it might be a true zero.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
time may be negative.
Hence, the SAFE approach is to make the inverse of all zeros a NaN.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
Grant Edwards <[EMAIL PROTECTED]> writes:
|> On 2006-06-15, Nick Maclaren <[EMAIL PROTECTED]> wrote:
|>
|> > Hence, the SAFE approach is to make the inverse of all zeros a
|> > NaN.
|>
|> OK. You're right. I
r ignoring 90% of the principles
of IEEE 754.
==>> But the flaws in those are not the point here. I am asking
whether people would positively OBJECT (as the did in C99) to
errors being detected, possibly as an overridable option.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
if Python just let the HW do it's thing when possible.
Including crash and burn?
Seriously. I don't think that you realise just how many layers of
fixup there are on a typical "IEEE 754" system, and how many variations
there are even for a single platform.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
p occurs, shall be a correctly signed
|> (infinity symbol)(6.3)."
|>
|> To me it looks like the spec specifically allows for a case
|> where "no trap occurrs" and the result is Inf.
That is correct. And it is a mandatory case. But it does NOT say what
the softwar
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
the only issue.
Tail recursion removal can often eliminate the memory drain, but the
code has to be written so that will work - and I don't know offhand
whether Python does it.
In compiled "3rd GL" languages, there are a lot of optimisation issues
where iteration will often produce b
t as a gimmicky, obfuscatory and often dogmatic
substitute for iteration! There are algorithms that become almost
incomprehensible without recursion, and I have implemented a recursion
layer in both assembler AND Fortran just to enable me to write them
without going bonkers.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
. Traditional,
clean streaming input can be implemented efficiently and with good
error diagnostics. The unclean C- and POSIX-like streaming input can't
be, or at least only one of the two can be provided at once.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
h
to have done any numeric work using fixed-point hardware.
|> So why not work with int(float * 100) instead? This way you only have
|> to take care of roundoffs etc when dividing.
And multiplying, and calling most mathematical functions.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
Scott David Daniels <[EMAIL PROTECTED]> writes:
|> Nick Maclaren wrote: (of fixed point)
|> > I am (just) old enough to remember when it was used for
|> > numeric work, and to have used it for that myself, but not old enough
|> &
The way that I read it, Python allows only values (and hence types)
to be immutable, and not class members. The nearest approach to the
latter is to use the name hiding conventions.
Is that correct?
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
Robert Kern <[EMAIL PROTECTED]> writes:
|> Nick Maclaren wrote:
|> > The way that I read it, Python allows only values (and hence types)
|> > to be immutable, and not class members. The nearest approach to the
|> > latter is t
it is so ambiguous
as to be almost totally useless - and it is THAT information that needs to
be in the reference manual, but is only in whatsnew2.2.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
like to consider adding the information you perceive to be
|> lacking.
Consider it considered, but I have to start by understanding what is
supposed to happen and what does happen, precisely and in detail.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
def joe (self) :
print "Inside /joe\n"
a = fred()
a.joe()
I get:
Inside pete
Inside joe
Traceback (most recent call last):
File "crap.py", line 14, in
a.joe()
TypeError: 'NoneType' object is not callable
VERY weird - I could understand it if I
oe within fred, I assumed that it referred to getting
joe from fred. That certainly doesn't appear to be the case, and I don't
see how it helps with my original request if not.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
ut
it is compatible with a good many other interpretations, too. Until and
unless you know what it means, you can't extract its meaning from its
words.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
I was using a decorator and defining an attribute directly.
But no matter - it is clear I had completely misunderstood the intent.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
here for a while.
Create a file called '' in your current directory containing
'print "Oh, yeah?\n"' and then import a module that doesn't exist.
Don't include the single quotes.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
"Simon Forman" <[EMAIL PROTECTED]> writes:
|> Nick Maclaren wrote:
|> ...
|> > Create a file called '' in your current directory containing
|> > 'print "Oh, yeah?\n"' and then import a modul
x27;fred'. strace
or equivalent shows up clearly what the bug is.
|> I don't know whether this is worth fixing.
It's definitely worth fixing, but not as a high priority. Invoking a
file spuriously is potentially serious, with very low probability.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
Fredrik Lundh <[EMAIL PROTECTED]> writes:
|> Nick Maclaren wrote:
|>
|> > It's definitely worth fixing, but not as a high priority. Invoking a
|> > file spuriously is potentially serious, with very low probability.
|>
|>
; "" as the second argument to compile:
|>
|> http://pyref.infogami.com/compile
And the reason that it does that is because it is using one of the standard
conventions for naming stdin. Python didn't INVENT that convention, you
know.
The bug isn't in passing an information string "" but in using
that string (which is not meant to represent a real file) to perform a
file search.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
gree, and depend on the system, configuration and program that
is listening on that port.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
t ones), and
excluding the systems that are not based on or largely cloned from
Unix. You should look at the POSIX facilities, but don't rely on
them without checking.
Also think very carefully whether you want to separate by user or
job - the latter is trickier under Unix.
Regards,
Nick Macla
always do.
|> I wasn't talking about FIFOs. Even if I was, they _are_ still subject to
|> regular file permissions (on Linux, at least).
They aren't on most Unices - Linux is not UNIX, you know :-)
I shall not respond further on this.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
ress are worth pursuing. One of the main reasons that
'program proving' has never taken off outside its cabal is that it
uses bizarre notations unlike anything else on earth that can't be
edited in a normal fashion.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
s a Bessel function?;)
Some people use them all the time; there are specific physical problems
where they are fundamental. I have never used them, in 40 years of
wide-ranging experience in the scientific computing arena!
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
t won't
be used until after the class has been created properly. Actually,
it won't be used except to test for class equivalence, but I may
want to extend later.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
r the class is initialised.
|> Alternatively you can play tricks with metaclasses for a similar effect.
Well, I am already doing that, and regretting the fact that Python
doesn't seem to allow a class instantiation to return a new class :-)
What I am trying to do is very simple, but is s
x27; of class (A).
There are several ways of doing this in Python, but I can't find
any that are as transparent to the user as I would really like.
There is method in my madness :-)
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
"Michele Simionato" <[EMAIL PROTECTED]> writes:
|> Nick Maclaren wrote:
|> > It would be much cleaner not to have to fiddle with static
|> > members after the class is initialised.
|>
|> You can hide the fiddling,
Why doesn't the tuple type have an index method? It seems such a
bizarre restriction that there must be some reason for it. Yes,
I know it's a fairly rare requirement.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
ove or add things to tuples is an even
|> bizarrer restriction!
Eh? Why?
My understanding of the difference between a tuple and a list is
PRECISELY that the former is immutable and the latter mutable.
But an index method makes precisely as much sense on an immutable
sequence as it does on a mutabl
have dual properties - and are true duals if you
include the constraint of no duplicate elements.
I remain baffled. I accept the explanations, but what I am now
confused by is the reason for the explanations
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
dum
on Usenet.
The point is that an index method makes sense on ANY data structure that
can be subscripted by an integer value but, for reasons that aren't at
all clear, is not defined for Python tuples. There is no technical or
mathematical reason why it shouldn't be.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
|> Nick Maclaren wrote:
|>
|> > If lists are intended to be homogeneous, then they should be checked
|> > for that, and an exception raised when an attempt is to make them
|>
rom the horse's mouth, will clear
|> things up once and for all...
|>
|> http://www.python.org/search/hypermail/python-1992/0285.html
Wonderful! Thanks. Yes, that does. It makes perfect sense. I did
say that I thought it would be a rarely used feature :-)
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
lace you put the subscription method, clearly. I really
don't see the problem. I can see that it has not been done because
Guido and others felt that it wasn't worth doing, but not that it is
hard to do.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
of entities where
there is no definable concept of equivalence between entities, and
Python has no such entities as far as I know.
Guido's response is fine - we didn't because we didn't think that it
was worth doing. One can dissent, but it makes perfect sense.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
ll.
[ Incidentally, my use was in argument decoding, where the Python layer
holds the arguments as strings, and I need to pass them as an index to C
(so they DO form a respectable tuple even in Guido's sense, being fixed
in number and value and just happening to be homogeneous). ]
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
with that. I consider the difficulty of adding a reliable
immutable attribute in most languages to be a serious piece of
misdesign, but there isn't a huge amount of point unless it is done
properly. Unreliable safety devices are as likely to increase
errors as reduce them, at least in the han
ple. If a heterogeneous list
just happens to have objects that are all similar, does it remain
heterogeneous?
Loose guidelines are very useful, but should almost always come with
the rider "Follow these unless you have good reasons to ignore them,
but do make sure that you understand the rules fir
cantly. Python has chosen
not to do that.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
f course then we would have
|> to define necessary...
It's not necessary :-) Lists, in Python, are no more homogeneous than
tuples in any sense that I have located. As I posted earlier, if
anyone knows of one, please tell me.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
in Python terms, because
|> Python doesn't formally embody the concept. But that
|> doesn't mean the concept isn't real.
Of course the concept is real, but the point is that Python doesn't
embody the concept of homogeneity in lists, formally or informally,
as far as I kno
n analogy between.
Unfortunately, you are confusing the issue, because there are far
more extraneous aspects than relevant ones, and your view of the
similarities requires looking at the issue in a very strange way.
I think that I can see what you mean, but only just.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
greg <[EMAIL PROTECTED]> writes:
|> Nick Maclaren wrote:
|>
|> > Unfortunately, you are confusing the issue, because there are far
|> > more extraneous aspects than relevant ones, and your view of the
|> > similarities req
type the "lists are intended to
be homogenous" people use to implement mutable heterogenous sequences,
or whether they claim that wanting such a feature is heresy :-)
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
you. Just as you can use a string as a list. We
|> don't have to be rigid to appreciate the difference. :)
Nope. That is DEFINITELY wrong. If you write code that abuses a
language construct in a way that is discouraged but just happens to
work, a couple of decades down the line it wi
;t have all the
|> features you want.
Which is tantamount to saying that Python doesn't support mutable
heterogeneous sequences, even though they are not locked out. That
is more than just odd - it is almost unbelievable. They are a very
basic data structure, after all!
Regards,
Nick Mac
3, agent2, agent3, agent4, str4, ...]
See Algol 68 for an example of this.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
ing to the mind of anyone who sees the terms, most
especially if they are familiar with their use in other areas of computing
and mathematics.
But, given that meaning, I now understand your point.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
"Hendrik van Rooyen" <[EMAIL PROTECTED]> writes:
|> "Nick Maclaren" <[EMAIL PROTECTED]> wrote:
|>
|> > Not at all. I didn't say that they came in pairs. Consider:
|> >
|> > [str1, str2, ag
x = (1.234567890125, 1.2345678901255)
print x
print x[0], x[1]
>>> (1.234567890124, 1.2345678901254999)
>>> 1.23456789012 1.23456789013
Is there a rational reason, or is that simply an artifact of the way
that the code has evolved? It is clearly not a bug :-)
Rega
rational and an artifact of the way the code has evolved!
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
Bjoern Schliessmann <[EMAIL PROTECTED]> writes:
|> Nick Maclaren wrote:
|>
|> > Ah! That explains it. I would call that reason intermediate
|> > between rational and an artifact of the way the code has evolved!
|>
|> Whi
In article <[EMAIL PROTECTED]>, Fredrik Lundh <[EMAIL PROTECTED]> writes:
|> Nick Maclaren wrote:
|>
|> > The use of different precisions for the two cases is not, however,
|> > and it is that I was and am referring to.
|>
|> that's by design, of course
olved in a religious
war over - I was merely puzzled as to the odd behaviour, because I have
to teach it, and it is the sort of thing that can confuse naive users.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
ay".
Not at all. "Precision" has been used to indicate the number of digits
after the decimal point for at least 60 years, probably 100; in 40 years
of IT and using dozens of programming languages, I have never seen
"display" used for that purpose.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
uot;, "de f,", "gh), i")
|>
|> would be extremely confusing if the current behaviour was changed. See
|> http://www.python.org/sf/1534769
|> for details.
Well, I wasn't complaining - merely querying.
If this approach is taken, it would be better to document
atter entirely, and will merely
confuse you. I have a course on computer arithmetic, and am just
now writing one on Python numerics, and confused people may contact
me - though I don't guarantee to help.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
2.0) are necessarily within the range
(x,y) in decimal, even for the most respectable values of x and y.
This was a MAJOR "gotcha" in the days before binary became standard,
and will clearly return with decimal.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
tr(some_float) and repr(some_float) and why str(some_tuple) uses the repr()
of
|> its elements.
Precisely. And it also applies to strings, which I had failed to
notice:
>>> print ("1","2")
('1', '2')
>>> print "1", "2"
1 2
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
hat is going on.
Any pointers appreciated, to more-or-less anything.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
many uses of Perl
|> What exactly did you "hear" of several "uses"? Which
|> application? Academia, Business, ...?
Mainly academic research, but that still covers many fields.
However, I am not and never have been a 'pure' academic, and
am as interested in oth
reak
b = c
else :
if c == a :
break
a = c
That works in binary, but in no base above 2 (assuming that I haven't
made a stupid error writing it down). In THAT case, it is easy to fix
for decimal, but there are ways that it can show up that can be quite
tricky to fix.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
ded programs. Yes, I know
that it is a bit Irish for the best way to use a shared memory system
to be to not share memory, but that's how it is.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
ith difficulty). Debugging
and tuning OpenMP and POSIX threads are beyond anyone except the most
extreme experts; I am only on the borderline of being able to.
The ASCI bunch favour Co-array Fortran, and its model matches Python
like a steam turbine is a match for a heart transplant.
[*] They are worth looking up, if you don't know about them.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
e.
They use it for the communication, but don't expose it to the
programmer. It is therefore easy to put the processes on different
CPUs, and get the memory consistency right.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
ONCEPTS in common between
POSIX and C's memory consistency 'specifications' is perhaps the worst.
That is why many POSIX threads programs work until the genuinely
shared memory accesses become frequent enough that you get some to the
same location in a single machine cycle.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
HPC system in UK academia for a decade,
ending less than a year ago, incidentally, and was and am fairly well
in touch with what is going on in HPC world-wide.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
for a couple of decades. Indeed, a lot of
modern programmers regard having to distort simple expressions in that
way as anathema.
It isn't a major issue, because our experience from then is that it is
both teachable and practical, but it IS a way in which any base above
2 is significantly worse than base 2.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
and others forcing "consistency" (which is
not actually defined, and there are many possible, incompatible,
interpretations). It leaves all language aspects (including allowed
code movement) to C.
There are no concepts in common between C's and POSIX's consistency
specifica
n primitives, and
threading models like OpenMP and BSP have explicit control.
Also, MPI has asynchronous (non-blocking) communication.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
reasons why what seems to be a more heavyweight mechanism (message
passing) can be faster than an apparently lightweight one (data sharing)
are both subtle and complicated.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
- like rational,
it would be straightforward to add to Python as an extension type.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
e the last
bit to 1. An old, cheap approximation to rounding.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
st enough for real work by someone who
is not deeply into developing Grid software, I will be amazed.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
Carsten Haese <[EMAIL PROTECTED]> writes:
|> On Thu, 2007-01-11 at 23:47 +, Nick Maclaren wrote:
|> > In article <[EMAIL PROTECTED]>,
|> > Facundo Batista <[EMAIL PROTECTED]> writes:
|> > |> Noud Aldenhoven wrote
her one can replace the other,
So far, so good. With reservations, I agree.
|> but there are more use
|> cases for Decimal than for Rational.
That is dubious, but let's not start that one again.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
anipulated appropriately.
Yes, I know that's "cheating" :-)
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
ATING-point
helps with providing that, but that claim is extremely dubious.
I can explain the problem in as much detail as you want, but would
very much rather not.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
ow!".
Oh, because it's not a proper data type! The data type is an expression,
and is held in a structured form, of which such powers may be one level.
This is better regarded as an optimisation of a common case than a true
data type. Now, there MAY be such a language that supports such
it was used on the old, discrete-logic, machines.
I have been told by hardware people that implementing IEEE 754 rounding
and denormalised numbers needs a horrific amount of logic - which is
why only IBM do it all in hardware. And the decimal formats are
significantly more complicated.
What
width). Python could, probably.
However, that isn't what the Decimal module does anyway. People will
specify more digits than they possibly need, not realising that they
need to specify many MORE if they are going to support multiplication.
Coming back to the start, is fixing that little
t of the base.
So, at a wild guesstimate, 64-bit decimal will deliver a precision
comparable to about 56-bit binary, and will cause significant numerical
problems to a FEW applications. Hence people will have to convert to
the much more expensive 128-bit decimal format for such work.
Bloatware rules. All your bits are belong to us.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
tware and throw a switch
selecting between the two rounding rules.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
cent encapsulation.
The decimal floating-point brigade grossly exaggerate the difficulty of
doing that, in order to persuade people that their solution is better.
If they admitted the difficulties of using decimal floating-point, and
merely said "but, overall, we think it is a better solution
an exception if a 1 ULP change in the floating-
point number would give a different answer; this is needed to make
certain operations reliable.
The default formatting does the obvious thing :-)
Er, that's about it
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
applications. In 30 years, it
has got almost nowhere.
Don't confuse interval methods with interval arithmetic, because you
don't need the latter for the former, despite the claims that you do.
|> For people just getting into it, it can be shocking to realize just how
|> wide the
t; past an experiment.
As the same is true for what plenty of people have done, despite them
having good backgrounds in mathematics, don't feel inferior!
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
oth the problem and global
optimisation.
This is why the "statistical" methods (so disliked by Kahan) are used.
In a fair number of cases, they give reasonable estimates of the error.
In others, they give a false sense of security :-(
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
1 - 100 of 118 matches
Mail list logo
