niedziela, 29 maja 2022 o 13:05:30 UTC+2 fir napisał(a):
> niedziela, 29 maja 2022 o 12:57:48 UTC+2 fir napisał(a):
> > niedziela, 29 maja 2022 o 12:08:21 UTC+2 fir napisał(a):
> > >
> > > like:
> > > x = sign(d)*d*d
> > >
> >
> > in fact fabs could go here and i do some tests
> >
> > void RunFrame(int advance)
> > {
> > ClearFrameData(0x505077);
> > sum = 0;
> > for(float f= -333333.33; f< 333333.3; f+=0.111)
> > // sum = -copysignf(1,f)*f*f; //26 ms //29 ms
> > sum = -fabs(f)*f; //26 ms //34 ms
> >
> > DrawSomeText2(0xff0000, 10 , 30, "aaaa %f", sum);
> > }
> >
> > i test it pitting some dosed in frame ofthe game as my little library has a built in plot
> > showing frame times so i may see olways live what my game changes effect on frame times
> >
> > i tested it on gcc 5 and gcc 10 - i more use gcc5 for some reason i dont remember which one
> > maybe it compiles faster or maybe becouse another reasons (various version of compilers sometimes
> > compiel some things better and some other worse so its the best to have couple and test them all
> > from time to time)
> >
> > some may also test it of have windows, only need to have mingw/tdm installed and put path to in tn compile.vat first line
> >
> > http://filesharing24.com/d/Ofo
> btw if some would like test it when runing it press f4 and hold, it sets sleep in the loop to zero so only there the value is real (sleep is added to not make cpu work on full load, and teh counter counts difference in time including all round (including sleep) but in case of testing one want to sleep zero to see minimal frame time)

forgot to mention to show a plot one ned to toggle f2

overally its quite weird how times switch randomly form version to wersion,
there is kinda joke that may be used when talking with ponys who generally thinks hard that
newer version of soft is always better - the joke would be to say that never version has 50% chance
to be better and 50% chance to be worse - i dont use that joke but it seems that reall life resembles this joke a lot

for eample when compiling my library (with some initial scene) with gcc 4.7 30 ms... gcc5.1 25 ms ... gcc10.3 28 ms

niedziela, 29 maja 2022 o 13:50:44 UTC+2 fir napisał(a):
> niedziela, 29 maja 2022 o 13:05:30 UTC+2 fir napisał(a):
> > niedziela, 29 maja 2022 o 12:57:48 UTC+2 fir napisał(a):
> > > niedziela, 29 maja 2022 o 12:08:21 UTC+2 fir napisał(a):
> > > >
> > > > like:
> > > > x = sign(d)*d*d
> > > >
> > >
> > > in fact fabs could go here and i do some tests
> > >
> > > void RunFrame(int advance)
> > > {
> > > ClearFrameData(0x505077);
> > > sum = 0;
> > > for(float f= -333333.33; f< 333333.3; f+=0.111)
> > > // sum = -copysignf(1,f)*f*f; //26 ms //29 ms
> > > sum = -fabs(f)*f; //26 ms //34 ms
> > >
> > > DrawSomeText2(0xff0000, 10 , 30, "aaaa %f", sum);
> > > }
> > >
> > > i test it pitting some dosed in frame ofthe game as my little library has a built in plot
> > > showing frame times so i may see olways live what my game changes effect on frame times
> > >
> > > i tested it on gcc 5 and gcc 10 - i more use gcc5 for some reason i dont remember which one
> > > maybe it compiles faster or maybe becouse another reasons (various version of compilers sometimes
> > > compiel some things better and some other worse so its the best to have couple and test them all
> > > from time to time)
> > >
> > > some may also test it of have windows, only need to have mingw/tdm installed and put path to in tn compile.vat first line
> > >
> > > http://filesharing24.com/d/Ofo
> > btw if some would like test it when runing it press f4 and hold, it sets sleep in the loop to zero so only there the value is real (sleep is added to not make cpu work on full load, and teh counter counts difference in time including all round (including sleep) but in case of testing one want to sleep zero to see minimal frame time)
> forgot to mention to show a plot one ned to toggle f2
>
> overally its quite weird how times switch randomly form version to wersion,
> there is kinda joke that may be used when talking with ponys who generally thinks hard that
> newer version of soft is always better - the joke would be to say that never version has 50% chance
> to be better and 50% chance to be worse - i dont use that joke but it seems that reall life resembles this joke a lot
>
> for eample when compiling my library (with some initial scene) with gcc 4..9 30 ms... gcc5.1 25 ms ... gcc10.3 28 ms

with this sign example its in fact oposite 4.7 was 26 ms same as 10.3 when 5.1 was 29ms and 34 ms

On 5/29/2022 2:01 AM, Ben wrote:
> 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.

Yes, but that comes from <math.h> or <cmath>, which is substantially
equivalent - in other words, this falls into the inclusion of C into C++.
On the other hand, the proposed alternative, C++ template based, is
considerably worse, IMO.

>
>>> #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);

I can't find a signbitf function or macro in the C or C++ standard.

>
> if likely to be what's wanted, even though float_t is not a standard
> type.

As Keith said, float_t is declared in <math.h> as part of the standard.
I was surprised too.

Anyway, the point stands that simpler solutions are often
> preferable.

Agreed, that is the gist of the "even superior" part.

>
>>> return sign;
>>> }
>

ye thinking a bot more on that i think thet simplicity is the most valueable here (probably)

so this IEEE 754 is not good

what is should be:
highest byte exponent (in U2 from +127 to -128 or maybe -127 and -128 would meen inf)
lowest 3 bytes 24bit integer in U2 ...exponent would meen *2^exp

so zero would be 00000000 00000000 00000000 00000000
1 would be 00000000 00000000 00000000 00000001
-1 would be 00000000 11111111 11111111 11111111
1/2 would be 11111111 00000000 00000000 00000001
-1/2 im not sure 11111111 11111111 1111111 1111111
???

niedziela, 29 maja 2022 o 18:31:08 UTC+2 fir napisał(a):
> ye thinking a bot more on that i think thet simplicity is the most valueable here (probably)
>
> so this IEEE 754 is not good
>
> what is should be:
> highest byte exponent (in U2 from +127 to -128 or maybe -127 and -128 would meen inf)
> lowest 3 bytes 24bit integer in U2 ...exponent would meen *2^exp
>
> so zero would be 00000000 00000000 00000000 00000000
> 1 would be 00000000 00000000 00000000 00000001
> -1 would be 00000000 11111111 11111111 11111111
> 1/2 would be 11111111 00000000 00000000 00000001
> -1/2 im not sure 11111111 11111111 1111111 1111111
> ???
though im not sure if the dot should be not movd inituially
so 1 should be 00000000 00000000 0001 0000 00000000
1/2 would be 00000000 00000000 0000 1000 00000000

do teh 1/x would be then liek copying bits in reverse? like 13 = 00001101 so 1/13 = 10110000 ??

niedziela, 29 maja 2022 o 18:36:39 UTC+2 fir napisał(a):
> niedziela, 29 maja 2022 o 18:31:08 UTC+2 fir napisał(a):
> > ye thinking a bot more on that i think thet simplicity is the most valueable here (probably)
> >
> > so this IEEE 754 is not good
> >
> > what is should be:
> > highest byte exponent (in U2 from +127 to -128 or maybe -127 and -128 would meen inf)
> > lowest 3 bytes 24bit integer in U2 ...exponent would meen *2^exp
> >
> > so zero would be 00000000 00000000 00000000 00000000
> > 1 would be 00000000 00000000 00000000 00000001
> > -1 would be 00000000 11111111 11111111 11111111
> > 1/2 would be 11111111 00000000 00000000 00000001
> > -1/2 im not sure 11111111 11111111 1111111 1111111
> > ???
> though im not sure if the dot should be not movd inituially
> so 1 should be 00000000 00000000 0001 0000 00000000
> 1/2 would be 00000000 00000000 0000 1000 00000000
>
> do teh 1/x would be then liek copying bits in reverse? like 13 = 00001101 so 1/13 = 10110000 ??

