changing the base clobbers ans/loss of precision when saving variables

Issue #118 closed
Former user created an issue

Originally reported on Google Code with ID 118

What steps will reproduce the problem?
1. enter pi
2. change the display mode to hex and back to dec
3. enter ans*3

What is the expected output? What do you see instead?
expected approx. 9.42, got rubbish

Please use labels and text to provide additional information.
this bug is not tied to the expression ans*3, but occurs whenever ans is used.
This bug can be traced back to version 0.8.

Sorry to be the first to report a bug

Reported by wolf.lammen on 2007-11-21 13:31:56

Comments (9)

  1. Former user Account Deleted

    ``` While I was looking for this bug, I stumbled over another one. You can see its effect by doing the following: 1. assign 1/3 to a variable, say x 2. view it in full precision (50 digits) 3. make sure, variables are saved on exit 4. close SpeedCrunch 5. Open it again 6. evaluate x

    You can see that x is not 1/3 to full precision any more.

    When you exit SpeedCrunch, the list of variables is iterated and each is saved to a stream using a text line like `varname'=`value'. Here `value' is a string returned by the math engine. It is received using a FixedFormat call requesting a 100 digits output. While this was ok with the former engine, unfortunately, this call fails in two respects with the new engine. First, a request to 100 digits precision will not be executed any more, because the new engine, for efficiency, is configured to a limit 79 digits. Because the engine checks parameters prior to execution, it sees it internal buffers would overflow with 100 digits, and refuses to do the operation. Instead you get a default answer, and that is a 20-digit scientific format encoding. That accounts for the observed loss of precision. Second, a fixed format is in principle not appropriate for the wide range of numbers any more. A value like 1e100000000 would require 100 MByte in fixed format - that's beyond discussion. So better choose FormatScientific with a the right precision constant DECPRECISION exported by the engine. Fixed this in trunk. ```

    Reported by `wolf.lammen` on 2007-11-24 22:31:43

  2. Former user Account Deleted

    ``` ok, I debugged SpeedCrunch and I found the reason why ans gets clobbered. First, this happens only if an option like 'Save variables on exit' is set. If you change the display mode by pushing one of the radio buttons, an event radixChange is created. That procedure looks at the state of the radio buttons, sets the format setting appropriately, and then calls a function setView to make the settings take effect. SetView in turn saves the complete state to disk (BTW, this is a side effect best to be avoided). The variables are saved as well as requested by 'Save variables on exit', as text strings and in a way that they are readable by the evaluator: `varname`=`value`. Then the state is reloaded, the saved variables assignments are passed each to the evaluator for execution. This has the (intended) effect that the variables are assigned the saved value, and the side effect, that ans is set to the saved value as well, unfortunately overwriting whatever is stored there. So, after reloading, ans contains the value of the last restored variable. ```

    Reported by `wolf.lammen` on 2007-11-25 23:55:42

  3. Former user Account Deleted

    ``` IMHO, the whole thing needs to be sorted out. Anyway I provide a makeshift fix, until somebody else finds a nicer solution. For the time being in trunk only. ```

    Reported by `wolf.lammen` on 2007-11-26 10:19:16

  4. Former user Account Deleted

    ``` fixed in 0.9 as well ```

    Reported by `wolf.lammen` on 2007-12-06 11:27:21 - Status changed: `Fixed`

  5. Former user Account Deleted

    Reported by `wolf.lammen` on 2007-12-06 11:32:50 - Labels added: Milestone-0.10

  6. Log in to comment