[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
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>
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 fa
"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
"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
"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 Standa
"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 m
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
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
"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 easi
[/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 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 ve
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 lu
[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:
> 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 so
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 withou
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, beca
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 raise
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 docu
2006/6/22, Nick Maclaren <[EMAIL PROTECTED]>:
> > Now, a more general reply: what are you actually trying to acheive
> > with these posts? I presume it's more than just make wild claims
> > about how much more you know about numerical programming than anyone
> > else...
>
> Sigh. What I am tryin
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?
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 '/view/sandbox/tru
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.
>
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 appear
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 holiday.
> >>> As I have posted to comp.l
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 cer
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? Beca
On 6/21/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
>
> >> BTW, prove me Decimal is not fast enough, ;)
> >
> > C:\Python24>python -m timeit -s "x = 1.0" "x+x"
> > 1000 loops, best of 3: 0.137 usec per loop
> >
> > C:\Python24>python -m timeit -s "from decimal import Deci
Nick Coghlan wrote:
>> BTW, prove me Decimal is not fast enough, ;)
>
> C:\Python24>python -m timeit -s "x = 1.0" "x+x"
> 1000 loops, best of 3: 0.137 usec per loop
>
> C:\Python24>python -m timeit -s "from decimal import Decimal as d; x = d(1)"
> "x+x"
> 1 loops, best of 3: 48.3 usec p
On Wed, Jun 21, 2006, Nick Coghlan wrote:
> Facundo Batista wrote:
>>
>> BTW, prove me Decimal is not fast enough, ;)
>
> C:\Python24>python -m timeit -s "x = 1.0" "x+x"
> 1000 loops, best of 3: 0.137 usec per loop
>
> C:\Python24>python -m timeit -s "from decimal import Decimal as d; x = d(
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 im
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
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 specificatio
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 b
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 w
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, b
"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 se
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
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 <[E
[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) C99.
40 matches
Mail list logo
