Thank you Hairy, I will try to ask on the SDL forums.
Best,
Rafael Picanço
On Tue, Jan 30, 2024 at 8:48 AM Hairy Pixels wrote:
> I don't think this has anything to do with the compiler. You should
> probably ask on the SDL forums. They've been helpful for me before.
>
> > On Jan 30, 2024, at
I don't think this has anything to do with the compiler. You should probably
ask on the SDL forums. They've been helpful for me before.
> On Jan 30, 2024, at 6:45 PM, Rafael Picanço via fpc-pascal
> wrote:
>
> Hi everyone, how are you doing?
>
> I am receiving an "FLT divide by zero" error
Hi everyone, how are you doing?
I am receiving an "FLT divide by zero" error when creating a renderer with
// will default to Direct3d renderer
DL_CreateRenderer(FSDLWindow, -1,
// error
// SDL_RENDERER_ACCELERATED or SDL_RENDERER_PRESENTVSYNC
SDL_RENDERER_SOFTWARE
);
So, my
Hello,
WriteLn(FloatToStr(100 / 0));
This code prints on the screen +Inf, but I think it should be NaN.
Is this a bug or a special case in computer arithmetic?
thx
Michael
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
At Tuesday, 23.08.2011 on 8:57 Michael Fuchs wrote:
Hello,
WriteLn(FloatToStr(100 / 0));
This code prints on the screen +Inf, but I think it should be NaN.
Is this a bug or a special case in computer arithmetic?
http://en.wikipedia.org/wiki/Division_by_zero#In_computer_arithmetic
--
Am 23.08.2011 09:16, schrieb Andreas Schneider:
This code prints on the screen +Inf, but I think it should be NaN.
Is this a bug or a special case in computer arithmetic?
http://en.wikipedia.org/wiki/Division_by_zero#In_computer_arithmetic
Oh, thank you. I should not read only the german
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/object
On Mon, Oct 19, 2009 at 02:57:10PM -0300, Gustavo Enrique Jimenez wrote:
2009/10/18 Tom Verhoeff t.verho...@tue.nl:
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 =
On Mon, Oct 19, 2009 at 11:20:50PM +0100, Frank Peelo wrote:
Gustavo Enrique Jimenez wrote:
2009/10/18 Tom Verhoeff t.verho...@tue.nl:
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
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,
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 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, so
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.
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
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
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
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
2009/10/18 Tom Verhoeff t.verho...@tue.nl:
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
Gustavo Enrique Jimenez wrote:
2009/10/18 Tom Verhoeff t.verho...@tue.nl:
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
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 application
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 ?
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
On Sun, Oct 18, 2009 at 18:49, Jorge Aldo G. de F. Junior
jagf...@gmail.com 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
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:
On Wednesday 19 April 2006 16:32, L505 wrote:
I didn't say pure pascal programmers with no other skills.
Of course you didn't say *that*. But it still sounds like you are very
focused on language skills. Language skills are much less important
than people usually think.
most
pascal
2006/4/20, Vinzent Hoefler [EMAIL PROTECTED]:
On Wednesday 19 April 2006 16:32, L505 wrote:
I didn't say pure pascal programmers with no other skills.
Of course you didn't say *that*. But it still sounds like you are very
focused on language skills. Language skills are much less important
If you can't find jobs
out there that use Pascal then you have to be really brave and start
your own business and start hiring people with Pascal skills.
Yeah right. Sorry to bring that up again, but if I would do that I would
never hire people that claim to have such specialized skills.
Sasa Zeman wrote:
FPC can be comparable with command line compiler of Delphi 7.
Yes? So Delphi has multi platform support and has maintainable compiler
sources?
Multi platform support was not an issue here.
O, you were not comparing to fpc (from www.freepascal.org)? Because that
Sasa Zeman wrote:
FPC can be comparable with command line compiler of Delphi 7.
Yes? So Delphi has multi platform support and has maintainable compiler
sources?
Multi platform support was not an issue here.
No? Most of fpc's complexity is caused by this. Just compare the speed and
memory
EDO is more museum exponat and price is 10 times larger than the same memory
size SD-RAM. The used memory is one module 128MB SD-RAM (PC100). I've manage
to found only one 256MB module available on market with price of 50Euro, but
only incompatible PC133.
No, PC133 is backwards
Marco van de Voort wrote:
EDO is more museum exponat and price is 10 times larger than the same memory
size SD-RAM. The used memory is one module 128MB SD-RAM (PC100). I've manage
to found only one 256MB module available on market with price of 50Euro, but
only incompatible PC133.
No, PC133
On 18 apr 2006, at 03:38, Sasa Zeman wrote:
It seem that you missunderstood. As a developer, I'm not interested in
looking FPC code nor tracking future plans (details are alse never
published, only future plans), but using it to create working
applications.
In that case, you cannot make
Marco van de Voort wrote:
EDO is more museum exponat and price is 10 times larger than the same
memory
size SD-RAM. The used memory is one module 128MB SD-RAM (PC100). I've
manage
to found only one 256MB module available on market with price of 50Euro,
but
only incompatible
Marco van de Voort wrote:
Marco van de Voort wrote:
EDO is more museum exponat and price is 10 times larger than the same
memory
size SD-RAM. The used memory is one module 128MB SD-RAM (PC100). I've
manage
to found only one 256MB module available on market with price of 50Euro,
but
only
In that case, you cannot make any sort of demands or set our
priorities. You can voice your opinion of course (which you did), but
Please do not mis-interprete. I'm aware that any meber of FPC can be a bit
more sensitive, but that is not a reson for inpropriate behavior instead of
cultural
On 18 apr 2006, at 12:49, Sasa Zeman wrote:
With free and opensource product you made a trade with voluniers
and users
to make a reliable and popular product, based on your own (i.e, FPC
team)
vision and user's requests. I can suggest features which suits to
my own
needs (declared as a
The problem was when you kept insisting that the compiler wastes
memory and should be optimized (with a target of 128MB physical
Please read all carfully, you mis-interpreting whole thing again.
If you want more developers in the team, simply yes or not is not enough.
Explain how else to know
HI,
I think that we all agree now and we should close this thread.
Alain
On Tue, 2006-04-18 at 16:04 +0200, Sasa Zeman wrote:
The problem was when you kept insisting that the compiler wastes
memory and should be optimized (with a target of 128MB physical
Please read all carfully, you
On Tuesday 18 April 2006 17:24, L505 wrote:
sense to me.). Or maybe you mean a foundation, like a non-profit
organization? Obviously FPC is not out for profit, but out to help
the developer. So I can see a non-profit organization working - but
this would mean that FPC team would spend more
Definition in documentation (RTL.pdf):
29.20 EDivByZero
29.20.1 Description
EDivByZero is used when the operating system or CPU signals a division by
zero error.
... and since these are handled by the compiler for constants, when running
the user program, the CPU will never see it. So
hint. Since 1/0=Inf is IEEE compliant, it's no real error. If people
really want an error, they can create their own error msg file making
the hint an error.
Unfortunatelly, this is a major problem with specific environment and type
of application... :-(
In this case, I consider it is
Regarding division problem. Florian was precise in explanation (suggested to
be part of documentation).
I think even _if_ there is a focus on getting the memusage down (and there
is, it is one of the internal linkers objectives), it should be more to
let
Lazarus perform optimally with say
Sasa Zeman wrote:
Regarding division problem. Florian was precise in explanation (suggested to
be part of documentation).
I think even _if_ there is a focus on getting the memusage down (and there
is, it is one of the internal linkers objectives), it should be more to
let
Lazarus perform
On 17 Apr 2006, at 16:52, Sasa Zeman wrote:
Inside total phisical memory of 128MB, Delphi compililation is very
fast.
That mean that process of compilation is optimized to work with
available
phisical memory (at least under 128MB).
It may simply be that for some reason, Delphi requires
Lazarus perform optimally with say 512-1024MB memory, and not to try to
squeeze it into sub 128 MB. That would be counterproductive.
Inside total phisical memory of 128MB, Delphi compililation is very fast.
Not in a modern version. It won't even start probably.
The point however is, those
Am Montag, den 17.04.2006, 16:52 +0200 schrieb Sasa Zeman:
Regarding division problem. Florian was precise in explanation (suggested to
be part of documentation).
I think even _if_ there is a focus on getting the memusage down (and there
is, it is one of the internal linkers objectives),
I think even _if_ there is a focus on getting the memusage down (and there
is, it is one of the internal linkers objectives), it should be more to
let
Lazarus perform optimally with say 512-1024MB memory, and not to try to
squeeze it into sub 128 MB. That would be counterproductive.
Inside
IMHO you should already be happy with the internal linker because you are
now able to create a smartlinked lazarus without requiring 1+ GB of
memory.
FPC and Lazarus are just testing alternatives. Comparing FPC performance of
internal linker with Delphi's or with external LD, I found no reason
Not in a modern version. It won't even start probably.
FPC can be comparable with command line compiler of Delphi 7. D2005-6
compile C/C++ (CBuilder) code among other features raise complexity, which
are not FPC tasks.
If we would try to match that, uncompromisingly, with Free Pascal, we
Sasa Zeman wrote:
Not in a modern version. It won't even start probably.
FPC can be comparable with command line compiler of Delphi 7.
Yes? So Delphi has multi platform support and has maintainable compiler
sources?
D2005-6
compile C/C++ (CBuilder) code among other features raise
Sasa Zeman wrote:
Keep in mind that I'm not in FPC developer team nor I'm interested.
Please keep in mind that FPC/Lazarus is OSS and that it lives from it's
user's contributions. If you don't like the idea of OSS, better stay
with Delphi and hope that it survives :)
Please keep in mind that FPC/Lazarus is OSS and that it lives from it's
user's contributions.
It seem that you missunderstood. As a developer, I'm not interested in
looking FPC code nor tracking future plans (details are alse never
published, only future plans), but using it to create working
FPC can be comparable with command line compiler of Delphi 7.
Yes? So Delphi has multi platform support and has maintainable compiler
sources?
Multi platform support was not an issue here.
It seems that all previously produced compiled code left in memory, even
if It seems but it isn't
Sasa Zeman wrote:
FPC 2.0.2 do not rasie exception on integer/floats division by Zero,
which
is suitable for calucaltion I currently developing. Instead, division
return infinity:
writeln(1/0) - +inf
writeln(1.0/0) - +inf
Already fixed.
Unfortunatelly, bug still persists when division
We don't consider this as a bug, it's for delphi compatibility reasons.
These expressions are evaluated at compile time, so it's something
differnt. If you want to get an error, compile with -Cr.
The -Cr will point on error in the code, however, enabling range checking
will also affect on
Sasa Zeman wrote:
We don't consider this as a bug, it's for delphi compatibility reasons.
These expressions are evaluated at compile time, so it's something
differnt. If you want to get an error, compile with -Cr.
The -Cr will point on error in the code, however, enabling range checking
The program won't compile with -Cr.
Program with -Cr will compile and link if all is correct. Eventually range
check error compiler can predict, will stop compilation as usually.
Otherwise, program itself will check range on each attemp to work with
arrays or calculations, which is clearly waste
Sasa Zeman wrote:
The program won't compile with -Cr.
Program with -Cr will compile and link if all is correct. Eventually range
check error compiler can predict, will stop compilation as usually.
Otherwise, program itself will check range on each attemp to work with
arrays or calculations,
People will complain, if FPC isn't delphi compatible.
FP actually is not 100% Delphi compatible by default mode and it is not
intention to be (regarding available informations on internet) it is
actually intented to be compatible with Turbo/Borland Pascal, I suppose.
Delphi simulation mode (-Sd,
Sasa Zeman wrote:
People will complain, if FPC isn't delphi compatible.
FP actually is not 100% Delphi compatible by default mode and it is not
That's true.
intention to be (regarding available informations on internet) it is
actually intented to be compatible with Turbo/Borland Pascal, I
Well, I consider the problem as minor so I don't know if it's worth to
introduce a new switch. I guess the best solution is to throw always a
hint. Since 1/0=Inf is IEEE compliant, it's no real error. If people
really want an error, they can create their own error msg file making
the hint an
FPC 2.0.2 do not rasie exception on integer/floats division by Zero, which
is suitable for calucaltion I currently developing. Instead, division
return
infinity:
writeln(1/0) - +inf
writeln(1.0/0) - +inf
With excluding zero exception from SetExceptionMask(), it dows not turn on
the
62 matches
Mail list logo
