is there some ?
people seem tend to use

inline float sign (float x) { return (x > 0) - (x < 0); }

but im not sure if it is efficient
afaik float standard says that sign bit is the highest bit ot 32bit
representation so maybe something based on this?

but what exactly?

fir <profesor.fir@gmail.com> writes:

> is there some ?
> people seem tend to use
>
> inline float sign (float x) { return (x > 0) - (x < 0); }

Standard C has copysign. A call to your sign(f) function is equivalent
to copysign(1, f).

There is also a standard signbit macro that returns 0/1 depending on the
sign of the argument. These two treat NaNs differently.

--
Ben.

środa, 25 maja 2022 o 12:45:50 UTC+2 Ben napisał(a):
> fir <profes...@gmail.com> writes:
>
> > is there some ?
> > people seem tend to use
> >
> > inline float sign (float x) { return (x > 0) - (x < 0); }
> Standard C has copysign. A call to your sign(f) function is equivalent
> to copysign(1, f).
>
> There is also a standard signbit macro that returns 0/1 depending on the
> sign of the argument. These two treat NaNs differently.
>
ok i will see, though it would be better tho have normal functions to not add/multiply
not quite necessary references

środa, 25 maja 2022 o 13:47:13 UTC+2 fir napisał(a):
> środa, 25 maja 2022 o 12:45:50 UTC+2 Ben napisał(a):
> > fir <profes...@gmail.com> writes:
> >
> > > is there some ?
> > > people seem tend to use
> > >
> > > inline float sign (float x) { return (x > 0) - (x < 0); }
> > Standard C has copysign. A call to your sign(f) function is equivalent
> > to copysign(1, f).
> >
> > There is also a standard signbit macro that returns 0/1 depending on the
> > sign of the argument. These two treat NaNs differently.
> >
> ok i will see, though it would be better tho have normal functions to not add/multiply
> not quite necessary references

return -2*signbit(x)+1 ;
seem to wrok, though i not tested it except one case

środa, 25 maja 2022 o 14:07:22 UTC+2 fir napisał(a):
> środa, 25 maja 2022 o 13:47:13 UTC+2 fir napisał(a):
> > środa, 25 maja 2022 o 12:45:50 UTC+2 Ben napisał(a):
> > > fir <profes...@gmail.com> writes:
> > >
> > > > is there some ?
> > > > people seem tend to use
> > > >
> > > > inline float sign (float x) { return (x > 0) - (x < 0); }
> > > Standard C has copysign. A call to your sign(f) function is equivalent
> > > to copysign(1, f).
> > >
> > > There is also a standard signbit macro that returns 0/1 depending on the
> > > sign of the argument. These two treat NaNs differently.
> > >
> > ok i will see, though it would be better tho have normal functions to not add/multiply
> > not quite necessary references
> return -2*signbit(x)+1 ;
> seem to wrok, though i not tested it except one case

inline float sign2(float x)
{ return -2*signbit(x)+1 ;
}

inline float sign1(float x)
{ return (x>0)-(x<0);
}

for(float f= -333333.33; f< 333333.3; f+=0.33)
sum += sign2(f);

i tested the efficiency and there is no visible difference here though (about 10 ms each, but i run on quite old machine)

środa, 25 maja 2022 o 14:25:30 UTC+2 fir napisał(a):
> środa, 25 maja 2022 o 14:07:22 UTC+2 fir napisał(a):
> > środa, 25 maja 2022 o 13:47:13 UTC+2 fir napisał(a):
> > > środa, 25 maja 2022 o 12:45:50 UTC+2 Ben napisał(a):
> > > > fir <profes...@gmail.com> writes:
> > > >
> > > > > is there some ?
> > > > > people seem tend to use
> > > > >
> > > > > inline float sign (float x) { return (x > 0) - (x < 0); }
> > > > Standard C has copysign. A call to your sign(f) function is equivalent
> > > > to copysign(1, f).
> > > >
> > > > There is also a standard signbit macro that returns 0/1 depending on the
> > > > sign of the argument. These two treat NaNs differently.
> > > >
> > > ok i will see, though it would be better tho have normal functions to not add/multiply
> > > not quite necessary references
> > return -2*signbit(x)+1 ;
> > seem to wrok, though i not tested it except one case
> inline float sign2(float x)
> {
> return -2*signbit(x)+1 ;
> }
>
> inline float sign1(float x)
> {
> return (x>0)-(x<0);
> }
>
> for(float f= -333333.33; f< 333333.3; f+=0.33)
> sum += sign2(f);
>
> i tested the efficiency and there is no visible difference here though (about 10 ms each, but i run on quite old machine)

not to say its -2*signbit(x)+1 is not all i woulkd beed as it returns +1 for zero...but if i see no difference i may left he < > version though it looks weird imo

fir <profesor.fir@gmail.com> writes:

> środa, 25 maja 2022 o 14:07:22 UTC+2 fir napisał(a):
>> środa, 25 maja 2022 o 13:47:13 UTC+2 fir napisał(a):
>> > środa, 25 maja 2022 o 12:45:50 UTC+2 Ben napisał(a):
>> > > fir <profes...@gmail.com> writes:
>> > >
>> > > > is there some ?
>> > > > people seem tend to use
>> > > >
>> > > > inline float sign (float x) { return (x > 0) - (x < 0); }
>> > > Standard C has copysign. A call to your sign(f) function is equivalent
>> > > to copysign(1, f).
>> > >
>> > > There is also a standard signbit macro that returns 0/1 depending on the
>> > > sign of the argument. These two treat NaNs differently.
>> > >
>> > ok i will see, though it would be better tho have normal functions to not add/multiply
>> > not quite necessary references
>> return -2*signbit(x)+1 ;
>> seem to wrok, though i not tested it except one case
>
> inline float sign2(float x)
> {
> return -2*signbit(x)+1 ;
> }
>
> inline float sign1(float x)
> {
> return (x>0)-(x<0);
> }
>
> for(float f= -333333.33; f< 333333.3; f+=0.33)
> sum += sign2(f);
>
> i tested the efficiency and there is no visible difference here though
> (about 10 ms each, but i run on quite old machine)

gcc, with -O2, generates shorter code for the one you didn't try:

copysignf(1, x)

That does not mean it's faster, but gcc probably has a reason to do what
it does.

Also, in many cases, it's copysign[fl]? that you want, but with
something other than 1 as the first argument.

--
Ben.

Ben <ben.usenet@bsb.me.uk> writes:

> fir <profesor.fir@gmail.com> writes:
>
>> is there some ?
>> people seem tend to use
>>
>> inline float sign (float x) { return (x > 0) - (x < 0); }
>
> Standard C has copysign. A call to your sign(f) function is equivalent
> to copysign(1, f).

The output doesn't match when the input is 0.

środa, 25 maja 2022 o 15:07:22 UTC+2 Ben napisał(a):
> fir <profes...@gmail.com> writes:
>
> > środa, 25 maja 2022 o 14:07:22 UTC+2 fir napisał(a):
> >> środa, 25 maja 2022 o 13:47:13 UTC+2 fir napisał(a):
> >> > środa, 25 maja 2022 o 12:45:50 UTC+2 Ben napisał(a):
> >> > > fir <profes...@gmail.com> writes:
> >> > >
> >> > > > is there some ?
> >> > > > people seem tend to use
> >> > > >
> >> > > > inline float sign (float x) { return (x > 0) - (x < 0); }
> >> > > Standard C has copysign. A call to your sign(f) function is equivalent
> >> > > to copysign(1, f).
> >> > >
> >> > > There is also a standard signbit macro that returns 0/1 depending on the
> >> > > sign of the argument. These two treat NaNs differently.
> >> > >
> >> > ok i will see, though it would be better tho have normal functions to not add/multiply
> >> > not quite necessary references
> >> return -2*signbit(x)+1 ;
> >> seem to wrok, though i not tested it except one case
> >
> > inline float sign2(float x)
> > {
> > return -2*signbit(x)+1 ;
> > }
> >
> > inline float sign1(float x)
> > {
> > return (x>0)-(x<0);
> > }
> >
> > for(float f= -333333.33; f< 333333.3; f+=0.33)
> > sum += sign2(f);
> >
> > i tested the efficiency and there is no visible difference here though
> > (about 10 ms each, but i run on quite old machine)
> gcc, with -O2, generates shorter code for the one you didn't try:
>
> copysignf(1, x)
>
> That does not mean it's faster, but gcc probably has a reason to do what
> it does.
>
> Also, in many cases, it's copysign[fl]? that you want, but with
> something other than 1 as the first argument.
>
thet copysigfn also roughly the same, maybe 5-10% faster but im not sure and have a terible headache today and cant test it too much
initially i tgought this < > version would be much slower (as ifs are slow) but if there is not such big difference the questiob is less important

środa, 25 maja 2022 o 15:16:23 UTC+2 Tim Rentsch napisał(a):
> Ben <ben.u...@bsb.me.uk> writes:
>
> > fir <profes...@gmail.com> writes:
> >
> >> is there some ?
> >> people seem tend to use
> >>
> >> inline float sign (float x) { return (x > 0) - (x < 0); }
> >
> > Standard C has copysign. A call to your sign(f) function is equivalent
> > to copysign(1, f).
> The output doesn't match when the input is 0.

thats right and this extended could be needed
hovever in my case it seem not so much

i need this sign when 'resolving' (adding) some force in a link (join?) agains 2 balls (dots) in 3d
space, say joint assumed distance is 100 when real distance is 110 or 95 then i need to applay force
like -10*10 or +5*5 (square probably best) thus i need a sign

void ResolveLinkForce_(int n, int i, float link_dist)
{ float Mi = dot3d[i].mass;
float dx = dot3d[i].x - dot3d[n].x;
float dy = dot3d[i].y - dot3d[n].y;
float dz = dot3d[i].z - dot3d[n].z;

float d = sqrt(dx*dx + dy*dy + dz*dz);
float dd = (d - link_dist);
float p = -sign(dd)*dd*dd* joint_hardness;

float px = (dx/d)*p;
float py = (dy/d)*p;
float pz = (dz/d)*p;
dot3d[i].vx += px/Mi;
dot3d[i].vy += py/Mi;
dot3d[i].vz += pz/Mi;

}
in case of dd being 0 its all zero so sign dont matter

or maybe i may simplify it at all ?

środa, 25 maja 2022 o 16:25:48 UTC+2 fir napisał(a):
> środa, 25 maja 2022 o 15:16:23 UTC+2 Tim Rentsch napisał(a):
> > Ben <ben.u...@bsb.me.uk> writes:
> >
> > > fir <profes...@gmail.com> writes:
> > >
> > >> is there some ?
> > >> people seem tend to use
> > >>
> > >> inline float sign (float x) { return (x > 0) - (x < 0); }
> > >
> > > Standard C has copysign. A call to your sign(f) function is equivalent
> > > to copysign(1, f).
> > The output doesn't match when the input is 0.
> thats right and this extended could be needed
> hovever in my case it seem not so much
>
> i need this sign when 'resolving' (adding) some force in a link (join?) agains 2 balls (dots) in 3d
> space, say joint assumed distance is 100 when real distance is 110 or 95 then i need to applay force
> like -10*10 or +5*5 (square probably best) thus i need a sign
>
> void ResolveLinkForce_(int n, int i, float link_dist)
> {
> float Mi = dot3d[i].mass;
> float dx = dot3d[i].x - dot3d[n].x;
> float dy = dot3d[i].y - dot3d[n].y;
> float dz = dot3d[i].z - dot3d[n].z;
>
> float d = sqrt(dx*dx + dy*dy + dz*dz);
> float dd = (d - link_dist);
> float p = -sign(dd)*dd*dd* joint_hardness;
>
> float px = (dx/d)*p;
> float py = (dy/d)*p;
> float pz = (dz/d)*p;
> dot3d[i].vx += px/Mi;
> dot3d[i].vy += py/Mi;
> dot3d[i].vz += pz/Mi;
>
> }
> in case of dd being 0 its all zero so sign dont matter
>
> or maybe i may simplify it at all ?