nah it would be only 1/1 +1/4+1/8 = 13/8

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Ben <ben.usenet@bsb.me.uk> writes:
> [...]
>> 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.
>
> Yes, float_t is standard. It's the same as one of the predefined
> floating-point types, depending on the value of FLT_EVAL_METHOD.

Never new that. Thanks.

--
Ben.

Manfred <noname@add.invalid> writes:

> On 5/29/2022 2:01 AM, Ben wrote:
>
>> 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.
>
> Yes, but that comes from <math.h> or <cmath>, which is substantially
> equivalent - in other words, this falls into the inclusion of C into
> C++.
> On the other hand, the proposed alternative, C++ template based, is
> considerably worse, IMO.
>
>>>> #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);
>
> I can't find a signbitf function or macro in the C or C++ standard.

Right. C defines a signbit() macro; C++ defines a signbit()
function, overloaded for each of the usual floating-point types.

>> if likely to be what's wanted, even though float_t is not a standard
>> type.
>
> As Keith said, float_t is declared in <math.h> as part of the
> standard. I was surprised too.
>
>> Anyway, the point stands that simpler solutions are often
>> preferable.
>
> Agreed, that is the gist of the "even superior" part.

I'm all in favor of simple solutions, but to count as a solution
the code needs to supply the behavior desired. The code from
Bonita gives a several-valued result (actually a many-valued
result, but the key thing is that it is more than binary).
Apparently what is being looked for is a "signum" function for
floating point, giving -1, 0, or 1, according to whether its
argument is, respectively, less than, equal to, or greater than
zero. This behavior can be supplied with a single (and simple)
function definition (and incidentally one that works regardless
of how floating-point numbers are represented):

#include <math.h>

int
fp_signum( long double x ){
return x ? signbit(x) ? -1 : 1 : 0;
}

If writing in C++, we might need a different #include (I have not
investigated that), and we might want to define two more overloaded
versions, for double and float, if that matters for some reason
(such as performance considerations).

Il 05/06/2022 16:35, Tim Rentsch ha scritto:
> Manfred <noname@add.invalid> writes:
>
>> On 5/29/2022 2:01 AM, Ben wrote:
>>
>>> 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.
>>
>> Yes, but that comes from <math.h> or <cmath>, which is substantially
>> equivalent - in other words, this falls into the inclusion of C into
>> C++.
>> On the other hand, the proposed alternative, C++ template based, is
>> considerably worse, IMO.
>>
>>>>> #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);
>>
>> I can't find a signbitf function or macro in the C or C++ standard.
>
> Right. C defines a signbit() macro; C++ defines a signbit()
> function, overloaded for each of the usual floating-point types.
>
>>> if likely to be what's wanted, even though float_t is not a standard
>>> type.
>>
>> As Keith said, float_t is declared in <math.h> as part of the
>> standard. I was surprised too.
>>
>>> Anyway, the point stands that simpler solutions are often
>>> preferable.
>>
>> Agreed, that is the gist of the "even superior" part.
>
> I'm all in favor of simple solutions, but to count as a solution
> the code needs to supply the behavior desired. The code from
> Bonita gives a several-valued result (actually a many-valued
> result, but the key thing is that it is more than binary).
> Apparently what is being looked for is a "signum" function for
> floating point, giving -1, 0, or 1, according to whether its
> argument is, respectively, less than, equal to, or greater than
> zero. This behavior can be supplied with a single (and simple)
> function definition (and incidentally one that works regardless
> of how floating-point numbers are represented):
>
> #include <math.h>
>
> int
> fp_signum( long double x ){
> return x ? signbit(x) ? -1 : 1 : 0;
> }
>
> If writing in C++, we might need a different #include (I have not
> investigated that), and we might want to define two more overloaded
> versions, for double and float, if that matters for some reason
> (such as performance considerations).

