Mathias Fröhlich wrote:
If you want to keep them, please help me and review that patch I have posted
a
few days ago. Please *verify* that the remaining functions do about the right
thing past converting them to something that is not even misscompiled.
If nobody helps here, I will finally
On Wednesday 21 June 2006 13:03, Christian Mayer wrote:
These functions can be great - when you know in advance (1) the number
range, (2) the required error range and that you are (3) in a very tight
loop that is (4) performance critical. So I'd leave them in.
Yes, but I doubt that I will
Olaf Flebbe wrote:
Hi,
The comment for fast_log is IMHO incorrect.
/**
* This function is about 3 times faster than the system log() function
* and has an error of about 0.01%
*/
The relative error can be larger than 7% it is almost nowhere about
0.01% when used in the range [ 0.5 -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Erik Hofman schrieb:
Olaf Flebbe wrote:
Hi,
The comment for fast_log is IMHO incorrect.
/**
* This function is about 3 times faster than the system log() function
* and has an error of about 0.01%
*/
The relative error can be larger than 7%
Hi,
The comment for fast_log is IMHO incorrect.
/**
* This function is about 3 times faster than the system log() function
* and has an error of about 0.01%
*/
The relative error can be larger than 7% it is almost nowhere about
0.01% when used in the range [ 0.5 - 1[. Try yourself:
Olaf
Hi,
... was offline, sorry.
On Saturday 17 June 2006 23:28, Erik Hofman wrote:
You know, I did a quick grep in the source code for fast_ and only found
it to be used in simgear/sound/xmlsound.cxx (namely fast_log10 and
fast_log). Maybe we can get rid of them after all.
In that time, I have
Mathias Fröhlich wrote:
I would never use these functions for serious computations, since I doubt
that
they will pass any IEEE test.
They are not designed for that either. It can be useful for sound
processing and color adjustments where very high precision isn't
necessary. I use it for
On Saturday 17 June 2006 10:05, Erik Hofman wrote:
Mathias Fröhlich wrote:
I would never use these functions for serious computations, since I doubt
that they will pass any IEEE test.
They are not designed for that either. It can be useful for sound
processing and color adjustments where
Mathias Fröhlich wrote:
Performance is a critical subject to me.
But IMO the possible advantages of the fastmath functions are too few
compared
to the possible problems.
I've never advocated using these routines for FMD's or anything like
that since it could get messy really quick. But
Hi Erik,
On Saturday 17 June 2006 10:54, Erik Hofman wrote:
Mathias Fröhlich wrote:
Performance is a critical subject to me.
But IMO the possible advantages of the fastmath functions are too few
compared to the possible problems.
I've never advocated using these routines for FMD's or
* Erik Hofman -- Friday 16 June 2006 09:34:
It think it would be best to use offset and factor just like most of
the other configurations (sound/animations).
I'm now using property/factor/offset for all numeric values. Some
HUD elements need two values. I'm now just using property n=1/
factor
Mathias Fröhlich wrote:
If you feel that they should be used, can you care for them and make them
alias safe?
Not at this time, I've got other things on my prioritylist.
Erik
--
http://www.ehtw.info (Dutch)Future of Enschede Airport Twente
http://www.ehofman.com/fgfs FlightGear
On Saturday 17 June 2006 14:54, Erik Hofman wrote:
Mathias Fröhlich wrote:
If you feel that they should be used, can you care for them and make them
alias safe?
Not at this time, I've got other things on my prioritylist.
Ok, the ones in fastmath.hxx are easy to fix, I have already prepared
Mathias Fröhlich wrote:
Seriously, I *can* think of fast_atan's polynomials being faster than a full
blown correct functioin.
But those simple fabs, sign or neg function implemented in the header cannot
even be faster than the cpu builtin assembler instructions usually available
on
* Erik Hofman -- Thursday 15 June 2006 22:35:
That's why I said I would copy the necessary files (all HUD related
code) to Instrumentation/HUD and rename the class(es) and leave the old
code to rust away.
OK. Done that. For now I've decided to make it a regular subsystem
that's registered by
Melchior FRANZ wrote:
data_scale becomes scale too (both exist currently
for the same thing in different HUD elements,
which hinders abstraction)
It think it would be best to use offset and factor just like most of
the other
* Erik Hofman -- Friday 16 June 2006 09:34:
Melchior FRANZ wrote:
data_scale becomes scale too (both exist currently
for the same thing in different HUD elements,
which hinders abstraction)
It think it would be best to use
* Melchior FRANZ -- Friday 16 June 2006 09:41:
BTW: I'd like to move Cockpit/hud_opts.hxx elsewhere. Don't know what
the assembler parts do, but the fallback implies that it's a quick
rounding function.
Or is it not worth at all to be done in assember nowadays?
m.
Melchior FRANZ wrote:
* Melchior FRANZ -- Friday 16 June 2006 09:41:
BTW: I'd like to move Cockpit/hud_opts.hxx elsewhere. Don't know what
the assembler parts do, but the fallback implies that it's a quick
rounding function.
Or is it not worth at all to be done in assember nowadays?
I
* Erik Hofman -- Friday 16 June 2006 09:51:
I think it's best to use the default functions supplied by the system
libraries (in this case lrintf() ? )
lrintf is c99 according to the man page, and so it roundf().
(int)rintf() then?
m.
___
Melchior FRANZ wrote:
* Erik Hofman -- Friday 16 June 2006 09:51:
I think it's best to use the default functions supplied by the system
libraries (in this case lrintf() ? )
lrintf is c99 according to the man page, and so it roundf().
(int)rintf() then?
Hmm, I doubt this will be faster
Erik Hofman a écrit :
Melchior FRANZ wrote:
* Erik Hofman -- Friday 16 June 2006 09:51:
I think it's best to use the default functions supplied by the system
libraries (in this case lrintf() ? )
lrintf is c99 according to the man page, and so it roundf().
(int)rintf()
On Friday 16 June 2006 10:18, Erik Hofman wrote:
Melchior FRANZ wrote:
* Erik Hofman -- Friday 16 June 2006 09:51:
I think it's best to use the default functions supplied by the system
libraries (in this case lrintf() ? )
lrintf is c99 according to the man page, and so it roundf().
* Erik Hofman -- Thursday 15 June 2006 15:32:
Melchior FRANZ wrote:
(a) an FGInstrumentMgr controlled class instance, and if so: should it
be moved to Instrumentation/HUD/?
That's my preference, especially since it will be a completely
overhauled version of the HUD code.
The
* Erik Hofman -- Thursday 15 June 2006 15:32:
* Melchior FRANZ wrote:
My preference is, of course, to switch and let loadfn die immediately. :-)
Yes, I can imagine but I think the cases where the old code is/has been
used outside of the FlightGear scope are all cases that draw attention
Melchior FRANZ wrote:
* Erik Hofman -- Thursday 15 June 2006 15:32:
I would just copy the current code to a new location and rename it's
class to maybe XMLHUD or something.
And let the old code how and where it is for compatibility reasons? It
turns out that I can't do much more
How about some stub functions ?It's kind of temporary patch up that's organized in one place.So later on, you know where to look in to delete the obsolete stuff.IsaoErik Hofman [EMAIL PROTECTED] wrote: Melchior FRANZ wrote: * Erik Hofman -- Thursday 15 June 2006 15:32: I would just copy the
27 matches
Mail list logo
