Re: [fpc-pascal] Dynamic arrays performance test.

2005-03-02 Thread Jonas Maebe
On 2 mrt 2005, at 07:29, Florian Klaempfl wrote:
- FPC's random is probably more complex
Indeed. I guess Delphi's is still a simple "(x * prime1) mod prime2" or 
so. FPC uses the Mersenne twister.

Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Dynamic arrays performance test.

2005-03-02 Thread Agustin Barto
On Wed, 2 Mar 2005 11:05:50 +0100, Jonas Maebe <[EMAIL PROTECTED]> wrote:
> 
> On 2 mrt 2005, at 07:29, Florian Klaempfl wrote:
> 
> > - FPC's random is probably more complex
> 
> Indeed. I guess Delphi's is still a simple "(x * prime1) mod prime2" or
> so. FPC uses the Mersenne twister.
> 
> Jonas

Bingo. That was it. Now the fpc version is at least as fast as the
Delphi version on the worst case and twice as fast using dynamic
arrays.

Agustin

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


[fpc-pascal] undefining multiple defines

2005-03-02 Thread Marc Santhoff
Hi,

I'm using several defines like this:

{$define M1}
{ $define M2}
{ $define M3}
{ $define M4}
...

Any time I have to change them, I have to touch all one by one, because
they're mutually exclusive.

Is there method of saying: {$undef M1..M15}?
Or a better basic approach? 

TIA,
Marc



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] undefining multiple defines

2005-03-02 Thread Jeff Miller
> I'm using several defines like this:
> 
> {$define M1}
> { $define M2}
> { $define M3}
> { $define M4}
> 
> Any time I have to change them, I have to touch all one by one, because
> they're mutually exclusive.
> 
> Or a better basic approach? 

Maybe I am missing something, but why not just have a single define statement, 
which you change to 
define the one symbol that you want for the current compile? If they are 
mutually exclusive, you 
never need more than one define, right?

Jeff

[EMAIL PROTECTED]



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] undefining multiple defines

2005-03-02 Thread Marc Santhoff
Am Do, den 03.03.2005 schrieb Jeff Miller um 13:56:
> > I'm using several defines like this:
> > 
> > {$define M1}
> > { $define M2}
> > { $define M3}
> > { $define M4}
> > 
> > Any time I have to change them, I have to touch all one by one, because
> > they're mutually exclusive.
> > 
> > Or a better basic approach? 
> 
> Maybe I am missing something, but why not just have a single define 
> statement, which you change to 
> define the one symbol that you want for the current compile? If they are 
> mutually exclusive, you 
> never need more than one define, right?

No, you don't. Thinking about it a little longer makes sense sometimes
(I'll do next time ;). And explaning the complete problem does, too.

These defines are used several times spread over a bunch of units. It is
possible to use one in unit a and another one in unit b. What i want to
achive is to undefine any previously set defines and be sure there is
only one of them active.

this is used to include some dependant functions from only one central
include file holding all possible versions. And it has to work from the
command line or makefile.

unit a;
...
{$define M1}
...
end.

unit b;
...
{$undef M1-M15}
{$define M2}
...
end.


Marc



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] undefining multiple defines

2005-03-02 Thread Marco van de Voort
> unit b;
> ...
> {$undef M1-M15}

Such constructs won't work, for the same reason that variablenames with
numbers in it can't be used as such.

For the compiler it is an alphanumerical identifier, and the number(s) have
no meaning.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal