Bug SS-3515
1 vote

significant digits option gets lost

Created by Martin Kraska on 3/14/2018 7:00 PM Last Updated by smath on 3/19/2018 6:26 PM
%
 (hrs)
Logged: 0   (hrs)

 Description

The attached file is created in 6622 and saved. When opened in 6647 then the significant digits option is lost.

Both program versions have the same settings.

In the sm-file, no particular settings info is stored for the result region. Then I would expect the program presets to be applied, which isn't the case because the significant digits option is activated in both program versions.

<region id="3" left="0" top="99" width="164" height="41" color="#000000" bgColor="#ffffff" fontSize="10">
    <math>
      <input>
        <e type="operand">F.x</e>
        <e type="operand">2</e>
        <e type="operator" args="2">^</e>
        <e type="operand">F.y</e>
        <e type="operand">2</e>
        <e type="operator" args="2">^</e>
        <e type="operator" args="2">+</e>
        <e type="function" args="1">sqrt</e>
      </input>
      <result action="numeric">
        <e type="operand">4.47</e>
        <e type="operand" style="unit">N</e>
        <e type="operator" args="2">*</e>
      </result>
    </math>
  </region>

In the settings object, a selection of settings is stored (significant digits option is missing, perhaps that is the bug)

    <calculation>
      <precision>3</precision>
      <exponentialThreshold>5</exponentialThreshold>
      <fractions>decimal</fractions>
    </calculation>

What settings are stored here, is that the presets of the program acting upon save of the file?

Is that some file-specific pre-set?


    smath (Monday, March 19, 2018 6:26 PM) #

Just tried 0.96.4884: both Trailing zeros and Significant Figures taken from current preset (when NumbersOutputFormatDisambiguation=CurrentPreset) - everythink works as expected.

    smath (Monday, March 19, 2018 6:22 PM) #

No, I did not. Unfortunately I have no Maxima setup.

I've tested on files produced by 0.98.6179 - works ok.

    Martin Kraska (Thursday, March 15, 2018 9:03 PM) #

Did you try the "Beispiel Solve.sm" file? It is generated in 0.96 (very old) and has no trailing zero tags at any region.

    smath (Thursday, March 15, 2018 8:56 PM) #

>preset no trailing zeros is not

Trailing zeros cannot be handle by NumbersOutputFormatDisambiguation because trailing zeros set implicitly:

    <math trailingZeros="true">

Again, there are known problems with calculation settings in 0.99.6622.

Try earlier versions to see that both: significantDigitsMode and trailingZeros works correctly.

    smath (Thursday, March 15, 2018 8:46 PM) #

>switching on significant digits also switches on trailing zeros

This is by design. By default results should display trailing zeros when significant digits mode is on.

 

Will check regarding trailing zeros (I did not test it).

    Martin Kraska (Thursday, March 15, 2018 8:32 PM) #

Doesn't work for the attached file

It starts with

<?application progid="SMath Studio Desktop" version="0.96.4909.6802"?>
<regions>
  <settings>
    <identity>
      <id>314b909a-9e19-4d4f-a067-fdb377aef45c</id>
      <revision>9</revision>
    </identity>
    <calculation>
      <precision>4</precision>
      <exponentialThreshold>5</exponentialThreshold>
      <fractions>decimal</fractions>
    </calculation>

my current preset is "no trailing zeros", "significant digits on"

NumbersOutputFormatDisambiguation=CurrentPreset is copied to the settings file

preset significant digits on is respected, preset no trailing zeros is not.

I also experience that switching on significant digits also switches on trailing zeros (which I usually don't want) Maybe, these issues are related?
 

    smath (Thursday, March 15, 2018 7:57 PM) #

New option added: NumbersOutputFormatDisambiguation=CurrentPreset (can be added into settings.inf content as a separate line)

New SMath Studio nightly build released.

    Martin Kraska (Thursday, March 15, 2018 7:05 PM) #

I have a lot of files which were modified using version 6622 (for the new handbook version, to be based on the latest stable version).

As for the problem you mentioned:

I see that it is important that legacy files display as initially generated in new versions. This implies that missing format options are set as it was default in previous versions which didn't provide choice for that option. That is your current design choice.

An alternative would be to display new options according to the current settings. If I want a legacy file to be displayed unmodified, I would have to adjust the presets to their legacy values. Once saved again in the new version, the display will become independent of presets, as now all options are stored.

having a choice how to handle missing format options in legacy files, would perhaps be interesting also for other users. The options would be "Legacy defaults" or "Current settings"

If that is not going to be implemented, I won't be lost. I hope to succeed by copying a full <calculation> block with appropriate presets into the .sm-source (not tested yet).

    smath (Thursday, March 15, 2018 12:33 PM) #

Martin,

Your understanding of the output number format is correct. This is how it is implemented, yes.

Regarding "In order to handle legacy files more consistently, I propose to apply the current presets to all format elements, which aren't defined in the file.": unfortunately I can't do it because this will break worksheets created before new formatting type was developed.

In other words, new SMath Studio version should always display results as they were initially designed/produced in previous versions.

Simple example: if in initial file regions a=0.0033 and b=0.0055 is located on the same line next to each other and new SMath Studio version will display them as a=0.003333 and b=0.005555 because Significant Figures mode turned on in your preset, then these two regions will be overlaped. It become a real problem for large files.

 

I'm really sorry about this issue in 0.99.6622 - it is very important to never make it happen again.

Last Months I've touched many parts of SMath Studio which was never changed since their first implementation and unfortunately their quality was very poor. That is why I had to rewrite many code (which was not covered by automated tests) and not only rewrite... I had to implement something new or improve performance, so complexity of these parts increased.

    Martin Kraska (Thursday, March 15, 2018 11:35 AM) #

Let me try to describe my understanding of how formatting is/should be applied:

  • if a file is loaded, then the numeric  results are displayed based on what is stored in <calculation> and <math>, no matter what the presets of the program instance are.
  • if a file is stored, the current presets are stored in <calculation> and the <math> regions store any setting different from the preset. Thus, what is stored in the <math> regions depends on the current presets.

Consequences:

  • The display of a given file does not depend on the presets in the current instance
  • The display of existing regions isn't changed by changing the presets
  • The presets only affect the display of new regions
  • Changing the presets and saving a file may lead to massive changes in what attributes each individual <math> region stores.

is that correct?

In order to handle legacy files more consistently, I propose to apply the current presets to all format elements, which aren't defined in the file. In the reported bug this did not happen. Obviously, some program-internal immutable defaults have been applied (disabled significant digits mode).

BTW: I think, the natural place for storage of region-specific result attributes would be the <result> tag. Also, storage would only be necessary if numeric results exist.

To reset a region to the current defaults, I found that you have to copy the expression and paste it to the canvas and evaluate it, i.e. in fact by creating a new region of the same contents.  This would be a handy toolbar button: Apply default numeric format.

 

    smath (Wednesday, March 14, 2018 8:56 PM) #

Unfortunately this is an error of 0.99.6622 which was fixed some time ago.

If you try to save a file using 0.99.6647 you will see that Significant Figures is a setting of a file:

 
    <calculation>
      <precision>4</precision>
      <exponentialThreshold>5</exponentialThreshold>
      <trailingZeros>false</trailingZeros>
      <significantDigitsMode>true</significantDigitsMode>
      <roundingMode>0</roundingMode>
      <fractions>decimal</fractions>
    </calculation>
 
 
This is what should be. But the error of 0.99.6622 is that significantDigitsMode is not a part of a file.
 
Next Stable SMath Studio version comming soon.