> y = a >> 1; should do the same a bit faster :)
Sure, but I just needed a quick and simple example. :)
> btw where can you release your hq2x/lq2x algo as a patch against 0.76.1 ?
I'll assume you meant "when" i.s.o. "where", and if so, the answer is:
this weekend. We're currently running some la
hey pieter!
> y = 0.500*a;
> or
> y = (512*a) >> 10;
y = a >> 1; should do the same a bit faster :)
btw where can you release your hq2x/lq2x algo as a patch against 0.76.1 ?
i wanna have a look at it...
thanx
unicorn
--
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, Fi
Well, yeah... certainly it's a matter of how many mantissa bits
you have/need. =)
But assuming you have at least one extra bit of mantissa to
play with you can represent the .5 properly. I'm just saying
no matter how many mantissa bits you have you can't represent
other decimals exactly. (But g
Trent Piepho wrote:
On Sat, 25 Oct 2003, Greg Menke wrote:
Just because there are some applications that can live with the lossy
compression that floating point provide, doesn't mean that it's accurate.
It is entirely accurate when numbers are represented in base2, its when
That's not true at a
On Sat, 25 Oct 2003, Greg Menke wrote:
> > Just because there are some applications that can live with the lossy
> > compression that floating point provide, doesn't mean that it's accurate.
>
> It is entirely accurate when numbers are represented in base2, its when
That's not true at all. Floa
smf wrote:
Floating point is completely accurate
..
but a pretty
good one when you're doing calculations where the orders of magnitude
can vary by factors of 100 or more and some uncertainty in the least
significant digits is acceptable.
Those two statements are contradictory. Uncertainty =
Pieter Hulshoff wrote:
Hello all,
What in general creates faster code:
y = 0.500*a;
or
y = (512*a) >> 10;
?
Well the real question is "On what hardware" :)
On x86 it's probably the latter, but that may not
be the case forever.
-kt
--
Kingsley Turner,
(mailto: [EMAIL PROTECTED])
http://MadDogsBrea
> Agreed 100%. You cannot accurately represent 0.6 with a float,
> but in the case of dividing by 2 you can represent 0.5 accurately.
It depends on what number you're dividing into :-)
#include
int main( void )
{
float x1 = 0x1;
long long x2 = 0x1;
printf( "%f\n", x1 / 2 );
--- smf <[EMAIL PROTECTED]> wrote:
> Just because there are some applications that can live with
> the lossy
> compression that floating point provide, doesn't mean that
> it's accurate.
Agreed 100%. You cannot accurately represent 0.6 with a float,
but in the case of dividing by 2 you can
>Floating point is completely accurate
..
> but a pretty
> good one when you're doing calculations where the orders of magnitude
> can vary by factors of 100 or more and some uncertainty in the least
> significant digits is acceptable.
Those two statements are contradictory. Uncertainty = inna
smf wrote:
The question is do you care about any decimal you lose in the
process? e.g. 3 / 2 == 1 ?
11 shifted right becomes 01 and you lost the extra "half".
If the result you need is an integer then by definition you need to lose the
fraction at some point. You can round by adding before the s
F.J. wrote:
> If you care about the decimal, bite the bullet and go floating
> point.
> Mixing floating operations and integers
> are often not good (casting being only one penalty).
Ever hear of fixed point? :)
More accurate than floating point (in the confidence in values, not in
giving a milli
You do get the remainder, but I fail to see how that helps :-)
Phill
___
Xmame mailing list
[EMAIL PROTECTED]
http://toybox.twisted.org.uk/mailman/listinfo/xmame
If I'm not mistaken--and it's been awhile since I wrote X86
assembly--the old-school X86 integer divide instruction returns
both an integer result in one register and a remainder in
another. (Of course this means 2 registers taken up, and X86
obviously lacks registers, so you end up using MOV to c
> The question is do you care about any decimal you lose in the
> process? e.g. 3 / 2 == 1 ?
> 11 shifted right becomes 01 and you lost the extra "half".
If the result you need is an integer then by definition you need to lose the
fraction at some point. You can round by adding before the shift:
Better yet, if a is an integer and you want half of it, just
shift it right one bit. That's effectively what your option #2
below does, and if you're lucky maybe gcc will optimize the
output as such since it would cut the number of ops in half.
Best not to place *that* much faith in compilers, th
> > ...ever come across a processor called a transputer ? only processor
> > I ever saw with faster floating point than integers...
>
>Hum that's plain wrong: current architectures are more efficient
> at most FP computations, especially multiplication. This has become
Might be true now, but
> > My money's on the latter. For a general purpose CPU, integers are
usually
> > much simpler to compute than floating-point. But IANA software engineer
>
> ...ever come across a processor called a transputer ? only processor
> I ever saw with faster floating point than integers...
Hum that's
> My money's on the latter. For a general purpose CPU, integers are usually
> much simpler to compute than floating-point. But IANA software engineer
...ever come across a processor called a transputer ? only processor
I ever saw with faster floating point than integers...
-bat.
On Friday 24 October 2003 22:17, Frank Cox wrote:
> For the definitive answer, put each into a loop structure and loop it a
> few hundred million times. Check the elapsed time after each loop has
> completed.
Yeah, I should have done that immediately. :) The answer btw is that the 2nd
option is
On Fri, 24 Oct 2003 22:01:26 +0200
Pieter Hulshoff <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> What in general creates faster code:
> y = 0.500*a;
> or
> y = (512*a) >> 10;
> ?
For the definitive answer, put each into a loop structure and loop it a
few hundred million times. Check the elapsed t
My money's on the latter. For a general purpose CPU, integers are usually
much simpler to compute than floating-point. But IANA software engineer
(yet).
> Hello all,
>
> What in general creates faster code:
> y = 0.500*a;
> or
> y = (512*a) >> 10;
> ?
>
> Regards,
>
> Pieter Hulshoff
>
_
Hello all,
What in general creates faster code:
y = 0.500*a;
or
y = (512*a) >> 10;
?
Regards,
Pieter Hulshoff
___
Xmame mailing list
[EMAIL PROTECTED]
http://toybox.twisted.org.uk/mailman/listinfo/xmame
23 matches
Mail list logo