note btw it works curiously well i mean when i get together some things with this dots keeped togehthet by this joints i may fire a dot in it and it will behave realistically (or semi realistically i mean have angular momentum and various complex moves - and this is all done by like 10-20 lines of code (when skipping the non core ones) there are hovever 2 or 3 problems (one is it is square, i eman joints itself are linear but the colisions are square and it slows down, well known problem) (second problem is it disalows fast moves i mean when ball moves the force of collision is square proportional to depth of penetration of ball in ball (at least i use it square, not sure if other are eually good or definietely worse) in fact the colision routine is liek the above except i dont need the sign .. hovever simply if a ball moves to fast it may just teleport thru the obstacles and to have reasonebly fast nice to looking balls but not very fast ones just reasoneble/medicore i need a speed like +100 per frame (at 50 fps) when bal sizes are like typically of 50 or 100 - this makes i need to put like at least 5 or better 10 physical frames instead of one just to make taht speed of movement of objevts down to 10 form 100 just not to tunel through

thisrd problem is sometimes when hit to much all that link build small figure of dots 'explode' - probably
the link distance between dots began to much, the force generated is in turn too much and it explodes, and i dont know what happens but maybe positions goes to nans or infs (the rest of this ball sets continue to work ok, but eventually everything may explode)

doeas maybe someone know is there some simple addition to this link routine above stoping this explosions?

środa, 25 maja 2022 o 16:57:07 UTC+2 fir napisał(a):
> środa, 25 maja 2022 o 16:25:48 UTC+2 fir napisał(a):
> > środa, 25 maja 2022 o 15:16:23 UTC+2 Tim Rentsch napisał(a):
> > > Ben <ben.u...@bsb.me.uk> writes:
> > >
> > > > fir <profes...@gmail.com> writes:
> > > >
> > > >> is there some ?
> > > >> people seem tend to use
> > > >>
> > > >> inline float sign (float x) { return (x > 0) - (x < 0); }
> > > >
> > > > Standard C has copysign. A call to your sign(f) function is equivalent
> > > > to copysign(1, f).
> > > The output doesn't match when the input is 0.
> > thats right and this extended could be needed
> > hovever in my case it seem not so much
> >
> > i need this sign when 'resolving' (adding) some force in a link (join?) agains 2 balls (dots) in 3d
> > space, say joint assumed distance is 100 when real distance is 110 or 95 then i need to applay force
> > like -10*10 or +5*5 (square probably best) thus i need a sign
> >
> > void ResolveLinkForce_(int n, int i, float link_dist)
> > {
> > float Mi = dot3d[i].mass;
> > float dx = dot3d[i].x - dot3d[n].x;
> > float dy = dot3d[i].y - dot3d[n].y;
> > float dz = dot3d[i].z - dot3d[n].z;
> >
> > float d = sqrt(dx*dx + dy*dy + dz*dz);
> > float dd = (d - link_dist);
> > float p = -sign(dd)*dd*dd* joint_hardness;
> >
> > float px = (dx/d)*p;
> > float py = (dy/d)*p;
> > float pz = (dz/d)*p;
> > dot3d[i].vx += px/Mi;
> > dot3d[i].vy += py/Mi;
> > dot3d[i].vz += pz/Mi;
> >
> > }
> > in case of dd being 0 its all zero so sign dont matter
> >
> > or maybe i may simplify it at all ?
> note btw it works curiously well i mean when i get together some things with this dots keeped togehthet by this joints i may fire a dot in it and it will behave realistically (or semi realistically i mean have angular momentum and various complex moves - and this is all done by like 10-20 lines of code (when skipping the non core ones) there are hovever 2 or 3 problems (one is it is square, i eman joints itself are linear but the colisions are square and it slows down, well known problem) (second problem is it disalows fast moves i mean when ball moves the force of collision is square proportional to depth of penetration of ball in ball (at least i use it square, not sure if other are eually good or definietely worse) in fact the colision routine is liek the above except i dont need the sign .. hovever simply if a ball moves to fast it may just teleport thru the obstacles and to have reasonebly fast nice to looking balls but not very fast ones just reasoneble/medicore i need a speed like +100 per frame (at 50 fps) when bal sizes are like typically of 50 or 100 - this makes i need to put like at least 5 or better 10 physical frames instead of one just to make taht speed of movement of objevts down to 10 form 100 just not to tunel through
>
> thisrd problem is sometimes when hit to much all that link build small figure of dots 'explode' - probably
> the link distance between dots began to much, the force generated is in turn too much and it explodes, and i dont know what happens but maybe positions goes to nans or infs (the rest of this ball sets continue to work ok, but eventually everything may explode)
>
> doeas maybe someone know is there some simple addition to this link routine above stoping this explosions?

soem may seen a demo of this problem

http://filesharing24.com/d/Oen

this demo dont seem to much good but may ilustrate the problem (in dempo press 5,6,7,8,9, 0
to fire dots into linked dots and some eventually will explode, may also pres f9 tu turn some gravity on and then most of them explode

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Ben <ben.usenet@bsb.me.uk> writes:
>
>> fir <profesor.fir@gmail.com> writes:
>>
>>> is there some ?
>>> people seem tend to use
>>>
>>> inline float sign (float x) { return (x > 0) - (x < 0); }
>>
>> Standard C has copysign. A call to your sign(f) function is equivalent
>> to copysign(1, f).
>
> The output doesn't match when the input is 0.

Ah, true.

--
Ben.

środa, 25 maja 2022 o 17:32:14 UTC+2 fir napisał(a):
>
> this demo dont seem to much good but may ilustrate the problem (in dempo press 5,6,7,8,9, 0
> to fire dots into linked dots and some eventually will explode, may also pres f9 tu turn some gravity on and then most of them explode

this is very simple simulation (seems most simplest that can be) but im usually interested in some
kind of fundaments in such things..still a bit pity processors are so slow and things began to choke
quite early at lieas when using native methods...such simulation is hovever totally adequate to paralisation in turn as you say you got 1 milion dots with pos and v and only need to produce same 1 milion dots with pos and v when order atc totally dont matter

hovever it seems i got no time to toy with that

środa, 25 maja 2022 o 15:19:20 UTC+2 fir napisał(a):
> środa, 25 maja 2022 o 15:07:22 UTC+2 Ben napisał(a):
> > fir <profes...@gmail.com> writes:
> >
> > > środa, 25 maja 2022 o 14:07:22 UTC+2 fir napisał(a):
> > >> środa, 25 maja 2022 o 13:47:13 UTC+2 fir napisał(a):
> > >> > środa, 25 maja 2022 o 12:45:50 UTC+2 Ben napisał(a):
> > >> > > fir <profes...@gmail.com> writes:
> > >> > >
> > >> > > > is there some ?
> > >> > > > people seem tend to use
> > >> > > >
> > >> > > > inline float sign (float x) { return (x > 0) - (x < 0); }
> > >> > > Standard C has copysign. A call to your sign(f) function is equivalent
> > >> > > to copysign(1, f).
> > >> > >
> > >> > > There is also a standard signbit macro that returns 0/1 depending on the
> > >> > > sign of the argument. These two treat NaNs differently.
> > >> > >
> > >> > ok i will see, though it would be better tho have normal functions to not add/multiply
> > >> > not quite necessary references
> > >> return -2*signbit(x)+1 ;
> > >> seem to wrok, though i not tested it except one case
> > >
> > > inline float sign2(float x)
> > > {
> > > return -2*signbit(x)+1 ;
> > > }
> > >
> > > inline float sign1(float x)
> > > {
> > > return (x>0)-(x<0);
> > > }
> > >
> > > for(float f= -333333.33; f< 333333.3; f+=0.33)
> > > sum += sign2(f);
> > >
> > > i tested the efficiency and there is no visible difference here though
> > > (about 10 ms each, but i run on quite old machine)
> > gcc, with -O2, generates shorter code for the one you didn't try:
> >
> > copysignf(1, x)
> >
> > That does not mean it's faster, but gcc probably has a reason to do what
> > it does.
> >
> > Also, in many cases, it's copysign[fl]? that you want, but with
> > something other than 1 as the first argument.
> >
> thet copysigfn also roughly the same, maybe 5-10% faster but im not sure and have a terible headache today and cant test it too much
> initially i tgought this < > version would be much slower (as ifs are slow) but if there is not such big difference the questiob is less important

ovaralli i would say 5ns/15 cycles for this it is +=0.33, sum+=sign2(f), check if f<333333.3 is not so bad
but also not a aterribly quick (imo such sole sign could be someting like 3 cycles or so)
but hell knows which it is this if in loop or what

lat time when i checked it it was quite long time ago the ifs was quite slow and it seem to me that
processors would definitively need soem asm opcodes that would do kinda of local ifs without ifs
but being small set of oparatiobs able to be combined to make more complex tasks (like various
arithmetic without real ifs)

meybe in a word where memory bandwith is main limit it doesnt matter so much but still 1-core
strightforward peograming is so nice that any able optimisation would be wery much welcome by me

what could be such ifless operations? i dont know maybe something like this old asm opcodes liek adc using falgs set to do somethink or do not or do soemething other, there those flags works liek ifs

it also eventually could be probably some opcodes that may combine some test and operation in one opcode

On 5/25/2022 3:09 AM, fir wrote:
> is there some ?
> people seem tend to use
>
> inline float sign (float x) { return (x > 0) - (x < 0); }
>
> but im not sure if it is efficient
> afaik float standard says that sign bit is the highest bit ot 32bit
> representation so maybe something based on this?

I presume that your "float standard" is IEEE754, which is not a part of
C standard, but anyway...

The important part of the rationale behind IEEE754 floating-point
representation was the fact that for ordering comparison purposes
floating-point numbers could be type-punned as equally-sized signed
integers and compared as signed integers. This allowed "weak" hardware
(i.e. slow/emulated FP support) to perform plain FP comparisons without
having to invoke anything FP-related at all. (Of course, one had to make
sure one's happy with what happened to such special values as negative
zeroes.)

So, in your case this means that you can type-pun-hack the original FP
problem into an integer problem. Now you can start a topic titled
"eficient int sign routine".

--
Best regards,
Andrey

On 5/27/22 9:17 PM, Andrey Tarasevich wrote:
> On 5/25/2022 3:09 AM, fir wrote:
>> is there some ?
>> people seem tend to use
>>
>> inline float sign (float x) {  return (x > 0) - (x < 0); }
>>
>> but im not sure if it is efficient
>> afaik float standard says that sign bit is the highest bit ot 32bit
>> representation so maybe something based on this?
>
> I presume that your "float standard" is IEEE754, which is not a part of
> C standard, but anyway...
>
> The important part of the rationale behind IEEE754 floating-point
> representation was the fact that for ordering comparison purposes
> floating-point numbers could be type-punned as equally-sized signed
> integers and compared as signed integers. This allowed "weak" hardware
> (i.e. slow/emulated FP support) to perform plain FP comparisons without
> having to invoke anything FP-related at all. (Of course, one had to make
> sure one's happy with what happened to such special values as negative
> zeroes.)
>
> So, in your case this means that you can type-pun-hack the original FP
> problem into an integer problem. Now you can start a topic titled
> "eficient int sign routine".
>

I thought floating point was stored as signed-magnitude, so you can't
just compare as signed integers, but the comparison was still pretty
quick, you first compare signs, and only if same did you compare
magnatude, but the fields were sorted to make the magnitude comparison
just work.

On 5/27/2022 7:03 PM, Richard Damon wrote:
> On 5/27/22 9:17 PM, Andrey Tarasevich wrote:
>> On 5/25/2022 3:09 AM, fir wrote:
>>> is there some ?
>>> people seem tend to use
>>>
>>> inline float sign (float x) {  return (x > 0) - (x < 0); }
>>>
>>> but im not sure if it is efficient
>>> afaik float standard says that sign bit is the highest bit ot 32bit
>>> representation so maybe something based on this?
>>
>> I presume that your "float standard" is IEEE754, which is not a part
>> of C standard, but anyway...
>>
>> The important part of the rationale behind IEEE754 floating-point
>> representation was the fact that for ordering comparison purposes
>> floating-point numbers could be type-punned as equally-sized signed
>> integers and compared as signed integers. This allowed "weak" hardware
>> (i.e. slow/emulated FP support) to perform plain FP comparisons
>> without having to invoke anything FP-related at all. (Of course, one
>> had to make sure one's happy with what happened to such special values
>> as negative zeroes.)
>>
>> So, in your case this means that you can type-pun-hack the original FP
>> problem into an integer problem. Now you can start a topic titled
>> "eficient int sign routine".
>>
>
> I thought floating point was stored as signed-magnitude, so you can't
> just compare as signed integers, but the comparison was still pretty
> quick, you first compare signs, and only if same did you compare
> magnatude, but the fields were sorted to make the magnitude comparison
> just work.

You are right. They have to be type-punned as signed magnitude
specifically in order to be compared as integers.

--
Best regards,
Andrey

sobota, 28 maja 2022 o 03:17:34 UTC+2 Andrey Tarasevich napisał(a):
> On 5/25/2022 3:09 AM, fir wrote:
> > is there some ?
> > people seem tend to use
> >
> > inline float sign (float x) { return (x > 0) - (x < 0); }
> >
> > but im not sure if it is efficient
> > afaik float standard says that sign bit is the highest bit ot 32bit
> > representation so maybe something based on this?
> I presume that your "float standard" is IEEE754, which is not a part of
> C standard, but anyway...
>
> The important part of the rationale behind IEEE754 floating-point
> representation was the fact that for ordering comparison purposes
> floating-point numbers could be type-punned as equally-sized signed
> integers and compared as signed integers. This allowed "weak" hardware
> (i.e. slow/emulated FP support) to perform plain FP comparisons without
> having to invoke anything FP-related at all. (Of course, one had to make
> sure one's happy with what happened to such special values as negative
> zeroes.)
>
> So, in your case this means that you can type-pun-hack the original FP
> problem into an integer problem. Now you can start a topic titled
> "eficient int sign routine".
>

people shpul;d trop they thinking that c is only what is defined in standard,
c is what people use not of what only is defined by 'standard'

i think much can be done by using float binary representation which in turn
is not hard, kinda weird they dont used 24 bits on lower 'integer' part (it would make round 3 bytes
then) im not shure also if that shift of 'dot' part is done right

1 is for example 00111111100000000000000000000000
2 is 01000000000000000000000000000000
4 is 01000000100000000000000000000000
(according to https://www.h-schmidt.net/FloatConverter/IEEE754.html )

as powers of 2 are always in fo rm 100.......0 and the first 1 is not stored shouldnt 4
be [2][0] (when first is exponent part and second are integer bits) ?
i think also this sign moved to highest bite is not necessary best idea it
could be better just have 3 bytes for integer (including its sign) and 1 byte for 'exponent'

hovever in fact, this sign not necesarrely need to be in this integer part as the highest bit is already skipped to simple copying will not recreate the oryginal integer

hovever i think probbaly this float should be done like this that 3 bytes would be identical as
normal 3 bytes of integer so zero should be 00000000 00000000 0000000 and 1 shopuld be 00000000 00000000 00000001 minus one should be 11111111 11111111 11111111 as to exponent part i dont know but probably should denote zeros/ones added lefot or right or something

this problem needs to be rethinked though,m though my brain like lost interestmen in that things which used to vitally interest me back days, its curious

sobota, 28 maja 2022 o 07:06:49 UTC+2 fir napisał(a):
> sobota, 28 maja 2022 o 03:17:34 UTC+2 Andrey Tarasevich napisał(a):
> > On 5/25/2022 3:09 AM, fir wrote:
> > > is there some ?
> > > people seem tend to use
> > >
> > > inline float sign (float x) { return (x > 0) - (x < 0); }
> > >
> > > but im not sure if it is efficient
> > > afaik float standard says that sign bit is the highest bit ot 32bit
> > > representation so maybe something based on this?
> > I presume that your "float standard" is IEEE754, which is not a part of
> > C standard, but anyway...
> >
> > The important part of the rationale behind IEEE754 floating-point
> > representation was the fact that for ordering comparison purposes
> > floating-point numbers could be type-punned as equally-sized signed
> > integers and compared as signed integers. This allowed "weak" hardware
> > (i.e. slow/emulated FP support) to perform plain FP comparisons without
> > having to invoke anything FP-related at all. (Of course, one had to make
> > sure one's happy with what happened to such special values as negative
> > zeroes.)
> >
> > So, in your case this means that you can type-pun-hack the original FP
> > problem into an integer problem. Now you can start a topic titled
> > "eficient int sign routine".
> >
> people shpul;d trop they thinking that c is only what is defined in standard,
> c is what people use not of what only is defined by 'standard'
>
> i think much can be done by using float binary representation which in turn
> is not hard, kinda weird they dont used 24 bits on lower 'integer' part (it would make round 3 bytes
> then) im not shure also if that shift of 'dot' part is done right
>
> 1 is for example 00111111100000000000000000000000
> 2 is 01000000000000000000000000000000
> 4 is 01000000100000000000000000000000
> (according to https://www.h-schmidt.net/FloatConverter/IEEE754.html )
>
> as powers of 2 are always in fo rm 100.......0 and the first 1 is not stored shouldnt 4
> be [2][0] (when first is exponent part and second are integer bits) ?
> i think also this sign moved to highest bite is not necessary best idea it
> could be better just have 3 bytes for integer (including its sign) and 1 byte for 'exponent'
>
> hovever in fact, this sign not necesarrely need to be in this integer part as the highest bit is already skipped to simple copying will not recreate the oryginal integer
>
> hovever i think probbaly this float should be done like this that 3 bytes would be identical as
> normal 3 bytes of integer so zero should be 00000000 00000000 0000000 and 1 shopuld be 00000000 00000000 00000001 minus one should be 11111111 11111111 11111111 as to exponent part i dont know but probably should denote zeros/ones added lefot or right or something
>
> this problem needs to be rethinked though,m though my brain like lost interestmen in that things which used to vitally interest me back days, its curious

maybe it should be like that 3 bytes are exact integer, teh exponened should say how many xxxx
add on right ond on left like integerxxxxxxxx. and .xxxxxxinteger though im not sure/probably in case
on negative integer xxxx should be not zeros but ones, im not sure though (and not sure if i like U2 at all)

In a superior language:

#include <cstdint>
#include <cstring>
#include <limits>
#include <concepts>
#include <type_traits>

template<typename FpType>
requires (std::same_as<FpType, float> || std::same_as<FpType, double>)
&& std::numeric_limits<FpType>::is_iec559
std::conditional_t<std::same_as<FpType, float>, std::int32_t,
std::int64_t> giveSign( FpType value )
{ using namespace std;
conditional_t<std::same_as<FpType, float>, int32_t, int64_t> iValue;
memcpy( &iValue, &value, sizeof value );
return iValue;
}

template
std::int32_t giveSign( float );

template
std::int64_t giveSign( double );

Gives:

"??$giveSign@M@@YAHM@Z":
movd eax, xmm0
ret

"??$giveSign@N@@YA_JN@Z":
movq rax, xmm0
ret

Sorry, litle mistake:

#include <cstdint>
#include <cstring>
#include <limits>
#include <concepts>
#include <type_traits>

template<typename FpType>
requires (std::same_as<FpType, float> || std::same_as<FpType, double>)
&& std::numeric_limits<FpType>::is_iec559
int giveSign( FpType value )
{ using namespace std;
conditional_t<same_as<FpType, float>, int32_t, int64_t> iValue;
memcpy( &iValue, &value, sizeof value );
return (iValue > 0) - (iValue < 0);
}

template
int giveSign( float );

template
int giveSign( double );

Gives:

"??$giveSign@M@@YAHM@Z":
movd eax, xmm0
xor ecx, ecx
test eax, eax
setg cl
sar eax, 31
add eax, ecx
ret

"??$giveSign@N@@YAHN@Z":
movq rax, xmm0
xor ecx, ecx
test rax, rax
setg cl
sar rax, 63
add eax, ecx

Compiler: clang-cl 13.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>In a superior language:
>
>#include <cstdint>
>#include <cstring>
>#include <limits>
>#include <concepts>
>#include <type_traits>
>
>template<typename FpType>
> requires (std::same_as<FpType, float> || std::same_as<FpType, double>)
>&& std::numeric_limits<FpType>::is_iec559
>std::conditional_t<std::same_as<FpType, float>, std::int32_t,
>std::int64_t> giveSign( FpType value )
>{
> using namespace std;
> conditional_t<std::same_as<FpType, float>, int32_t, int64_t> iValue;
> memcpy( &iValue, &value, sizeof value );
> return iValue;
>}
>
>template
>std::int32_t giveSign( float );
>
>
>template
>std::int64_t giveSign( double );

In an even more superior language.

#include <math.h>

int main()
{ float_t number = -1.235;

sign = signbit(number);
return sign;
}

On 5/28/2022 9:43 PM, Scott Lurndal wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> In a superior language:
>>
>> #include <cstdint>
>> #include <cstring>
>> #include <limits>
>> #include <concepts>
>> #include <type_traits>
>>
>> template<typename FpType>
>> requires (std::same_as<FpType, float> || std::same_as<FpType, double>)
>> && std::numeric_limits<FpType>::is_iec559
>> std::conditional_t<std::same_as<FpType, float>, std::int32_t,
>> std::int64_t> giveSign( FpType value )
>> {
>> using namespace std;
>> conditional_t<std::same_as<FpType, float>, int32_t, int64_t> iValue;
>> memcpy( &iValue, &value, sizeof value );
>> return iValue;
>> }
>>
>> template
>> std::int32_t giveSign( float );
>>
>>
>> template
>> std::int64_t giveSign( double );
>
> In an even more superior language.

Agreed with the "even superior" part, at least in this case.

>
> #include <math.h>
>
> int main()
> {
> float_t number = -1.235;
>
> // sign = signbit(number);

int sign = signbit(number);

> return sign;
> }

Manfred <noname@add.invalid> writes:

> On 5/28/2022 9:43 PM, Scott Lurndal wrote:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> In a superior language:
>>>
>>> #include <cstdint>
>>> #include <cstring>
>>> #include <limits>
>>> #include <concepts>
>>> #include <type_traits>
>>>
>>> template<typename FpType>
>>> requires (std::same_as<FpType, float> || std::same_as<FpType, double>)
>>> && std::numeric_limits<FpType>::is_iec559
>>> std::conditional_t<std::same_as<FpType, float>, std::int32_t,
>>> std::int64_t> giveSign( FpType value )
>>> {
>>> using namespace std;
>>> conditional_t<std::same_as<FpType, float>, int32_t, int64_t> iValue;
>>> memcpy( &iValue, &value, sizeof value );
>>> return iValue;
>>> }
>>>
>>> template
>>> std::int32_t giveSign( float );
>>>
>>>
>>> template
>>> std::int64_t giveSign( double );
>> In an even more superior language.
>
> Agreed with the "even superior" part, at least in this case.

Although C++ also has the signbit functions.

>> #include <math.h>
>> int main()
>> {
>> float_t number = -1.235;
>> // sign = signbit(number);
>
> int sign = signbit(number);

Yes, missing type but also

int sign = signbitf(number);

if likely to be what's wanted, even though float_t is not a standard
type. Anyway, the point stands that simpler solutions are often
preferable.

>> return sign;
>> }

--
Ben.