On Mon, Oct 19, 2009 at 11:20:50PM +0100, Frank Peelo wrote:
> Gustavo Enrique Jimenez wrote:
>> 2009/10/18 Tom Verhoeff :
>>> A simple example is the situation where one needs to calculate
>>> the replacement resistor value R for parallel resistors having
>>> values R1, R2, ..., Rk. The formula i
On Mon, Oct 19, 2009 at 02:57:10PM -0300, Gustavo Enrique Jimenez wrote:
> 2009/10/18 Tom Verhoeff :
> > A simple example is the situation where one needs to calculate
> > the replacement resistor value R for parallel resistors having
> > values R1, R2, ..., Rk. The formula is R = 1/(1/R1 + 1/R2 +
Jonas,
> In theory this is of course possible, but in practice this is extremely
> error prone due to the nature of signal handlers. Furthermore, adding extra
> global variables to the interface of the system unit is very much frowned
> upon, and this would be required since the signal handling ha
On 19 Oct 2009, at 19:08, Bart wrote:
In the code that "translates" the "you did something nasty" to
runerror(some_exit_code) it may be possible to differentiate between
float and integer fault?
It is (on some platforms with some hacking).
This info could then be stored in some variable/obj
Gustavo Enrique Jimenez wrote:
2009/10/18 Tom Verhoeff :
A simple example is the situation where one needs to calculate
the replacement resistor value R for parallel resistors having
values R1, R2, ..., Rk. The formula is R = 1/(1/R1 + 1/R2 + ... + 1/Rk).
The formula gives a divide-by-zero if o
2009/10/18 Tom Verhoeff :
> A simple example is the situation where one needs to calculate
> the replacement resistor value R for parallel resistors having
> values R1, R2, ..., Rk. The formula is R = 1/(1/R1 + 1/R2 + ... + 1/Rk).
> The formula gives a divide-by-zero if one of the resistors has va
Jonas,
I might be just babbling, since I really have no idea how it's done, but:
In the code that "translates" the "you did something nasty" to
runerror(some_exit_code) it may be possible to differentiate between
float and integer fault?
This info could then be stored in some variable/object that
On 19 Oct 2009, at 17:04, Bart wrote:
Could you comment on my opinion that in case of a floating point
divide by zero error an EZeroDivide should be raised (or no exception
at all depending on the FPU exception mask) and only in case of
integer divide by zero (div operation) an EDivByZero shoul
Jonas,
Could you comment on my opinion that in case of a floating point
divide by zero error an EZeroDivide should be raised (or no exception
at all depending on the FPU exception mask) and only in case of
integer divide by zero (div operation) an EDivByZero should be raised?
This was my original
On 19 Oct 2009, at 14:36, Jonas Maebe wrote:
In case it's Mac OS X on x86: floating point exception reporting via
Unix signals isn't exactly its forte.
And in case Mac OS X on ppc: the same caveats apply as for x86, except
that we don't have to any opcode decoding since the PPC doesn't rai
On 19 Oct 2009, at 14:14, Tom Verhoeff wrote:
On Mon, Oct 19, 2009 at 10:21:01AM +0200, Jonas Maebe wrote:
http://www.freepascal.org/docs-html/rtl/math/setexceptionmask.html
Fully cross-platform, even.
How new is that?
Not very. I think it exists at least since 2.0.0.
It works 'part
On Mon, Oct 19, 2009 at 10:21:01AM +0200, Jonas Maebe wrote:
>
> On 18 Oct 2009, at 17:52, Tom Verhoeff wrote:
>
>> It would be nicer if one had the ability to make floating-point
>> division
>> by zero return an IEEE 754 plus/minus infinity, without raising an
>> exception.
>
> http://www.freepa
On Sun, Oct 18, 2009 at 02:49:40PM -0200, Jorge Aldo G. de F. Junior wrote:
> Wouldnt a NaN (Not a number) be more "matematically correct" result (I saw
> that on an old book about i387)
No, read Kahan's article that I pointed to.
> Matematically division by zero is an "mathematical impossibility
Hi all,
Interesting thoughts.
However, if we raise an exception, why do we raise EDivByZero instead
of EZeroDivide?
Note: EDivByZero = class(EIntError), so IMHO it makes no sense to
raise it with a floating point error.
Bart
___
fpc-pascal maillist -
On 18 Oct 2009, at 17:52, Tom Verhoeff wrote:
It would be nicer if one had the ability to make floating-point
division
by zero return an IEEE 754 plus/minus infinity, without raising an
exception.
http://www.freepascal.org/docs-html/rtl/math/setexceptionmask.html
Fully cross-platform, even
On Sun, Oct 18, 2009 at 18:49, Jorge Aldo G. de F. Junior
wrote:
> Wouldnt a NaN (Not a number) be more "matematically correct" result (I saw
> that on an old book about i387)
>
> Matematically division by zero is an "mathematical impossibility", so NaN
> would be more logical
>
> Is there a way t
Is there a way to deal with NaN's and other i387 (and similars)
conventions directly in Pascal ?
Yes, if not yet possible (I didn't have a closer look) I would like to
have that too. But I think it's heavily depending on the processor...
(Details about NaN's and infinity at http://en.wikipedi
Wouldnt a NaN (Not a number) be more "matematically correct" result (I saw
that on an old book about i387)
Matematically division by zero is an "mathematical impossibility", so NaN
would be more logical
Is there a way to deal with NaN's and other i387 (and similars) conventions
directly in Pascal
On Sat, Oct 17, 2009 at 01:57:28PM +0200, Bart wrote:
>
> Is there a reason why in fpc both floating point and integer division
> by zero raise an EDivByZero exception?
>
> See: http://docwiki.embarcadero.com/VCL/en/SysUtils.EZeroDivide
>
> SysUtils.EZeroDivide exception is raised when an applic
Hi,
Is there a reason why in fpc both floating point and integer division
by zero raise an EDivByZero exception?
See: http://docwiki.embarcadero.com/VCL/en/SysUtils.EZeroDivide
SysUtils.EZeroDivide exception is raised when an application attempts
to divide a floating-point value by zero.
Note:
20 matches
Mail list logo
