# '=ROUND( 5.1234E-306, 309 )' -> #NUM! - why? - wrong constants as limits in ROUND, ROUNDUP and TRUNC ( ROUNDDOWN )?

If I understand correctly ROUND, ROUNDUP and TRUNC ( ROUNDDOWN ) intend to neglect excessive values for 'digits' and forward the origin unchanged ( because for e.g. doubles values outside -323 .. 308 would cause errors as exponents to 10 in the process of scaling ). But this does not work well for all cases:

```
' =round(5.1234E-306, 308) ' -> 5.12E-306
' =round(5.1234E-306, 309) ' -> #NUM!
' =round(5.1234E-306, 1024) ' -> #NUM!
' =round(5.1234E-306, 1025) ' -> 5.1234E-306
```

IMHO this evolves from using GNM_MAX_EXP and GNM_MIN_EXP as limits which are defined by (L)DBL_MAX_EXP and (L)DBL_MIN_EXP which are the max meaningful **base-2** exponents. I think the intention was to use (L)DBL_(MIN/MAX)_**10**_EXP.

( additional: maybe it is meaningful to round in the range of subnormals too instead of passing unchanged. For this larger exponents would have to be allowed ( 309 ... 324 resp. 4932 ... 4951 ), and with these to be calculated differently. E.g. `' / 10^-309 '`

instead of `' * 10^309 '`

would work. )

( GNM_MAX_EXP is also used in `plugins/fn-financial/functions.c`

and `src/mathfunc.c`

, for the first I assume MAX_10_EXP would fit better, for the second I don't know. )

Tested with gnumeric 1.12.50 ( kali distro ), a clean 1.12.53 from around 2022-05-06, and a lightly patched ver. from around 2022-06-07.

LO Calc passes unchanged for e.g. `' =ROUND(5.1234E-306, 309) '`

-> `5.1234E-306`

, which is mathematically 'suboptimal'.