mmmh ... so in C, using a macro like this, you could make the floating
point type generic:

#define my_sign(x) ((x == 0.) ? 0 : (((unsigned char *)&x)[sizeof(x) -
1] & 0x80) ? -1 : 1)

jak <nospam@please.ty> writes:

> Il 05/06/2022 16:35, Tim Rentsch ha scritto:

[...]

>> Apparently what is being looked for is a "signum" function for
>> floating point, giving -1, 0, or 1, according to whether its
>> argument is, respectively, less than, equal to, or greater than
>> zero. This behavior can be supplied with a single (and simple)
>> function definition (and incidentally one that works regardless
>> of how floating-point numbers are represented):
>>
>> #include <math.h>
>>
>> int
>> fp_signum( long double x ){
>> return x ? signbit(x) ? -1 : 1 : 0;
>> }
>>
>> [...]
>
> mmmh ... so in C, using a macro like this, you could make the floating
> point type generic: [white space added to avoid long lines]
>
> #define my_sign(x) ( \
> (x == 0.) ? 0 : \
> (((unsigned char *)&x)[sizeof(x) - 1] & 0x80) ? -1 : 1 \
> )

Yes you could.. if you aren't worried about portability, and
you aren't too fussy about getting compilation errors for some
floating-point arguments, and you don't mind getting wrong
answers in some cases.

(Also, macro parameters should be enclosed in parentheses to
avoid unintended parsings. But the problems mentioned remain
even if the macro definition is changed to follow that rule.)

Il 05/06/2022 22:09, Tim Rentsch ha scritto:
> jak <nospam@please.ty> writes:
>
>> Il 05/06/2022 16:35, Tim Rentsch ha scritto:
>
> [...]
>
>>> Apparently what is being looked for is a "signum" function for
>>> floating point, giving -1, 0, or 1, according to whether its
>>> argument is, respectively, less than, equal to, or greater than
>>> zero. This behavior can be supplied with a single (and simple)
>>> function definition (and incidentally one that works regardless
>>> of how floating-point numbers are represented):
>>>
>>> #include <math.h>
>>>
>>> int
>>> fp_signum( long double x ){
>>> return x ? signbit(x) ? -1 : 1 : 0;
>>> }
>>>
>>> [...]
>>
>> mmmh ... so in C, using a macro like this, you could make the floating
>> point type generic: [white space added to avoid long lines]
>>
>> #define my_sign(x) ( \
>> (x == 0.) ? 0 : \
>> (((unsigned char *)&x)[sizeof(x) - 1] & 0x80) ? -1 : 1 \
>> )
>
> Yes you could.. if you aren't worried about portability, and
> you aren't too fussy about getting compilation errors for some
> floating-point arguments, and you don't mind getting wrong
> answers in some cases.
>
> (Also, macro parameters should be enclosed in parentheses to
> avoid unintended parsings. But the problems mentioned remain
> even if the macro definition is changed to follow that rule.)

then changing the macro like this:

#define my_sign(v) \
({ \
long double x = (long double)(v); \
int r = 0; \
if(x != 0.) \
r = (x > 0.) ? 1 : -1; \
r; \
})

and then by casting to the largest of the float types and using only
boolean logic with a macro you can test all the float types that have a
size smaller than or equal to the largest of them and the representation
of the types is not important. If there are further problems I have not
noticed them English is not my language.

jak <nospam@please.ty> writes:

