i think there is probably a need of clamp operator
in c
the question is how it could look like
it could be something like

x = <0|x|650> but with some better operator
one alos may think of some keyword like CL
(clamp left) and CR (clamp right

x = x CL 0;
x = x CR 650;

but how it should look better in details i dont know

sobota, 1 lipca 2023 o 16:20:25 UTC+2 fir napisał(a):
> i think there is probably a need of clamp operator
> in c
> the question is how it could look like
> it could be something like
>
> x = <0|x|650> but with some better operator
> one alos may think of some keyword like CL
> (clamp left) and CR (clamp right
>
> x = x CL 0;
> x = x CR 650;
>
> but how it should look better in details i dont know

maybe something liek this may be considered
x |= 0 //clamp down to zero
x =| 100 //clamp up to 100

by analogy to += etc

sobota, 1 lipca 2023 o 16:24:42 UTC+2 fir napisał(a):
> sobota, 1 lipca 2023 o 16:20:25 UTC+2 fir napisał(a):
> > i think there is probably a need of clamp operator
> > in c
> > the question is how it could look like
> > it could be something like
> >
> > x = <0|x|650> but with some better operator
> > one alos may think of some keyword like CL
> > (clamp left) and CR (clamp right
> >
> > x = x CL 0;
> > x = x CR 650;
> >
> > but how it should look better in details i dont know
> maybe something liek this may be considered
> x |= 0 //clamp down to zero
> x =| 100 //clamp up to 100
>
> by analogy to += etc

or maybe <? for min operator and ?> for max operator

x = 2<?10 //2

so

x = (x ?> 0) <? 100 worx liek clamp i guess

x ?>= 100; // same as a = a ?> 100 it is max(a,100) //clamp down to 100

sobota, 1 lipca 2023 o 16:46:00 UTC+2 fir napisał(a):
> sobota, 1 lipca 2023 o 16:24:42 UTC+2 fir napisał(a):
> > sobota, 1 lipca 2023 o 16:20:25 UTC+2 fir napisał(a):
> > > i think there is probably a need of clamp operator
> > > in c
> > > the question is how it could look like
> > > it could be something like
> > >
> > > x = <0|x|650> but with some better operator
> > > one alos may think of some keyword like CL
> > > (clamp left) and CR (clamp right
> > >
> > > x = x CL 0;
> > > x = x CR 650;
> > >
> > > but how it should look better in details i dont know
> > maybe something liek this may be considered
> > x |= 0 //clamp down to zero
> > x =| 100 //clamp up to 100
> >
> > by analogy to += etc
> or maybe <? for min operator and ?> for max operator
>
> x = 2<?10 //2
>
> so
>
> x = (x ?> 0) <? 100 worx liek clamp i guess
>
> x ?>= 100; // same as a = a ?> 100 it is max(a,100) //clamp down to 100

so

0 >? z <? 100

clamp z to {0 to 100}

seems sorta ok, though better symbols could be used

On 01/07/2023 15:24, fir wrote:
> sobota, 1 lipca 2023 o 16:20:25 UTC+2 fir napisał(a):
>> i think there is probably a need of clamp operator
>> in c
>> the question is how it could look like
>> it could be something like
>>
>> x = <0|x|650> but with some better operator
>> one alos may think of some keyword like CL
>> (clamp left) and CR (clamp right
>>
>> x = x CL 0;
>> x = x CR 650;
>>
>> but how it should look better in details i dont know
>
> maybe something liek this may be considered
> x |= 0 //clamp down to zero
> x =| 100 //clamp up to 100

> by analogy to += etc

'clamp' is never going to make it into C since it is so trivially
implemented as a function.

However, I do have clamp as an operator in my own languages, where it
has this syntax:

y := clamp(x, a, b)

a, b are lower and upper limits. I transform clamp(x, a, b) internally
into min(max(x, a), b).

min/max are always operators, usually written as max(a, b), but can alos
be used in place like this, to implement your examples:

x max:= 0
x min:= 650 # so, x := min(x, 650)

The reason I don't have a `clamp`, or `min max`, as functions, is to
allow overloading (say between ints and floats), but also my compilers
can't automatically inline functions, so it is easier to generate
efficient inline code.

An expression like `max(x, y)` when x, y are floats, is implemented as
three instructions including `maxsd`.

sobota, 1 lipca 2023 o 17:01:47 UTC+2 Bart napisał(a):
> On 01/07/2023 15:24, fir wrote:
> > sobota, 1 lipca 2023 o 16:20:25 UTC+2 fir napisał(a):
> >> i think there is probably a need of clamp operator
> >> in c
> >> the question is how it could look like
> >> it could be something like
> >>
> >> x = <0|x|650> but with some better operator
> >> one alos may think of some keyword like CL
> >> (clamp left) and CR (clamp right
> >>
> >> x = x CL 0;
> >> x = x CR 650;
> >>
> >> but how it should look better in details i dont know
> >
> > maybe something liek this may be considered
> > x |= 0 //clamp down to zero
> > x =| 100 //clamp up to 100
>
> > by analogy to += etc
> 'clamp' is never going to make it into C since it is so trivially
> implemented as a function.
>

it need to be operator as code in c that does clamping looks
sometimes bad

see for example

pship.shield += pship.shield_regen;
if(pship.shield>pship.shield_max) pship.shield=pship.shield_max;

its long as i sometimes use long names

writing clamp function in c that looks good also is not looking good (some may show exampel if find soem looks good, one i wrote dont look good

i could eventually write specific like clamp_down_to_zero or something better but also not best
pship.shield += pship.shield_regen;
pship.shield= clamp_down_to_zero ( pship.shield);
or
pship.shield += pship.shield_regen;
clamp_down_to_zero (&pship.shield);

some operator should juzt be good

(pship.shield += pship.shield_regen) |= 0;

i also dont liek use min max as this inherited confusion with it

not is clamp left would be |= clamp right =| then min max would be maybe |< >|
though here is a bit of confusion as clamp left is related to max and is max is >| then maybe it should be |>

x |> 100 //max ..clamp ;eft eventually x |=100

> However, I do have clamp as an operator in my own languages, where it
> has this syntax:
>
> y := clamp(x, a, b)
>
> a, b are lower and upper limits. I transform clamp(x, a, b) internally
> into min(max(x, a), b).
>
> min/max are always operators, usually written as max(a, b), but can alos
> be used in place like this, to implement your examples:
>
> x max:= 0
> x min:= 650 # so, x := min(x, 650)
>
> The reason I don't have a `clamp`, or `min max`, as functions, is to
> allow overloading (say between ints and floats), but also my compilers
> can't automatically inline functions, so it is easier to generate
> efficient inline code.
>
> An expression like `max(x, y)` when x, y are floats, is implemented as
> three instructions including `maxsd`.

On 7/1/23 10:24 AM, fir wrote:
> sobota, 1 lipca 2023 o 16:20:25 UTC+2 fir napisał(a):
>> i think there is probably a need of clamp operator
>> in c
>> the question is how it could look like
>> it could be something like
>>
>> x = <0|x|650> but with some better operator
>> one alos may think of some keyword like CL
>> (clamp left) and CR (clamp right
>>
>> x = x CL 0;
>> x = x CR 650;
>>
>> but how it should look better in details i dont know
>
> maybe something liek this may be considered
> x |= 0 //clamp down to zero
> x =| 100 //clamp up to 100
>
> by analogy to += etc

Did you forget that |= is already a C operator, and =| is an archaic
equivalent to it?

|= IS the exact analogy to +=

x |= a is the equivalent to x = x | a, the bitwise oring of the values.

sobota, 1 lipca 2023 o 18:43:52 UTC+2 Richard Damon napisał(a):
> On 7/1/23 10:24 AM, fir wrote:
> > sobota, 1 lipca 2023 o 16:20:25 UTC+2 fir napisał(a):
> >> i think there is probably a need of clamp operator
> >> in c
> >> the question is how it could look like
> >> it could be something like
> >>
> >> x = <0|x|650> but with some better operator
> >> one alos may think of some keyword like CL
> >> (clamp left) and CR (clamp right
> >>
> >> x = x CL 0;
> >> x = x CR 650;
> >>
> >> but how it should look better in details i dont know
> >
> > maybe something liek this may be considered
> > x |= 0 //clamp down to zero
> > x =| 100 //clamp up to 100
> >
> > by analogy to += etc
> Did you forget that |= is already a C operator, and =| is an archaic
> equivalent to it?
>
> |= IS the exact analogy to +=
>
> x |= a is the equivalent to x = x | a, the bitwise oring of the values.

ye i know...but those bit-logic operators were amde in sixties when bit operations
were so important today imo it showed that it block more useful syntax
and bit operators should be moved on longer names imo...

ofc in c it couldnt be changed and is someone would ad clamps and min/max operators should use something other (and probably shouldnt do it at all
as changing classical c has big negative result imo)

but it might considered on more general field of c-spirit and here in new c those operators (clamps and min/max) are imo for sure needed

sobota, 1 lipca 2023 o 18:49:20 UTC+2 fir napisał(a):
> sobota, 1 lipca 2023 o 18:43:52 UTC+2 Richard Damon napisał(a):
> > On 7/1/23 10:24 AM, fir wrote:
> > > sobota, 1 lipca 2023 o 16:20:25 UTC+2 fir napisał(a):
> > >> i think there is probably a need of clamp operator
> > >> in c
> > >> the question is how it could look like
> > >> it could be something like
> > >>
> > >> x = <0|x|650> but with some better operator
> > >> one alos may think of some keyword like CL
> > >> (clamp left) and CR (clamp right
> > >>
> > >> x = x CL 0;
> > >> x = x CR 650;
> > >>
> > >> but how it should look better in details i dont know
> > >
> > > maybe something liek this may be considered
> > > x |= 0 //clamp down to zero
> > > x =| 100 //clamp up to 100
> > >
> > > by analogy to += etc
> > Did you forget that |= is already a C operator, and =| is an archaic
> > equivalent to it?
> >
> > |= IS the exact analogy to +=
> >
> > x |= a is the equivalent to x = x | a, the bitwise oring of the values.
> ye i know...but those bit-logic operators were amde in sixties when bit operations
> were so important today imo it showed that it block more useful syntax
> and bit operators should be moved on longer names imo...
>
> ofc in c it couldnt be changed and is someone would ad clamps and min/max operators should use something other (and probably shouldnt do it at all
> as changing classical c has big negative result imo)
>
> but it might considered on more general field of c-spirit and here in new c those operators (clamps and min/max) are imo for sure needed

overally in c arithmetic operators agre great, logical are badly asigned to syntax imo as i said, relative should in turn be improved imo

i onse was talked that considering 0/1 as true false is logically bad:
both 0/1 should be true and fales is for negative values

thus things like a>100 imo possibly should return maybe a difference between a and 100, so if a is 106 a>100 should return possibly 5 - so it brings info its true and yet value (its side remark though, though its quite important to notice that 0/1 is logically bad)

sobota, 1 lipca 2023 o 19:01:20 UTC+2 fir napisał(a):
> sobota, 1 lipca 2023 o 18:49:20 UTC+2 fir napisał(a):
> > sobota, 1 lipca 2023 o 18:43:52 UTC+2 Richard Damon napisał(a):
> > > On 7/1/23 10:24 AM, fir wrote:
> > > > sobota, 1 lipca 2023 o 16:20:25 UTC+2 fir napisał(a):
> > > >> i think there is probably a need of clamp operator
> > > Did you forget that |= is already a C operator, and =| is an archaic
> > > equivalent to it?
> > >
> > > |= IS the exact analogy to +=
> > >
> > > x |= a is the equivalent to x = x | a, the bitwise oring of the values.
> > ye i know...but those bit-logic operators were amde in sixties when bit operations
> > were so important today imo it showed that it block more useful syntax
> > and bit operators should be moved on longer names imo...
> >
> > ofc in c it couldnt be changed and is someone would ad clamps and min/max operators should use something other (and probably shouldnt do it at all
> > as changing classical c has big negative result imo)
> >
> > but it might considered on more general field of c-spirit and here in new c those operators (clamps and min/max) are imo for sure needed
> overally in c arithmetic operators agre great, logical are badly asigned to syntax imo as i said, relative should in turn be improved imo
>
> i onse was talked that considering 0/1 as true false is logically bad:
> both 0/1 should be true and fales is for negative values
>
> thus things like a>100 imo possibly should return maybe a difference between a and 100, so if a is 106 a>100 should return possibly 5 - so it brings info its true and yet value (its side remark though, though its quite important to notice that 0/1 is logically bad)

so in short my opinion on c operators

arithnetic - great
logical - wrongly assigned to syntax (&|~^)
relative - need repair a bit
clamp/minmax - needed to be added

sobota, 1 lipca 2023 o 17:01:47 UTC+2 Bart napisał(a):
> On 01/07/2023 15:24, fir wrote:
> > sobota, 1 lipca 2023 o 16:20:25 UTC+2 fir napisał(a):
> >> i think there is probably a need of clamp operator
> >> in c
> >> the question is how it could look like
> >> it could be something like
> >>
> >> x = <0|x|650> but with some better operator
> >> one alos may think of some keyword like CL
> >> (clamp left) and CR (clamp right
> >>
> >> x = x CL 0;
> >> x = x CR 650;
> >>
> >> but how it should look better in details i dont know
> >
> > maybe something liek this may be considered
> > x |= 0 //clamp down to zero
> > x =| 100 //clamp up to 100
>
> > by analogy to += etc
> 'clamp' is never going to make it into C since it is so trivially
> implemented as a function.
>
> However, I do have clamp as an operator in my own languages, where it
> has this syntax:
>
> y := clamp(x, a, b)
>
> a, b are lower and upper limits. I transform clamp(x, a, b) internally
> into min(max(x, a), b).
>
> min/max are always operators, usually written as max(a, b), but can alos
> be used in place like this, to implement your examples:
>
> x max:= 0
> x min:= 650 # so, x := min(x, 650)
>
> The reason I don't have a `clamp`, or `min max`, as functions, is to
> allow overloading (say between ints and floats), but also my compilers
> can't automatically inline functions, so it is easier to generate
> efficient inline code.
>
> An expression like `max(x, y)` when x, y are floats, is implemented as
> three instructions including `maxsd`.

btw writing min/max/clamp as a branch is probably evil as imo
min/max/clamp are in fact quick branchless operation
if properly written - thionking on it min is probably min = (a+b)/2 - fabs(a-b)/2
so its branchless, (and fast as fabs and div by 2 are cheap imo) so it shpuld be branchless operator imo for sure - seaing ifs there would be pain/bad (yawn)

On 01/07/2023 18:33, fir wrote:
> sobota, 1 lipca 2023 o 17:01:47 UTC+2 Bart napisał(a):
>> An expression like `max(x, y)` when x, y are floats, is implemented as
>> three instructions including `maxsd`.
>
> btw writing min/max/clamp as a branch is probably evil as imo
> min/max/clamp are in fact quick branchless operation
> if properly written - thionking on it min is probably min = (a+b)/2
- fabs(a-b)/2
> so its branchless, (and fast as fabs and div by 2 are cheap imo)

Integers or floats? I'm asking because div by 2 is only cheap for
integers, but fabs is defined for floats and implementated via a
function, unless optimised by compiler.

But both min/max can already be done branchless for both integers and
floats on x64: integers make use of CMOVcc, and floats make use of
MINSS/SD and MAXSS/SD.

They don't really need an optimising compiler if intrinsic operators.

sobota, 1 lipca 2023 o 20:36:46 UTC+2 Bart napisał(a):
> On 01/07/2023 18:33, fir wrote:
> > sobota, 1 lipca 2023 o 17:01:47 UTC+2 Bart napisał(a):
> >> An expression like `max(x, y)` when x, y are floats, is implemented as
> >> three instructions including `maxsd`.
> >
> > btw writing min/max/clamp as a branch is probably evil as imo
> > min/max/clamp are in fact quick branchless operation
> > if properly written - thionking on it min is probably min = (a+b)/2
> - fabs(a-b)/2
> > so its branchless, (and fast as fabs and div by 2 are cheap imo)
> Integers or floats? I'm asking because div by 2 is only cheap for
> integers, but fabs is defined for floats and implementated via a
> function, unless optimised by compiler.
>
> But both min/max can already be done branchless for both integers and
> floats on x64: integers make use of CMOVcc, and floats make use of
> MINSS/SD and MAXSS/SD.
>
> They don't really need an optimising compiler if intrinsic operators.

both should be cheap imo, floats are in a form of amntisa+exponent and afair the exponent is in binary so div by 2 is dec expomnent or something like that

On 7/1/2023 7:20 AM, fir wrote:
> i think there is probably a need of clamp operator
> in c
> the question is how it could look like
> it could be something like
>
> x = <0|x|650> but with some better operator
> one alos may think of some keyword like CL
> (clamp left) and CR (clamp right
>
> x = x CL 0;
> x = x CR 650;
>
> but how it should look better in details i dont know
>

Check out the clamp source code from the
GLM library:

https://glm.g-truc.net/0.9.5/api/a00155.html#ga72e9e213c84f06a329a2a838b51200f4

On 01/07/2023 19:42, fir wrote:
> sobota, 1 lipca 2023 o 20:36:46 UTC+2 Bart napisał(a):
>> On 01/07/2023 18:33, fir wrote:
>>> sobota, 1 lipca 2023 o 17:01:47 UTC+2 Bart napisał(a):
>>>> An expression like `max(x, y)` when x, y are floats, is implemented as
>>>> three instructions including `maxsd`.
>>>
>>> btw writing min/max/clamp as a branch is probably evil as imo
>>> min/max/clamp are in fact quick branchless operation
>>> if properly written - thionking on it min is probably min = (a+b)/2
>> - fabs(a-b)/2
>>> so its branchless, (and fast as fabs and div by 2 are cheap imo)
>> Integers or floats? I'm asking because div by 2 is only cheap for
>> integers, but fabs is defined for floats and implementated via a
>> function, unless optimised by compiler.
>>
>> But both min/max can already be done branchless for both integers and
>> floats on x64: integers make use of CMOVcc, and floats make use of
>> MINSS/SD and MAXSS/SD.
>>
>> They don't really need an optimising compiler if intrinsic operators.
>
> both should be cheap imo, floats are in a form of amntisa+exponent
and afair the exponent is in binary so div by 2 is dec expomnent or
something like that

Yes, you have to decrement an 11-bit field in a 64-bit word making sure
it doesn't affect the neighbouring bits, while also checking it's not a
NaN or Infinity or Zero or (I think) a Denormal value.

If I look at gcc's code to divide by 2.0, the best it seems to manage is
to multiply by 0.5.

I don't think it's worth trying anything too clever. I ran a test
comparing a min() function using your formula, with one just using
a<=b?a:b, and with gcc they both ran in the same time, whether optimised
or not.

With tcc and bcc however, your formula was 4-6 times slower; the reason
appears to be that it calls the library fabs function rather than use
inline code as gcc does.

Otherwise all timings were the same: 0.5 seconds for 100M iterations,
even with gcc-O3.

Using my language however with the built-in min() function, it took 0.25
seconds unoptimised (and 0.08 seconds optimised), which is now mainly
loop overhead.

niedziela, 2 lipca 2023 o 00:00:48 UTC+2 Bart napisał(a):
> On 01/07/2023 19:42, fir wrote:
> > sobota, 1 lipca 2023 o 20:36:46 UTC+2 Bart napisał(a):
> >> On 01/07/2023 18:33, fir wrote:
> >>> sobota, 1 lipca 2023 o 17:01:47 UTC+2 Bart napisał(a):
> >>>> An expression like `max(x, y)` when x, y are floats, is implemented as
> >>>> three instructions including `maxsd`.
> >>>
> >>> btw writing min/max/clamp as a branch is probably evil as imo
> >>> min/max/clamp are in fact quick branchless operation
> >>> if properly written - thionking on it min is probably min = (a+b)/2
> >> - fabs(a-b)/2
> >>> so its branchless, (and fast as fabs and div by 2 are cheap imo)
> >> Integers or floats? I'm asking because div by 2 is only cheap for
> >> integers, but fabs is defined for floats and implementated via a
> >> function, unless optimised by compiler.
> >>
> >> But both min/max can already be done branchless for both integers and
> >> floats on x64: integers make use of CMOVcc, and floats make use of
> >> MINSS/SD and MAXSS/SD.
> >>
> >> They don't really need an optimising compiler if intrinsic operators.
> >
> > both should be cheap imo, floats are in a form of amntisa+exponent
> and afair the exponent is in binary so div by 2 is dec expomnent or
> something like that
> Yes, you have to decrement an 11-bit field in a 64-bit word making sure
> it doesn't affect the neighbouring bits, while also checking it's not a
> NaN or Infinity or Zero or (I think) a Denormal value.
>
> If I look at gcc's code to divide by 2.0, the best it seems to manage is
> to multiply by 0.5.
>
> I don't think it's worth trying anything too clever. I ran a test
> comparing a min() function using your formula, with one just using
> a<=b?a:b, and with gcc they both ran in the same time, whether optimised
> or not.
>
> With tcc and bcc however, your formula was 4-6 times slower; the reason
> appears to be that it calls the library fabs function rather than use
> inline code as gcc does.
>
> Otherwise all timings were the same: 0.5 seconds for 100M iterations,
> even with gcc-O3.
>
> Using my language however with the built-in min() function, it took 0.25
> seconds unoptimised (and 0.08 seconds optimised), which is now mainly
> loop overhead.

present times im not to much in optimisation, im too weary - but i want tos ay that this min/max/clamp has no reason to be slow if well done and should be in a set of operators

niedziela, 2 lipca 2023 o 00:00:48 UTC+2 Bart napisał(a):
> On 01/07/2023 19:42, fir wrote:
> > sobota, 1 lipca 2023 o 20:36:46 UTC+2 Bart napisał(a):
> >> On 01/07/2023 18:33, fir wrote:
> >>> sobota, 1 lipca 2023 o 17:01:47 UTC+2 Bart napisał(a):
> >>>> An expression like `max(x, y)` when x, y are floats, is implemented as
> >>>> three instructions including `maxsd`.
> >>>
> >>> btw writing min/max/clamp as a branch is probably evil as imo
> >>> min/max/clamp are in fact quick branchless operation
> >>> if properly written - thionking on it min is probably min = (a+b)/2
> >> - fabs(a-b)/2
> >>> so its branchless, (and fast as fabs and div by 2 are cheap imo)
> >> Integers or floats? I'm asking because div by 2 is only cheap for
> >> integers, but fabs is defined for floats and implementated via a
> >> function, unless optimised by compiler.
> >>
> >> But both min/max can already be done branchless for both integers and
> >> floats on x64: integers make use of CMOVcc, and floats make use of
> >> MINSS/SD and MAXSS/SD.
> >>
> >> They don't really need an optimising compiler if intrinsic operators.
> >
> > both should be cheap imo, floats are in a form of amntisa+exponent
> and afair the exponent is in binary so div by 2 is dec expomnent or
> something like that
> Yes, you have to decrement an 11-bit field in a 64-bit word making sure
> it doesn't affect the neighbouring bits, while also checking it's not a
> NaN or Infinity or Zero or (I think) a Denormal value.
>
> If I look at gcc's code to divide by 2.0, the best it seems to manage is
> to multiply by 0.5.
>
> I don't think it's worth trying anything too clever. I ran a test
> comparing a min() function using your formula, with one just using
> a<=b?a:b, and with gcc they both ran in the same time, whether optimised
> or not.
>
> With tcc and bcc however, your formula was 4-6 times slower; the reason
> appears to be that it calls the library fabs function rather than use
> inline code as gcc does.
>
> Otherwise all timings were the same: 0.5 seconds for 100M iterations,
> even with gcc-O3.
>
> Using my language however with the built-in min() function, it took 0.25
> seconds unoptimised (and 0.08 seconds optimised), which is now mainly
> loop overhead.

BTW if youre not weary to do test, maybe tou could test one thing

make a function of say 8 pointers to functions, each one say taking
3 floats - then put it on the loop

float x = 22.22, y=33.33, a = 90;

fori(int i=0; i<1000*1000; i++)
{ fun_p[i&8](x,y,a);
}

then compare it to version with switch and not pointers

fori(int i=0; i<1000*1000; i++)
{ if(i&8==0) fun0(x,y,a);
else if f(i&8==1) fun1(x,y,a);
else if f(i&8==2) fun2(x,y,a);
else if f(i&8==3) fun3(x,y,a);
else if f(i&8==4) fun4(x,y,a);
else if f(i&8==5) fun5(x,y,a);
else if f(i&8==6) fun6(x,y,a);
else if f(i&8==7) fun7(x,y,a);
}

i wonder the results but feel a bit weary to test it

On 02/07/2023 11:00, fir wrote:
> niedziela, 2 lipca 2023 o 00:00:48 UTC+2 Bart napisał(a):

>> I don't think it's worth trying anything too clever. I ran a test
>> comparing a min() function using your formula, with one just using
>> a<=b?a:b, and with gcc they both ran in the same time, whether optimised
>> or not.
>>
>> With tcc and bcc however, your formula was 4-6 times slower; the reason
>> appears to be that it calls the library fabs function rather than use
>> inline code as gcc does.
>>
>> Otherwise all timings were the same: 0.5 seconds for 100M iterations,
>> even with gcc-O3.
>>
>> Using my language however with the built-in min() function, it took 0.25
>> seconds unoptimised (and 0.08 seconds optimised), which is now mainly
>> loop overhead.
>
> BTW if youre not weary to do test, maybe tou could test one thing
>
> make a function of say 8 pointers to functions, each one say taking
> 3 floats - then put it on the loop
>
> float x = 22.22, y=33.33, a = 90;
>
> fori(int i=0; i<1000*1000; i++)
> {
> fun_p[i&8](x,y,a);
> }
>
> then compare it to version with switch and not pointers
>
> fori(int i=0; i<1000*1000; i++)
> {
> if(i&8==0) fun0(x,y,a);
> else if f(i&8==1) fun1(x,y,a);
> else if f(i&8==2) fun2(x,y,a);
> else if f(i&8==3) fun3(x,y,a);
> else if f(i&8==4) fun4(x,y,a);
> else if f(i&8==5) fun5(x,y,a);
> else if f(i&8==6) fun6(x,y,a);
> else if f(i&8==7) fun7(x,y,a);
> }
>
> i wonder the results but feel a bit weary to test it

C code? Because it has things like `fori` (I assume a typo); and `if
f()` (another typo?); and `i&8==5`, but `i&8` will give either 0 or 8,
never 5.

Also this second form isn't `switch`, which would be:

switch (i & 7) {
case 0: fun0(x,y,z); break;
etc

I'm sure that if you can type out the above, you can time it too.

For the fastest such dispatch, in the case where `i` is unknown (not
sequential), try using 'computed goto'. But this needs label pointers,
an extension of gcc.

I believe this optimises branch prediction, because there will be
multiple dispatch points to which it can associate predictions, instead
of just one.

niedziela, 2 lipca 2023 o 14:49:51 UTC+2 Bart napisał(a):
> On 02/07/2023 11:00, fir wrote:
> > niedziela, 2 lipca 2023 o 00:00:48 UTC+2 Bart napisał(a):
>
> >> I don't think it's worth trying anything too clever. I ran a test
> >> comparing a min() function using your formula, with one just using
> >> a<=b?a:b, and with gcc they both ran in the same time, whether optimised
> >> or not.
> >>
> >> With tcc and bcc however, your formula was 4-6 times slower; the reason
> >> appears to be that it calls the library fabs function rather than use
> >> inline code as gcc does.
> >>
> >> Otherwise all timings were the same: 0.5 seconds for 100M iterations,
> >> even with gcc-O3.
> >>
> >> Using my language however with the built-in min() function, it took 0.25
> >> seconds unoptimised (and 0.08 seconds optimised), which is now mainly
> >> loop overhead.
> >
> > BTW if youre not weary to do test, maybe tou could test one thing
> >
> > make a function of say 8 pointers to functions, each one say taking
> > 3 floats - then put it on the loop
> >
> > float x = 22.22, y=33.33, a = 90;
> >
> > fori(int i=0; i<1000*1000; i++)
> > {
> > fun_p[i&8](x,y,a);
> > }
> >
> > then compare it to version with switch and not pointers
> >
> > fori(int i=0; i<1000*1000; i++)
> > {
> > if(i&8==0) fun0(x,y,a);
> > else if f(i&8==1) fun1(x,y,a);
> > else if f(i&8==2) fun2(x,y,a);
> > else if f(i&8==3) fun3(x,y,a);
> > else if f(i&8==4) fun4(x,y,a);
> > else if f(i&8==5) fun5(x,y,a);
> > else if f(i&8==6) fun6(x,y,a);
> > else if f(i&8==7) fun7(x,y,a);
> > }
> >
> > i wonder the results but feel a bit weary to test it
> C code? Because it has things like `fori` (I assume a typo); and `if
> f()` (another typo?); and `i&8==5`, but `i&8` will give either 0 or 8,
> never 5.
>
> Also this second form isn't `switch`, which would be:
>
> switch (i & 7) {
> case 0: fun0(x,y,z); break;
> etc
>
> I'm sure that if you can type out the above, you can time it too.
>
> For the fastest such dispatch, in the case where `i` is unknown (not
> sequential), try using 'computed goto'. But this needs label pointers,
> an extension of gcc.
>
> I believe this optimises branch prediction, because there will be
> multiple dispatch points to which it can associate predictions, instead
> of just one.
yes that was typos i mean want to campare table of pointers and switch (better if-ladder, but also my test switch as a third)

i can measure it but i often tired and sometimes need to do somoething else, but eventually now probably i can test it

the result imo is worth knowing

niedziela, 2 lipca 2023 o 15:16:24 UTC+2 fir napisał(a):
> niedziela, 2 lipca 2023 o 14:49:51 UTC+2 Bart napisał(a):
> > On 02/07/2023 11:00, fir wrote:
> > > niedziela, 2 lipca 2023 o 00:00:48 UTC+2 Bart napisał(a):
> >
> > >> I don't think it's worth trying anything too clever. I ran a test
> > >> comparing a min() function using your formula, with one just using
> > >> a<=b?a:b, and with gcc they both ran in the same time, whether optimised
> > >> or not.
> > >>
> > >> With tcc and bcc however, your formula was 4-6 times slower; the reason
> > >> appears to be that it calls the library fabs function rather than use
> > >> inline code as gcc does.
> > >>
> > >> Otherwise all timings were the same: 0.5 seconds for 100M iterations,
> > >> even with gcc-O3.
> > >>
> > >> Using my language however with the built-in min() function, it took 0.25
> > >> seconds unoptimised (and 0.08 seconds optimised), which is now mainly
> > >> loop overhead.
> > >
> > > BTW if youre not weary to do test, maybe tou could test one thing
> > >
> > > make a function of say 8 pointers to functions, each one say taking
> > > 3 floats - then put it on the loop
> > >
> > > float x = 22.22, y=33.33, a = 90;
> > >
> > > fori(int i=0; i<1000*1000; i++)
> > > {
> > > fun_p[i&8](x,y,a);
> > > }
> > >
> > > then compare it to version with switch and not pointers
> > >
> > > fori(int i=0; i<1000*1000; i++)
> > > {
> > > if(i&8==0) fun0(x,y,a);
> > > else if f(i&8==1) fun1(x,y,a);
> > > else if f(i&8==2) fun2(x,y,a);
> > > else if f(i&8==3) fun3(x,y,a);
> > > else if f(i&8==4) fun4(x,y,a);
> > > else if f(i&8==5) fun5(x,y,a);
> > > else if f(i&8==6) fun6(x,y,a);
> > > else if f(i&8==7) fun7(x,y,a);
> > > }
> > >
> > > i wonder the results but feel a bit weary to test it
> > C code? Because it has things like `fori` (I assume a typo); and `if
> > f()` (another typo?); and `i&8==5`, but `i&8` will give either 0 or 8,
> > never 5.
> >
> > Also this second form isn't `switch`, which would be:
> >
> > switch (i & 7) {
> > case 0: fun0(x,y,z); break;
> > etc
> >
> > I'm sure that if you can type out the above, you can time it too.
> >
> > For the fastest such dispatch, in the case where `i` is unknown (not
> > sequential), try using 'computed goto'. But this needs label pointers,
> > an extension of gcc.
> >
> > I believe this optimises branch prediction, because there will be
> > multiple dispatch points to which it can associate predictions, instead
> > of just one.
> yes that was typos i mean want to campare table of pointers and switch (better if-ladder, but also my test switch as a third)
>
> i can measure it but i often tired and sometimes need to do somoething else, but eventually now probably i can test it
>
> the result imo is worth knowing

i made such

int testi = 0;

int f1(int x,int y, int a) { return x+y+a;}
int f2(int x,int y, int a) { return x+y+a+1;}
int f3(int x,int y, int a) { return x+y+a+2;}
int f4(int x,int y, int a) { return x+y+a+3;}
int f5(int x,int y, int a) { return x+y+a+4;}
int f6(int x,int y, int a) { return x+y+a+5;}
int f7(int x,int y, int a) { return x+y+a+6;}
int f8(int x,int y, int a) { return x+y+a+7;}

typedef int (*fp)(int,int,int) ;

fp ftab[8] = {f1,f2,f3,f4,f5,f6,f7,f8};

//[8] = {f1,f2,f3,f4,f5,f6,f7};

void TEST()
{ int x = 230, y=120, a=0;

for(int i=0; i<1000*1000*30; i++)
{
x++; y--; a=i;
if(i&7==0) testi+=f1(x,y,a);
else if(i&7==1) testi+=f2(x,y,a);
else if(i&7==2) testi+=f3(x,y,a);
else if(i&7==3) testi+=f4(x,y,a);
else if(i&7==4) testi+=f5(x,y,a);
else if(i&7==5) testi+=f6(x,y,a);
else if(i&7==6) testi+=f7(x,y,a);
else if(i&7==7) testi+=f8(x,y,a);
}

}

void TEST2()
{ int x = 230, y=120, a=0;

for(int i=0; i<1000*1000*30; i++)
{
x++; y--; a=i;
testi+=ftab[i&7](x,y,a);
}

}

and the results TEST 26 ms TEST2 113 ms - ist probably by this stack passing thru..if so it shows that this kind of function pointers has not much sense..but may try yet some that not apsses arguments via stack

niedziela, 2 lipca 2023 o 16:05:00 UTC+2 fir napisał(a):
>
> and the results TEST 26 ms TEST2 113 ms - ist probably by this stack passing thru..if so it shows that this kind of function pointers has not much sense..but may try yet some that not apsses arguments via stack

tested with no args

int testi;
int x = 230, y=120, a=0;

int f1() { return x+y+a;}
int f2() { return x+y+a+1;}
int f3() { return x+y+a+2;}
int f4() { return x+y+a+3;}
int f5() { return x+y+a+4;}
int f6() { return x+y+a+5;}
int f7() { return x+y+a+6;}
int f8() { return x+y+a+7;}

typedef int (*fp)() ;

fp ftab[8] = {f1,f2,f3,f4,f5,f6,f7,f8};

//[8] = {f1,f2,f3,f4,f5,f6,f7};

void TEST()
{

for(int i=0; i<1000*1000*30; i++)
{
x++; y--; a=i;
if(i&7==0) testi+=f1();
else if(i&7==1) testi+=f2();
else if(i&7==2) testi+=f3();
else if(i&7==3) testi+=f4();
else if(i&7==4) testi+=f5();
else if(i&7==5) testi+=f6();
else if(i&7==6) testi+=f7();
else if(i&7==7) testi+=f8();
}

}

void TEST2()
{

for(int i=0; i<1000*1000*30; i++)
{
x++; y--; a=i;
testi+=ftab[i&7]();
}

}

TEST 45 ms TEST2 455 ma - i dont get it, i was hoping the array of pointers would be faster..but im to weary to see the assembly etc

(array of pointers avoid if logic so it should be faster for that noticably imo (in theory) byt maybe jumping thru pointers makes cache problems or what)

testing on 10+ year old cpu (i got more new comp but more rarely use it as i like the old)

Am 01.07.2023 um 16:20 schrieb fir:
> i think there is probably a need of clamp operator
> in c
> the question is how it could look like
> it could be something like
>
> x = <0|x|650> but with some better operator
> one alos may think of some keyword like CL
> (clamp left) and CR (clamp right
>
> x = x CL 0;
> x = x CR 650;
>
> but how it should look better in details i dont know
>

This type of clamping is used too seldom to require a special
operator for it. Imagine you need this once for a thousand
lines of code. A special operator would be rather confusing.
The language is already perfect in that respect.

niedziela, 2 lipca 2023 o 16:36:29 UTC+2 Bonita Montero napisał(a):
> Am 01.07.2023 um 16:20 schrieb fir:
> > i think there is probably a need of clamp operator
> > in c
> > the question is how it could look like
> > it could be something like
> >
> > x = <0|x|650> but with some better operator
> > one alos may think of some keyword like CL
> > (clamp left) and CR (clamp right
> >
> > x = x CL 0;
> > x = x CR 650;
> >
> > but how it should look better in details i dont know
> >
> This type of clamping is used too seldom to require a special
> operator for it. Imagine you need this once for a thousand
> lines of code. A special operator would be rather confusing.
> The language is already perfect in that respect.

not really.. clamping, min /max ids used relatively often,
for sure more often this say xor..probably abut the same as or and or shifts..once per a thusand is not so rare btw as it would be once a 3 days of work (when i code its about 10k lines a month) (but then i must rest its not to hold whole year 10k a month imo)

also abs/fabs and sign should be built in imo,s ame as error operator

foo() --> printf("error!");

-> is error operator here (my invention)

Am 02.07.2023 um 16:41 schrieb fir:
> niedziela, 2 lipca 2023 o 16:36:29 UTC+2 Bonita Montero napisał(a):
>> Am 01.07.2023 um 16:20 schrieb fir:
>>> i think there is probably a need of clamp operator
>>> in c
>>> the question is how it could look like
>>> it could be something like
>>>
>>> x = <0|x|650> but with some better operator
>>> one alos may think of some keyword like CL
>>> (clamp left) and CR (clamp right
>>>
>>> x = x CL 0;
>>> x = x CR 650;
>>>
>>> but how it should look better in details i dont know
>>>
>> This type of clamping is used too seldom to require a special
>> operator for it. Imagine you need this once for a thousand
>> lines of code. A special operator would be rather confusing.
>> The language is already perfect in that respect.
>
> not really.. clamping, min /max ids used relatively often,
> for sure more often this say xor..probably abut the same as or and or shifts..once per a thusand is not so rare btw as it would be once a 3 days of work (when i code its about 10k lines a month) (but then i must rest its not to hold whole year 10k a month imo)
>
> also abs/fabs and sign should be built in imo,s ame as error operator
>
> foo() --> printf("error!");
>
> -> is error operator here (my invention)

C++ has things like min(), max() and minmax() gerically, but
nothing like clamping; so it looks like that clamping isn't
needed that often. And there's the ternary operator which you
can nest like that:
clamped = value >= min ? value <= max ? value : max : min
That has a good readabity so you won't need clamping.

niedziela, 2 lipca 2023 o 16:48:40 UTC+2 Bonita Montero napisał(a):
> Am 02.07.2023 um 16:41 schrieb fir:
> > niedziela, 2 lipca 2023 o 16:36:29 UTC+2 Bonita Montero napisał(a):
> >> Am 01.07.2023 um 16:20 schrieb fir:
> >>> i think there is probably a need of clamp operator
> >>> in c
> >>> the question is how it could look like
> >>> it could be something like
> >>>
> >>> x = <0|x|650> but with some better operator
> >>> one alos may think of some keyword like CL
> >>> (clamp left) and CR (clamp right
> >>>
> >>> x = x CL 0;
> >>> x = x CR 650;
> >>>
> >>> but how it should look better in details i dont know
> >>>
> >> This type of clamping is used too seldom to require a special
> >> operator for it. Imagine you need this once for a thousand
> >> lines of code. A special operator would be rather confusing.
> >> The language is already perfect in that respect.
> >
> > not really.. clamping, min /max ids used relatively often,
> > for sure more often this say xor..probably abut the same as or and or shifts..once per a thusand is not so rare btw as it would be once a 3 days of work (when i code its about 10k lines a month) (but then i must rest its not to hold whole year 10k a month imo)
> >
> > also abs/fabs and sign should be built in imo,s ame as error operator
> >
> > foo() --> printf("error!");
> >
> > -> is error operator here (my invention)
> C++ has things like min(), max() and minmax() gerically, but
> nothing like clamping; so it looks like that clamping isn't
> needed that often. And there's the ternary operator which you
> can nest like that:
> clamped = value >= min ? value <= max ? value : max : min
> That has a good readabity so you won't need clamping.

noy much good
the question is hovever what operator to use

maybe x]b for min and a[x for max , a[x]b for clamp..thsi is possibly the shortest