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 6:
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 wh
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 note
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
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_arithm
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
http://lists
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:
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 imp
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 progr
> > 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
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
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,
On 4/18/06, Sasa Zeman <[EMAIL PROTECTED]> wrote:
> It is highly unlikely that any project will stay OpenSource and free of
> charge forever. As example is popular RedHat where worked 100s, maybe 1000s
> of people (volonitiers and contributers). It become commercial since v 8.0.
Comercial is not c
> If FreePascal founders are registrated as a company, contract would have
> legitimity in the law, otherwise will not.
Incorporating into a registered company doesn't really help secure anything
down - for example Borland could cut off the Delphi product at any time (or sell
it) even though the
On Tue, 18 Apr 2006, Sasa Zeman wrote:
Unless you have no interest at all in providing commercial grade
support, because it's just a hobby and you want to be free regarding
how much time you spend on it, on what you spend it.
Unless you calculate number od Delphi developer world wide.
I doub
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 mis-interpreting whole thing again.
>
> If you want more developers in the team, simply "yes or not" is not en
> 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 kn
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 p
> 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 arg
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 pr
> 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
>
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 any
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.
>
> > 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
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
m
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
compiler
> 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 is
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 :)
___
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 com
> 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
> wo
> 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 reas
> 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.
Ins
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 objectiv
> > 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,
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 le
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
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 51
> > 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 cons
>
> 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 se
> 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
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 Pasca
> 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:
>> 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 calcula
> 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:
>> 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 checki
> 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 gl
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
> > 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 is
> 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
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 exception (u
70 matches
Mail list logo
