Since it looks like you wish to work with quadrants why not use the integer part and add the fractional part again ?

e.g.:   if q in [1,3] then     b := trunc(alpha) MOD 90   else     b := 90-(trunc(alpha) MOD 90);       beta := b + frac(alpha);

where b is of type integer.

« Last Edit: October 14, 2016, 07:25:10 pm by molly »

« Last Edit: October 14, 2016, 07:51:33 pm by Xor-el »

A better question - how can I sort it

??

That is indeed the better question

unfortunately to which i do not know a simple answer (in case really want to keep using mod).

Since it looks like you wish to work with quadrants why not use the integer part and add the fractional part again ?

e.g.:

if q in [1,3] then   b := trunc(alpha) MOD 90 else   b := 90-(trunc(alpha) MOD 90);

    beta := b + frac(alpha);

where b is of type integer.

Thanks Molly, you've understood my needs perfectly again

Thinking in the car, this solution did cross my mind but Xor-el's link may well be a good 'fix' - though I wasn't anticipating the option to have both arguments as 'reals' that's no bad option.

FPC 3.0.0 - Lazarus 1.6 & FPC 3.2.2 - Lazarus 2.2.0 Win 7 Ult 64

Why doesn't MOD accept a 'single' as the first argument?

That is very simple. If you do mod "x", a floating point might be to imprecise to represent anything in the 1.."x" range.

if you imagine x:=x mod 30 as x:=x - x/30 and division as repeated subtraction, then you get

1. y:\=1E30;
2. while y>30 do
3. y:\=y-30.0;

which could be a forever loop, or have a random result.

Well, there is a flaw in my design. Did you spot it already ?

This read a lot better (at least the results makes a bit more sense now):   if q in [1,3] then     beta := (trunc(alpha) MOD 90) + frac(alpha)   else     beta := 90-(trunc(alpha) MOD 90) - frac(alpha);

Well, there is a flaw in my design. Did you spot it already ?

This read a lot better (at least the results makes a bit more sense now):

if q in [1,3] then   beta := (trunc(alpha) MOD 90) + frac(alpha) else   beta := 90-(trunc(alpha) MOD 90) - frac(alpha);

I hadn't had time to properly evaluate the code but I have now - You obviously do the same as I do - - - - try to minimize code by re-use - doesn't always work

I've written a function based upon the TByteSize link so that is now in my armoury as F_MOD.

FPC 3.0.0 - Lazarus 1.6 & FPC 3.2.2 - Lazarus 2.2.0 Win 7 Ult 64

Prime candidate for a nice operator overload,something like:

1. operator mod(const a,b:double) c:double;inline;
2. begin
3. c:\= a-b * trunc(a/b); //trunc was correct, not floor so I editted this back in
4. end;
5. //test: sign must be that of a
6. begin
7. writeln( 18.5 mod 4.2 :4:8); // 1.70000000
8. writeln( -18.5 mod 4.2 :4:8); //- 1.70000000
9. writeln( 18.5 mod -4.2 :4:8); // 1.70000000
10. end.

Compatible with C fmodf

1. include <stdio.h>

2. include <math.h>

3. int main()
4. {
5. printf("%f\n", fmodf(18.5f, 4.2f));
6. printf("%f\n", fmodf(-18.5f, 4.2f));
7. printf("%f\n", fmodf(18.5f, -4.2f));
8. }

And java:

1. public class Fmodj{
2. public static void main(String[] args){
3. System.out.println( 18.5f % 4.2f );
4. System.out.println( -18.5f % 4.2f );
5. System.out.println( 18.5f % -4.2f );
6. }
7. }

I've asked for inclusion in math unit on mantis.

« Last Edit: October 15, 2016, 01:13:56 pm by Thaddy »

Specialize a type, not a var.

!!! Well !!!

I now feel justified in asking what I sometimes consider naïve questions.

It seems even these can sometimes prompt potential improvements in a constantly evolving product.

FPC 3.0.0 - Lazarus 1.6 & FPC 3.2.2 - Lazarus 2.2.0 Win 7 Ult 64

You were right in asking. I think this has been an oversight indeed.

Either math should have an fmod function or this operator can be added to either system or math. C uses a function for fmodf Java uses an overloaded operator % for modulo floats. Because of that difference I added the demo code in C and Java.

My vote is for the operator in system, because it does not rely on math. I hope the suggestion will be added by devs. Note it is not Delphi compatible (Delphi can't overload stand-alone operators yet) but hey, who cares

« Last Edit: October 15, 2016, 12:57:51 pm by Thaddy »

Specialize a type, not a var.

I don't think it would be wise to add it as an inbuilt overloaded operator because it would cause collisions with other floating points like extended, single or double. remember unlike pascal, c, csharp and java has the ability to add either 'f' or 'd' to floating points literals (not variables) and that forces the compiler to enforce that value to the specified type.

below is an illustration

which version of the overloaded operator am I calling with this codes? is it the extended, double or single variant?

2.5 mod 1.2 3.6 mod 4 5 mod 6

you see, there will be precision issues.

I prefer we define it as an intristic (or inline) method in the 'system' unit with various suitable overloads. this is my personal view.

« Last Edit: October 15, 2016, 01:31:17 pm by Xor-el »

I don't think it would be wise to add it as an inbuilt overloaded operator because it would cause collisions with other floating points like extended, single or double.

You obviously don't know how it works. No it does not cause collisions because the highest definition possible is chosen. And this is by convention in the math unit. e.g. in the math unit the operator would be defined as:

1. operator mod(const a,b:float) c:float;inline;
2. begin
3. c:\= a-b * trunc(a/b);
4. end;

Why? because fpc has a Type Float = MaxFloatType; // determined by the compiler So there is and never will be a collision.

What you CAN do for a useless bit of speed optimization is add some more overloaded operators. The result of the single overloaded operator that can handle all types, including integers for the "b" parameter, is sufficient. The current overloaded operators in math are overloaded once. Using MaxFloatType on all platforms.

I actually tried to add separate operators, but soon decided it was pointless since mod is an expensive operation anyway. After I saw that overloaded operators in math.pp had just one implementation I submitted my version as above accordingly.

No collisions.

Of course you are free to add additional overloads in your own code but these do not belong in the standard rtl.

« Last Edit: October 15, 2016, 01:43:23 pm by Thaddy »

Specialize a type, not a var.

well I have not taken a peek at math.pp but using what you said about 'float' type and the compiler figuring out the maxfloattype, I guess that is OK.