#33 how does round work?

[Stefano]

Hi,

I've noticed this behaviour about the rounding precision in both v2.2.6 and 2.2.8 as well: a number which last figure is 5 get rounded towards 0. For example:

(precision = 2)
1.04 -> 1
1.05 -> 1
1.06 -> 1.1

I usually round my numbers applying the convention that figures {0, 1, 2, 3, 4} get roundet towards 0 and figures {5, 6, 7, 8, 9} get rounded away from 0. This is, for example, how it works in excel if you apply number format to a cell.

But I also recently discovered that are others way to round a number (excel's power query by default rounds towards even, which I found crazy!) so it could not be a bug at all, but just an alternate way.

In the latter case, there is a way to specify how to round a number, so I can apply the convenction I am more confortable with?

[Stefano]

I want to clarify that in my opinion the value 1.05 in the example above should be rounded to 1.1

[Jan Rheinlaender]

Hi Stefano,

could you give me a complete example? I tried

%%ii @x@ EQDEF x = 1.05
%%ii {precision=2} PRINTVAL {x}

But this rounds to 1.1 as expected, on my installation.

My understanding of the rounding behaviour is the same as yours - last digit 5 is rounded up.

[Anonymous]

Guess what, 1.05 behave diffrently from the rest of the number I've tested!

In the attached image you can see the 1.05 get rounded to 1.1, but 2.05 get rounded to 2 and so on

[Jan Rheinlaender]

I'm afraid this is not really a bug, but a feature of digital computers. You can understand what happens if you set precision to 20 or larger.
Because numbers are stored internally in binary format, some decimal numbers do not have an exact representation. So when converting back to decimal format (for printing), things like you describe happen.

Floating point numbers are by definition inexact. You can specify exact numbers as fractions, e.g. x=105/100.

[zeon_account_will_be_deleted]

Yeah, but what about other apps?

[Jan Rheinlaender]

Obviously iMath does too much conversion between number types. I rewrote the whole code for printing numbers and things should be better now. But there might be new bugs. Maybe you can help by checking this file and finding more examples?

See 2.2.9~beta3 which I just uploaded

[zeon_account_will_be_deleted]

LO+imath 2.2.8 crashes, when I try to format iFormula (any of them in the document), because of new format option. I suppose, other versions might crach LO too.

In imath2.2.9~beta3 I didn't find any bugs

[Jan Rheinlaender]

Do you mean crash because of lowsclimit and highsclimit in 2.2.8? They are not defined in 2.2.8 but of course it shouldn't crash anyway.

[zeon_account_will_be_deleted]

Yes, because of highlimit. But I think old imath versions should ignore unknown options or just report about them. Not to crash.

[Jan Rheinlaender]

I agree. But I haven't be able to reproduce a crash in 2.2.9 beta (e.g. with the option "eqsplit" which is also scheduled to be implemented one day, like highsclimit).

I don't want to change old versions of iMath to avoid the crash. But if you can reproduce the crash in 2.2.9 I will fix it.

An idea: iMath should show a warning if you open a file that was created in a later version. Then people will not be surprised if there is a crash. They should update iMath first and then open the document.

[zeon_account_will_be_deleted]

Hi Jan!

An idea: iMath should show a warning if you open a file that was created in a later version.

Why not? Good solution.

[Stefano]

Hi,

with 2.2.8

I can confirm that, with 2.2.8, LO crashes upon trying to format something. About the warning idea if a file is created with a later version of iMath: I would prefer that in addition to the warning, iMath will stop working in order to avoid any crash.
I had my fair amount of crashes using LO (iMath related and non) and they are, always, not welcome.

with 2.2.9-Beta3

I found a difference in behaviour between 2.2.8 and 2.2.9 version:

1. let's say I have a number: x=1.23456
2. I set the precision to 0:
   1. In 2.2.8 the result is x=1
   2. In 2.2.9 the result is x=0

More blatantly, if I set the number to x=19.23456 and precision=0 the result become x=00 which is meaningless.

I also tried to combine with fixedpoint=true and exponent=1 with various results (see attached file). By my extimation, the expression with fixedpoint=true option are evaluated correctly.

I also tried to open the same file with 2.2.8 and, as you can see in attached file, the expression with precision=0 are evaluated the same as precision=1. Most notably I get an error message "invalid string position" for any combination of position=0, exponent=1

(by the way, testing this stuff I got lots of crashes which I am not able to replicate with consistency; also I tried to test thing with the latest package of 2.2.8 "iMath-2.2.8-AOO.oxt", but I'm not able to install it: I've used a previous version I downloaded "iMath-2.2.8.oxt"; I'll open a proper bug ticket for that)

[Jan Rheinlaender]

Specifying precision=0 with fixedpoint=false makes no sense because you are asking for zero significant digits to be displayed. The fact that iMath-2.2.8 displayed 1 in this case should be considered a bug in that version.

Specifying exponent=1 is possible but does not make a lot of sense either.
The case x=1.23456 with precision=0; fixedpoint=true; exponent=1 is another which does not make sense. It is impossible to display this number correctly with these options.

I have added an error message for the probably most frequent case precision=0 with fixedpoint=false.

Thanks for testing all these cases. I have attached a test file which I use myself.

[Jan Rheinlaender]

Can this bug be closed?