Allow users to change scientific notation to other format

[GoogleCodeExporter]

Add preference option to allow users to change the formatting of scientific 
notation.

Discussion:

Short answer:  I haven’t provided this an an option
in the program yet.  It defaults to scientific notation
for longer numbers.

Longer answer:
It would not be too difficult to provide an option to
change number formatting.  However, there are a
few questions/complications with doing so:

1) Does the preference affect just the current view?
2) Does the preference affect all views of that type?
3) Should the preference be program wide?
4) Should the preference be saved with the project file?
5) Should the preference be saved in some sort of
  new preference file for the user and if so where
  will that file be stored?

I have long wanted to provide more preferences
for users, but when there are more preferences the
need to store them permanently somehow would
be needed.

Original issue reported on code.google.com by jkosc...@asu.edu on 16 Oct 2014 at 2:01

[GoogleCodeExporter]

Our preference is to deal with this and other related preferences such as 
colours, font size, etc in a preference file.

Original comment by mmcc...@gmail.com on 16 Oct 2014 at 2:06

• Changed state: Accepted
• Added labels: Milestone-Release_Future, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

That would be great to add it to the list.   Eventually,
it would make sense to gather together a number
of small features that would be best handled by
the existence of a “user preferences” file.  The
first issue would be figuring out how and where
to store the file.  After that, it would be fairly straight
forward to start adding various options to the file.

Some things that would be nice to save in a
preference file:
- number formatting
- font size
- color preferences for various views
- possibly font encoding
- possibly commonly used options for particular views
  such as: show/hide regimes in scatter plot

I didn’t realize that a lot of people using GeoDa aren’t
familiar with scientific notation.  That does raise the
priority some for sure.  These are the things that
I don’t get to know about easily since I’m not teaching
courses with GeoDa.  I really appreciate having
this issues brought to my attention.

Original comment by jkosc...@asu.edu on 16 Oct 2014 at 2:07

[GoogleCodeExporter]

Just to add a few more ideas for number formatting in a preference file:
- add system-wide default for number of significant digits
- add system-wide override for "." vs "," in real number encoding.  Right now 
we rely on localization preferences in the OS, but there could easily be 
instances where this fails it would be nice to provide the user with an 
override.

Original comment by mmcc...@gmail.com on 16 Oct 2014 at 2:12

[GoogleCodeExporter]

Regarding the scientific notation thing.  I’m guessing that
many users are not familiar with seeing the
“e” symbol in the numbers.  This is understandable since
it’s a convention that has been necessitated by computers
not being able to easily display superscripts in the past.
In grade 9, I learned how to read numbers like:

1.53 x 10^3  (with a real superscript 3, not “^3”)

1.53e10  is the default short-form provided by the system.

A years ago, I looked into formatting with real superscripts.
in the GeoDa Table using wxWidgets.  It seemed to be
possible theoretically, but I wasn’t able to get it working
and could find no example of anybody else doing it.

Original comment by mmcc...@gmail.com on 16 Oct 2014 at 2:38