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 fina
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 ide
* Mathias Fröhlich -- Monday 19 June 2006 19:19:
> I have also removed the functions that are very most likely slower than the
> libm implementations from the header.
Concerning that float_to_int() thingy: what I really wanted was to get
rid of it in Cockpit/, where stuff like that just doesn't b
-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 c
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 rang
And BTW fast_log2 don't work correctly with denormalized numbers, i.e.
very small numbers, which can easily happen when cancellation effects
occur.
Try x = 1.e-45 and you get an error of more then 14%. (This is
enormous for a log() type function). Please remove this function and
use log() instea
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
#inclu
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 hav
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 cu
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 pre
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 Fl
* Erik Hofman -- Friday 16 June 2006 09:34:
> It think it would be best to use and just like most of
> the other configurations (sound/animations).
I'm now using // for all numeric values. Some
HUD elements need two values. I'm now just using /
/ for those. That's a bit ugly and one could
put i
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
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
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
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 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 ro
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().
>>
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 fas
* 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.
___
Flightge
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 nowaday
* 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.
__
* Erik Hofman -- Friday 16 June 2006 09:34:
> Melchior FRANZ wrote:
> > becomes too (both exist currently
> > for the same thing in different HUD elements,
> > which hinders abstraction)
>
> It think it would be best to use and jus
Melchior FRANZ wrote:
> becomes too (both exist currently
> for the same thing in different HUD elements,
> which hinders abstraction)
It think it would be best to use and just like most of
the other configurations (sound/animati
* 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
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 cu
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 im
* Erik Hofman -- Thursday 15 June 2006 15:32:
* > Melchior FRANZ wrote:
> > My preference is, of course, to switch and let 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
> to
On Thursday 15 June 2006 12:03, Melchior FRANZ wrote:
> I've started to clean up the HUD code. ..
... Great stuff!
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
___
Flightgear-devel mailing list
Flightgear-devel@lists
* Melchior FRANZ -- Thursday 15 June 2006 16:13:
> [...]
>
>
>
> that depends on electricity and . The entry could
> be used once we have a *usable* render-to-texture HUD version.
Maybe I should have noted that I do, of course, not plan to break the
current HUD modes (2D, 3D). These sh
* 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.
Melchior FRANZ wrote:
> I've started to clean up the HUD code. I've moved all class-specific
> code to the classes. Before, each class had an external initializer
> that loaded the properties from the property tree and called a constructor
> with *many* parameters. Now the constructors are only poi
I've started to clean up the HUD code. I've moved all class-specific
code to the classes. Before, each class had an external initializer
that loaded the properties from the property tree and called a constructor
with *many* parameters. Now the constructors are only pointed to the
group node and fet
33 matches
Mail list logo
