Add option to control positioning of maybe numbers

[GoogleCodeExporter]

Got this email from a user, one or two others have also appeared:

"
Previously, on my Samsung Galaxy Tablet, the  "maybe" numbers appeared in a 
legible consecutive row in the lower left corner of each square. Scanning the 
entire puzzle for matches and relationships was thus visually easy.

With this update the "maybe" numbers are in three rows: 123, 456, and 7.
Instead of being tucked neatly in the corner, the numbers occupy much of each 
square.
The puzzle is thus confusing to look at and analyze.
"

Perhaps worth having both as an option?

Original issue reported on code.google.com by bbux...@gmail.com on 18 Jan 2011 at 12:29

[GoogleCodeExporter]

User feedback is what drives most of the changes, so agreed we should include 
an option:

Added a checkbox option: "Maybes in 3x3 grid".
If this is unticked, it will display the maybe numbers exactly(*) like it used 
to in V1.6.

Since the number of options is growing, I also put them into Categories.

(*) except the maybe numbers are now sorted in numerical order, regardless of 
the order they are input. So previously, if you entered '6', '7' & '3', it 
would display "673", but now it displays "367".

Revision 68

Mathdoku v1.8 Beta 5 available from download page

Original comment by em...@srlee.com on 19 Jan 2011 at 10:16

• Changed title: Add option to control positioning of maybe numbers
• Changed state: Started
• Added labels: Milestone-Release1.8, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

V1.8 released to Market

Original comment by em...@srlee.com on 23 Jan 2011 at 1:49

• Changed state: Fixed

[GoogleCodeExporter]

Before the numbers were arranged into the 9x9 square, I used to use the order 
of the numbers to record hints - for example, if I had used some scheme that 
insured that the numbers entered were limited to the penciled numbers such as 
exhaustive search or mathematical proof, I'd enter the numbers in ascending 
order, while if the numbers types in were simply excluded by eliminations I'd 
put them in descending order.  A simple example of the first sort would be a 
group of three that had to multiply to 35.  The three numbers are 1, 5, and 7.  
We know that those numbers are the only numbers because we have factored to 
primes, so they would be entered in ascending order.  An example of the latter 
would be three numbers adding to 18 in a column where 5 and 7 were eliminated.  
 I would type 9864321.  That would be a clue to me to go and redo it - and when 
I ran the combinations to exclusion I'd discover that there were no 
combinations that used 2 once a 5 and 7 were eliminated (I have a "calculator" 
written in D that runs down those possibilities. Currently porting it to Java 
with the eventual goal of moving it to Java.)  But sometimes I do the puzzles 
by hand, and that means that I would like to have the original ordering. 

These days, I usually do 9x9 puzzles.  The numbers are small emough that if I 
can't have ordering, there is no use in the linear layout as I can match the 
tiny numbers up by presence or absence of the number...

In an ideal world: The original order of entry would always be retained, with a 
second click removing the number and any newly clicked numbers added to the 
end. If the numbers were displayed in a 3x3 array, this would not alter the 
entry order.  When the numbers were displayed in 3x3 they would be displayed 
sorted, and if 3x3 was turned off, then the entry order would be restored...and 
this would happen whether or not the numbers were entered while 3x3 or linear 
display was in effect.

Am I greedy?  I have shown this program to people and they have refused to use 
it because "they want to pencil more notes than just numbers" and in order to 
make them happy, a long press on the number square would have to open a note 
:-).  

Now I have to admit that I have not missed the notes as much since I wrote my 
calculator because I can easily do exhaustive analysis so I don't have the need 
for the descending exhaustive grouping. The calculator takes cage shape, 
positional excludes, and even things like numbers that have to be in one of 
several positions, or numbers that may not appear in certain positions in 
combination, so the analysis is actually fairly exhaustive (I am purposely 
stopping short of writing a solver - it does not automatically correlate cages 
- it operates on one cage at a time and you have to move constraints as 
needed,. But I used to use a up and down penciling to indicate combinations, 
like when you have two squares that add to 7 - I might enter 615243 so that the 
grouping was obvious.

Original comment by simic...@gmail.com on 28 Mar 2011 at 3:03

[GoogleCodeExporter]

This issue will be closed as meeting the original requirement of making the 
maybe grid optional. There is a major redesign of the UI being looked at for 
V2.0. This issue (ordering of maybe numbers & cell notes) will be considered as 
part of the redesign.

Original comment by em...@srlee.com on 27 Mar 2013 at 1:20

• Changed state: Verified