[EMAIL PROTECTED] wrote:
I'm not asking you to describe SC22WG14 or post detailed technical summaries
of the long and painful road. I'd like you to post things directly relevant
to Python with footnotes to necessary references. It is then incumbent on
those that wish to respond to your
Neal Norwitz [EMAIL PROTECTED] wrote:
Seriously, there seems to be a fair amount of miscommunication in this
thread. ...
Actually, this isn't really a reply to you, but you have described
the issue pretty well.
The best design doc that I know of is code. :-)
It would be much easier to
To the moderator: this is getting ridiculous.
[EMAIL PROTECTED] wrote:
Unfortunately, that doesn't help, because it is not where the issues
are. What I don't know is how much you know about numerical models,
IEEE 754 in particular, and C99. You weren't active on the SC22WG14
Michael Hudson [EMAIL PROTECTED] wrote:
But, a floating point exception isn't a machine check interrupt, it's
a program interrupt...
For reasons that I could go into, but are irrelevant, almost all
modern CPU architectures have one ONE interrupt mechanism, and use
it for both of those. It is
Tim Peters [EMAIL PROTECTED] wrote:
I suspect Nick spends way too much time reading standards ;-)
God help me, YES! And in trying to get them improved. Both of which
are very bad for my blood pressure :-(
My real interest is in portable, robust programming - I DON'T abuse
the terms to mean
Tim Peters [EMAIL PROTECTED] wrote:
SC22WG14? is that some marketing academy? not a very good one, obviously.
That's because it's European ;-)
Er, please don't post ironic satire of that nature - many people will
believe it!
ISO is NOT European. It is the Internatational Standards
Terry Reedy [EMAIL PROTECTED] wrote:
Of interest among their C-EPs is one for adding the equivalent of our
decimal module
http://www.open-std.org/jtc1/sc22/wg14/www/projects#24732
IBM is mounting a major campaign to get its general decimal arithmetic
standardised as THE standard form of
Jim Jewett [EMAIL PROTECTED] wrote:
The conventional interpretation was that any operation that
was not mathematically continuous in an open region including its
argument values (in the relevant domain) was an error, and that all
such errors should be flagged. That is what I am talking
Nick Maclaren [EMAIL PROTECTED] wrote:
Facundo Batista [EMAIL PROTECTED] wrote:
Well, so I'm completely lost... because, if all you want is to be able
to chose a returned value or an exception raised, you actually can
control that in Decimal.
Yes, but I have so far failed to get hold
On 6/23/06, Nick Maclaren [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote: Unfortunately, that doesn't help, because it is not where the issues are.What I don't know is how much you know about numerical models,
IEEE 754 in particular, and C99.You weren't active on the SC22WG14 reflector, but
On 6/22/06, Nick Maclaren [EMAIL PROTECTED] wrote:
Not a lot.Annex F in itself is only numerically insane.You need to know the rest of the standard, including that which is documented only in SC22WG14 messages, to realise the full horror.
[...]Unfortunately, that doesn't help, because it is
Nick Maclaren [EMAIL PROTECTED] writes:
My intentions are to provide some numerically robust semantics,
preferably of the form where straightforward numeric code (i.e. code
that doesn't play any bit-twiddling tricks) will never invoke
mathematically undefined behaviour without it being
Nick Maclaren wrote:
Unfortunately, that doesn't help, because it is not where the issues
are. What I don't know is how much you know about numerical models,
IEEE 754 in particular, and C99. You weren't active on the SC22WG14
reflector, but there were some lurkers.
SC22WG14? is that some
[Kevin Jacobs]
...
A good place to start: You mentioned earlier that there where some
nonsensical things in floatobject.c. Can you list some of the most serious
of these?
I suspect Nick spends way too much time reading standards ;-) What he said is:
If you look at floatobject.c, you
Nick Maclaren wrote:
The standard floating-point model is that it maps functions defined on
the reals (sometimes complex) to approximations defined on floating-
point.
OK.
The conventional interpretation was that any operation that
was not mathematically continuous in an open region
Fredrik Lundh wrote:
Nick Maclaren wrote:
Unfortunately, that doesn't help, because it is not where the issues
are. What I don't know is how much you know about numerical models,
IEEE 754 in particular, and C99. You weren't active on the SC22WG14
reflector, but there were some lurkers.
Nick Coghlan [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
SC22WG14? is that some marketing academy? not a very good one,
obviously.
http://www.open-std.org/jtc1/sc22/wg14/
Looks like python-dev for C, only with extra servings of international
bureaucracy and vendor
[/F]
SC22WG14? is that some marketing academy? not a very good one, obviously.
That's because it's European ;-) The ISO standards process has highly
visible layers of bureaucracy, and, in full, JTC1/SC22/WG14 is just
the Joint ISO/IEC Technical Committee 1's SubCommittee 22's Working
Group 14
Nick Maclaren [EMAIL PROTECTED] writes:
Michael Hudson [EMAIL PROTECTED] wrote:
This mail never appeared on python-dev as far as I can tell, so I'm
not snipping anything.
And it still hasn't :-( I am on the list of recipients without posting
rights, and the moderator appears to be on
Michael Hudson wrote:
I get the impression that you would like to see floatobject.c
rewritten to make little or no use of the FPU, is that right? Also,
you seem to have an alternate model for floating point calculations in
mind, but seem very reluctant to actually explain what this is.
I
Very interesting. I need to investigate in more depth.
The work-in-progress can be seen in Python's SVN sandbox:
http://svn.python.org/view/sandbox/trunk/decimal-c/
beelzebub$svn checkout http://svn.python.org/view/sandbox/trunk/decimal-c/
svn: PROPFIND request failed on
Michael Hudson [EMAIL PROTECTED] wrote:
Maybe append for me, at least to what I wrote then. But really, it
is hard: because Python runs on so many platforms, and platforms that
no current Python developer has access to. If you're talking about
implementing FP in software (are you?), then
On Thu, Jun 22, 2006, Nick Maclaren wrote:
Sigh. What I am trying to get is floating-point support of the form
that, when a programmer makes a numerical error (see above), he gets
EITHER an exception value returned OR an exception raised.
Then you need to write up a detailed design
On 6/22/06, Aahz [EMAIL PROTECTED] wrote:
On Thu, Jun 22, 2006, Nick Maclaren wrote:
Sigh. What I am trying to get is floating-point support of the form
that, when a programmer makes a numerical error (see above), he gets
EITHER an exception value returned OR an exception raised.
Then
Facundo Batista wrote:
2006/6/20, Nick Coghlan [EMAIL PROTECTED]:
The intent was always to replace the internal use of tuples and longs
with a
more efficient C implementation - that particular step simply wasn't
needed
for the original use case that lead Facundo to write and implement PEP
On Wed, Jun 21, 2006, Nick Coghlan wrote:
Facundo Batista wrote:
BTW, prove me Decimal is not fast enough, ;)
C:\Python24python -m timeit -s x = 1.0 x+x
1000 loops, best of 3: 0.137 usec per loop
C:\Python24python -m timeit -s from decimal import Decimal as d; x = d(1)
x+x
1
Nick Coghlan wrote:
BTW, prove me Decimal is not fast enough, ;)
C:\Python24python -m timeit -s x = 1.0 x+x
1000 loops, best of 3: 0.137 usec per loop
C:\Python24python -m timeit -s from decimal import Decimal as d; x = d(1)
x+x
1 loops, best of 3: 48.3 usec per loop
I don't
On 6/21/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
BTW, prove me Decimal is not fast enough, ;)
C:\Python24python -m timeit -s x = 1.0 x+x
1000 loops, best of 3: 0.137 usec per loop
C:\Python24python -m timeit -s from decimal import Decimal as d; x =
d(1)
Brett Cannon's and Neal Norwitz's replies appreciated and noted, but
responses sent by mail.
Nick Coghlan [EMAIL PROTECTED] wrote:
Python 2.4's decimal module is, in essence, a floating point emulator based
on
the General Decimal Arithmetic specification.
Grrk. Format and all? Because,
Michael Hudson [EMAIL PROTECTED] wrote:
As I have posted to comp.lang.python, I am not happy with Python's
numerical robustness - because it basically propagates the 'features'
of IEEE 754 and (worse) C99.
That's not really now I would describe the situation today.
It is certainly the
This mail never appeared on python-dev as far as I can tell, so I'm
not snipping anything.
On 19 Jun 2006, at 16:29, Nick Maclaren wrote:
Michael Hudson [EMAIL PROTECTED] wrote:
As I have posted to comp.lang.python, I am not happy with Python's
numerical robustness - because it basically
Nick Maclaren wrote:
Brett Cannon's and Neal Norwitz's replies appreciated and noted, but
responses sent by mail.
Nick Coghlan [EMAIL PROTECTED] wrote:
Python 2.4's decimal module is, in essence, a floating point emulator based
on
the General Decimal Arithmetic specification.
Grrk.
2006/6/20, Nick Coghlan [EMAIL PROTECTED]:
Nick Maclaren wrote:
Brett Cannon's and Neal Norwitz's replies appreciated and noted, but
responses sent by mail.
Damn, the most difficult way to keep a thread...
The intent was always to replace the internal use of tuples and longs with a
more
Nick Maclaren [EMAIL PROTECTED] writes:
As I have posted to comp.lang.python, I am not happy with Python's
numerical robustness - because it basically propagates the 'features'
of IEEE 754 and (worse) C99.
That's not really now I would describe the situation today.
Yes, it's better, but I
On 6/19/06, Michael Hudson [EMAIL PROTECTED] wrote:
Nick Maclaren [EMAIL PROTECTED] writes:
2) Because some people are dearly attached to the current behaviour,
warts and all, and there is a genuine quandary of whether the 'right'
behaviour is trap-and-diagnose, propagate-NaN or
As I have posted to comp.lang.python, I am not happy with Python's
numerical robustness - because it basically propagates the 'features'
of IEEE 754 and (worse) C99. Yes, it's better, but I would like to
make it a LOT better. I already have a more robust version of 2.4.2,
but there are some
[skipping answering the numeric-specific questions since I am no math expert =) ]On 6/15/06, Nick Maclaren [EMAIL PROTECTED]
wrote:As I have posted to comp.lang.python, I am not happy with Python's
numerical robustness - because it basically propagates the 'features'of IEEE 754 and (worse)
You should be aware of PEP 754 and address it.
http://www.python.org/dev/peps/pep-0754/
Also note that Python conforms to C89, not C99. Any solution should
work on all Python platforms. Some of those platforms are here:
http://www.python.org/dev/buildbot/all/
n
--
On 6/18/06, Brett Cannon
Nick Maclaren wrote:
5) I am NOT offering to write a full floating-point emulator, though
it would be easy enough and could provide repeatable, robust results.
Easy does not mean quick :-( Maybe when I retire. Incidentally,
experience from times of yore is that emulated floating-point would
Nick Maclaren [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
experience from times of yore is that emulated floating-point would
be fast enough that few, if any, Python users would notice.
Perhaps you should enquire on the Python numerical and scientific computing
lists to see how
40 matches
Mail list logo
