Incorrect Modulo Calculation

Former user Account Deleted

``` 83^55 is a number with 106 decimal places - much more than the 80 some digits the engine can hold throughout an evaluation. As a result, a rounded value is fed into the mod operation - leading to your unexpected result. Besides replacing the engine by something more powerful, what can we do here? If mod was only defined on integers, the engine could simply reject an input too big. But mod has been generalized to work on floats as well, so just checking for big numbers would cripple SpeedCrunch in other respects. ```

Reported by `wolf.lammen` on 2009-07-01 15:46:40

2009-07-01T15:46:40+00:00

Former user Account Deleted

``` i know .. 83^55 is a big number, sorry! ;) But I think, giving the wrong result isn't the best way to handle such big numbers. I don't know how the modulo-computation is implemented now (haven't looked in the sources), but maybe the "binary exponentiation" could be a smarter way (for ints) - if it isn't yet!

```

Reported by `armin.widegreen` on 2009-07-01 16:08:14

2009-07-01T16:08:14+00:00

zanetu NA

``` Hi, I just encountered the same problem when trying out RSA examples. In RSA cryptosystem, modular calculation on such large numbers are quite common. :) I agree with armin.widegreen as to the inappropriateness of giving the wrong result. Is it a good idea to create a new function (eg modf) that is dedicated to floats and prompts the user to use the new function when he or she tries to use mod on floats? After all, integers are far more frequently used than floats in modular calculation and the correctness of integer calculation should be given first priority.

```

Reported by `zanetu` on 2010-01-15 06:35:33

2010-01-15T06:35:33+00:00

Former user Account Deleted

``` Speedcrunch essentially has a 'single-data-type' engine and this type is fixed to an 80 decimal digits floating point format. Built-in support for integers is very limited, covering just a few bitwise operations like AND or XOR. Prior to their execution, operands are converted to 256 bit integers, and results finally converted back to native floating point format. While I understand there is occasionally specialized need for arbitrary precision integer arithmetic, (as far as I am concerned) Speedcrunch in near future will not serve these needs, because it requires - a complete rewrite of the engine - a paradigm change in user interface, requesting users to be aware of and deal with the concept of a data type.

You can do integer arithmetic as long as you do not pass by the 256 bit limit. If you do, Speedcunch silently uses the floating point style arithmetic it was once designed for. 256 bit is enough for all every-day needs of computer scientists. Demands of cryptology require something different.

cheers Wolf ```

Reported by `wolf.lammen` on 2010-01-16 13:58:10