> Il 05/06/2022 22:09, Tim Rentsch ha scritto:
>
>> jak <nospam@please.ty> writes:
>>
>>> Il 05/06/2022 16:35, Tim Rentsch ha scritto:
>>
>> [...]
>>
>>>> Apparently what is being looked for is a "signum" function for
>>>> floating point, giving -1, 0, or 1, according to whether its
>>>> argument is, respectively, less than, equal to, or greater than
>>>> zero. This behavior can be supplied with a single (and simple)
>>>> function definition (and incidentally one that works regardless
>>>> of how floating-point numbers are represented):
>>>>
>>>> #include <math.h>
>>>>
>>>> int
>>>> fp_signum( long double x ){
>>>> return x ? signbit(x) ? -1 : 1 : 0;
>>>> }
>>>>
>>>> [...]
>>>
>>> mmmh ... so in C, using a macro like this, you could make the floating
>>> point type generic: [white space added to avoid long lines]
>>>
>>> #define my_sign(x) ( \
>>> (x == 0.) ? 0 : \
>>> (((unsigned char *)&x)[sizeof(x) - 1] & 0x80) ? -1 : 1 \
>>> )
>>
>> Yes you could.. if you aren't worried about portability, and
>> you aren't too fussy about getting compilation errors for some
>> floating-point arguments, and you don't mind getting wrong
>> answers in some cases.
>>
>> (Also, macro parameters should be enclosed in parentheses to
>> avoid unintended parsings. But the problems mentioned remain
>> even if the macro definition is changed to follow that rule.)
>
> then changing the macro like this:
>
> #define my_sign(v) \
> ({ \
> long double x = (long double)(v); \
> int r = 0; \
> if(x != 0.) \
> r = (x > 0.) ? 1 : -1; \
> r; \
> })
>
> and then by casting to the largest of the float types and using
> only boolean logic with a macro you can test all the float types
> that have a size smaller than or equal to the largest of them and
> the representation of the types is not important. If there are
> further problems I have not noticed them English is not my
> language.

This macro is better than the last one, but it's more complicated
than it has to be, and it needs a non-standard extension to work.

Using a function like the one shown above allows the code to be
standard ISO C, which is an important advantage. If performance
matters the function can be declared 'static inline', which is
likely to give the same performance as a macro expansion.

Il 07/06/2022 01:45, Tim Rentsch ha scritto:
> This macro is better than the last one, but it's more complicated
> than it has to be, and it needs a non-standard extension to work.
>
> Using a function like the one shown above allows the code to be
> standard ISO C, which is an important advantage. If performance
> matters the function can be declared 'static inline', which is
> likely to give the same performance as a macro expansion.

you are right, but this macro has the advantage that it can be used with
all numeric types and not just floats. sometimes accepting compromises
can be beneficial.

cheers

jak <nospam@please.ty> writes:

> Il 07/06/2022 01:45, Tim Rentsch ha scritto:
>> This macro is better than the last one, but it's more complicated
>> than it has to be, and it needs a non-standard extension to work.
>> Using a function like the one shown above allows the code to be
>> standard ISO C, which is an important advantage. If performance
>> matters the function can be declared 'static inline', which is
>> likely to give the same performance as a macro expansion.
>
> you are right, but this macro has the advantage that it can be used with
> all numeric types and not just floats.

So can Tim's function.

> sometimes accepting compromises can be beneficial.

Sure, but there's no trade-off here.

--
Ben.

Il 07/06/2022 12:56, Ben ha scritto:
> jak <nospam@please.ty> writes:
>
>> Il 07/06/2022 01:45, Tim Rentsch ha scritto:
>>> This macro is better than the last one, but it's more complicated
>>> than it has to be, and it needs a non-standard extension to work.
>>> Using a function like the one shown above allows the code to be
>>> standard ISO C, which is an important advantage. If performance
>>> matters the function can be declared 'static inline', which is
>>> likely to give the same performance as a macro expansion.
>>
>> you are right, but this macro has the advantage that it can be used with
>> all numeric types and not just floats.
>
> So can Tim's function.
>
>> sometimes accepting compromises can be beneficial.
>
> Sure, but there's no trade-off here.
>

oh i know but i also know that among so many languages, this is the
least suitable for following standards and therefore i shut myself up.