There are also dictionary preview inconsistencies for map, floor, union, ceiling - seems to be a sampling issue?

Well spotted, will need to investigate!

I created a code-in task out of this, in case you want to give it a try :)

I have just done a bit of hunting. and the really odd thing about the whole remainder situation, is that it seemed to be converting it to an integer on Linux and keeping it floated on Windows.

I took a look through the function calls, and KAlgebra calls Analitza. In turn Analitza runs the case in operations.cpp line 65. On line 67 it runs "oper->setValue(int(remainder(a, b)));". The pass through the int is what is making giving it the different functionality in Linux.

The next question is "why is it not effecting the windows version of KAlgebra", but I think the answer to that is because the Analitza version, or the KAlgebra version are not the latest when installed through the kde windows installer. I checked the KAlgebra about dialogue on windows and it says "Version 0.11 Using KDE Development Platform 4.10.2" and on Arch Linux "Version 0.11 Using KDE Development Platform 4.11.4".

So what changed since the old version? I think it has something to do with a change made on April 8th 2013 in git commit 3a7f33e23c84dd27c698f86ac78a27c42c06d93b . In the operations.cpp on line 64-66. Before this commit the format of the 'oper' was set to an integer, but the math was still done floating point. After the change the math was converted to an int before setting to the 'oper' value.

So what can be done?
Nothing I guess, if the functionality seen in the later Linux version is the 'expected' functionality, then just wait for it to roll into stable on windows. Otherwise this is a regression and it needs to be fixed.

I rolled back the analitza repo locally and compiled. Running calgebra I had the following output:
"./calgebra
>>> rem(2.5,5)
2.5 
>>> "
Wheras the latest version of calgebra runs as follows:
"calgebra 
>>> rem(2.5,5)
2 
>>> "

This shows that the change mentioned in the above comment is what is causing this behaviour between different versions of Analitza (and also why it is different on windows if my assumption about the old branch used on windows is true)

Nice hunting! I did some investigating earlier and I think it's that
commit too - there's really no way for it to return it otherwise if
it's casted to an integer.

On 12/14/13, Benjamin Kaiser <benjaminjkaiser@gmail.com> wrote:
> https://bugs.kde.org/show_bug.cgi?id=328368
>
> --- Comment #5 from Benjamin Kaiser <benjaminjkaiser@gmail.com> ---
> I rolled back the analitza repo locally and compiled. Running calgebra I
> had
> the following output:
> "./calgebra
>>>> rem(2.5,5)
> 2.5
>>>> "
> Wheras the latest version of calgebra runs as follows:
> "calgebra
>>>> rem(2.5,5)
> 2
>>>> "
>
> This shows that the change mentioned in the above comment is what is
> causing
> this behaviour between different versions of Analitza (and also why it is
> different on windows if my assumption about the old branch used on windows
> is
> true)
>
> --
> You are receiving this mail because:
> You reported the bug.
>

Ok, so it's just that kde-windows version is too old... Nice work!!