EPT[Mahjong]Tenhou Thread - Page 25
| Forum Index > General Games |
|
Benawii
United States51 Posts
| ||
|
Rhaegar99
Australia1190 Posts
| ||
|
teplofizik
Russian Federation13 Posts
Allow generate tables for graph plotting (in external program), finding games by many parameters (yaku, player's stats, balance, hand cost, opened sets count and etc), paifu generation, stats file generation (for statistical analysis in external programs like excel) and some other things. | ||
|
Hesmyrr
Canada5776 Posts
wins twice on the dealer turn and be in commanding lead have family call you out of nowhere and drag me away from the keyboard come back hour late to see I got 4th place  | ||
|
Benawii
United States51 Posts
| ||
|
Hesmyrr
Canada5776 Posts
Never mind. Figured it out. | ||
|
spinesheath
Germany8679 Posts
On December 17 2013 06:15 teplofizik wrote: My console version of tenhou logs parser: TenhouViewer. Open source, of course. C#, .NET 3.5. Allow generate tables for graph plotting (in external program), finding games by many parameters (yaku, player's stats, balance, hand cost, opened sets count and etc), paifu generation, stats file generation (for statistical analysis in external programs like excel) and some other things. Funny, my current project is called TenView and does or will do similar things. Earlier in this thread I posted a program that can download and display replays too. I see you're using a recursive shanten calculation algorithm much like the one I use/used. How is it performing for you? I found it was too slow for my needs (statistical analysis over thousands of replays), so I developed an algorithm that uses state machines. The final shanten calculator takes up more than 20MB in memory and takes more than a day to build (hopefully it's not bugged so I don't have to build it again). | ||
|
Benawii
United States51 Posts
On December 18 2013 03:41 spinesheath wrote: Funny, my current project is called TenView and does or will do similar things. Earlier in this thread I posted a program that can download and display replays too. I see you're using a recursive shanten calculation algorithm much like the one I use/used. How is it performing for you? I found it was too slow for my needs (statistical analysis over thousands of replays), so I developed an algorithm that uses state machines. The final shanten calculator takes up more than 20MB in memory and takes more than a day to build (hopefully it's not bugged so I don't have to build it again). I actually also made my own program that computes the shanten number. It is based on a recursive algorithm with a few simple optimizations. From what I've seen it's always fast (<100 ms), but if you have some hands that are particularly difficult to compute I can try them on my program to see if it's still fast. I'm more interested in your state machines algorithm. By that you mean a look-up table, right? Is it a look-up table for all possible hands? There are tens of billions of unique 13-tile hands. You must be relying on many kinds of symmetry to get that down to 20MB. Initially I was trying to create a bot to play on Tenhou, because I believed that computers should be able to play much better than an average player seeing how simple my playing strategy is even though I'm already about average. I still believe this but my ideal algorithm would require some estimates about how other people play. Logs from real games help but I still need to put in a lot of effort to generalize very limited set of game logs to complete playing strategy. This is way more effort than I planned to put in for this little hobby, so in the end I had to give up. If anyone wants to work on this though, I'd be happy to share my ideas. | ||
|
teplofizik
Russian Federation13 Posts
On searching or paifying, this preparsed file loaded and used without any calculations (apart some exceptions). One replay's parsing time is least than 1 second. Of course, searching on complex parameters, for which we are need to analyze content of all hands in all games (forms search for example), is relatively slow. Uke-ire analyzing maybe slow too (+several shanten analysis for suitable tiles instead one), but at now I don't use it. I know about your replay viewer, but I wanted to find games from my tenhou log and build some graphs (rating graph at least, ron percent, agari percent, average payment, average place and etc) =) I measure perfomance of this shanten counting algorithm on 256097 hands (~500 replays) (1.61 GHz, x32): average: 486,01 us, maximum: 22176,00 us. Shanten counting algorithm was copied from 麻雀C言語プログラム集 site (ShiftJIS codepage), C++; and rewrited to C#. Additionally, C# version analyze waitings of tempai hand. It probably can be speed up by using functions in native code (x86, x64). Benawii, bot AI algorithms are interesting :3 I have small list of open source mahjong projects, some of them has AI. Maybe it be useful for you. | ||
|
spinesheath
Germany8679 Posts
On December 18 2013 08:36 Benawii wrote: I actually also made my own program that computes the shanten number. It is based on a recursive algorithm with a few simple optimizations. From what I've seen it's always fast (<100 ms), but if you have some hands that are particularly difficult to compute I can try them on my program to see if it's still fast. I'm more interested in your state machines algorithm. By that you mean a look-up table, right? Is it a look-up table for all possible hands? There are tens of billions of unique 13-tile hands. You must be relying on many kinds of symmetry to get that down to 20MB. The slowest hands for the recursive algorithm typically are the monocolored hands because there are a lot more possible combinations to consider. It's a Deterministic Finite Automaton (DFA). Or rather a combination of 9 DFAs of which 4 are selected in a first step and their results are combined into the input for the last one, which then outputs the shanten count. It's kinda like a look up table, but a lot better. It also works on both 13 and 14 tile hands, with a fairly natural extension of the term "shanten" for 14 tile hands as in - winning hand is 0 shanten - other hands are the best shanten you could get by discarding any one tile This part allows for easier calculation of Uke-Ire; instead of drawing one tile and counting the shanten for each discard, I get the correct value just by counting the hand after the draw. You can browse the code here. The actual calculator is ShantenCounter.cs. The rest is mainly code to create the ShantenCounter. On December 18 2013 17:49 teplofizik wrote: spinesheath, my idea - use preparsed logs (saved to xml) with all precalculated values as shanten number, waiting tile list, wall content and danger tiles for all hands. On searching or paifying, this preparsed file loaded and used without any calculations (apart some exceptions). One replay's parsing time is least than 1 second. Of course, searching on complex parameters, for which we are need to analyze content of all hands in all games (forms search for example), is relatively slow. Uke-ire analyzing maybe slow too (+several shanten analysis for suitable tiles instead one), but at now I don't use it. I know about your replay viewer, but I wanted to find games from my tenhou log and build some graphs (rating graph at least, ron percent, agari percent, average payment, average place and etc) =) I measure perfomance of this shanten counting algorithm on 256097 hands (~500 replays) (1.61 GHz, x32): average: 486,01 us, maximum: 22176,00 us. Shanten counting algorithm was copied from 麻雀C言語プログラム集 site (ShiftJIS codepage), C++; and rewrited to C#. Additionally, C# version analyze waitings of tempai hand. It probably can be speed up by using functions in native code (x86, x64). Benawii, bot AI algorithms are interesting :3 I have small list of open source mahjong projects, some of them has AI. Maybe it be useful for you. By "us" you mean microseconds? As in a maximum of 0.022176 seconds? That sounds quite fast, though to be honest I didn't even profile my current version yet heh. I'm not completely sure I understand why your algorithm works, I don't know if it works, anyways. I probably will look into it in detail when I have more time, maybe a week or so. At first glance I don't see how your algorithm deals with the boundary between colors in the CutMentsu method. It seems to try things like 9m12p as a row which obviously is not allowed. I'm also not sure it deals correctly with situations like closed: 1245m + some honors, called: 333m 6666m This hand doesn't allow both 12 and 45 to be considered penchan/ryanmen shapes because there only is a single 3m left and no 6m at all. My recursive algorithm "reserves" tiles that would be used for incomplete melds, I see nothing that would replace this functionality. On December 18 2013 08:36 Benawii wrote: Initially I was trying to create a bot to play on Tenhou, because I believed that computers should be able to play much better than an average player seeing how simple my playing strategy is even though I'm already about average. I still believe this but my ideal algorithm would require some estimates about how other people play. Logs from real games help but I still need to put in a lot of effort to generalize very limited set of game logs to complete playing strategy. This is way more effort than I planned to put in for this little hobby, so in the end I had to give up. If anyone wants to work on this though, I'd be happy to share my ideas. Humans vs computers in Mahjong is (at least that's my view at it) very similar to the same situation in chess. Except that chess (probably) has less board states and only two players. Computers do very well at short term, tactical play, but they are not very good at strategic play. Well, chess computers got fairly good at that too by now, but still, tactical play is their true strength. In Mahjong, there is short term tile efficiency and safety - which tile discard gives me the best chance to improve my shanten by one, which tile is safest to discard right now? But as soon as you look ahead a couple of turns, the problem becomes insanely difficult to compute. Which discard gives me the best chance to improve my shanten by 2 or 3 and leaves me with a good tenpai hand worth enough that it should be pursued? Does this plan lead to a series of potentially dangerous discards? Each turn you look ahead increases the computational effort by a very large factor. I'm not entirely opposed to letting other people in on my project, even if it's just to share ideas. My code is a bit of a mess right now though, since I want to redo part of the program architecture and I'm still debating fairly big changes in the database design and encapsulation... I'm also a busy, so I didn't actually have the time/energy to write code in the last few weeks. But one of the (further in the future) goals of my project is indeed to tack on a tenhou client. It would both be able to play by itself as well as allow a player to play just as if he used an official client, but with live analysis and suggestions. | ||
|
teplofizik
Russian Federation13 Posts
You can browse the code here. It seems difficult o.o I didn't even profile my current version yet heh. I too. I didn't use any optimisations of algorithm. I'm not completely sure I understand why your algorithm works Algorithm run throught the hand (which describe in Tehai array, index of array - tile type, value - count of tiles) and recursively cut pairs, sets (mentsu and ankou) and on the end simply forms (kanchan, penchan, ryanmen, pair) in all possible variations. One pair or form substract one shanten, one set - two shanten. Used tiles are removed from array and restore after recursive call of CutMentsu function. Accounted only first 4 forms (other does not give shanten number reduction). After each variant of dissection shanten counted as (8 - 2 * sets - forms [- 2 * opened sets]). Minimal value is used as real shanten number. It seems to try things like 9m12p No, all suits are divided by one cell (indexes 10, 20, 30), which always contains zero. Algorithm is correct and irrelevant to tiles count in hand (if hand has some opened sets). Of course, nuki should not be counted. I'm also not sure it deals correctly with situations like 1245m + some honors If honors completed to set, it's one shanten. Shanten number irrelevant to unaccesible tiles - it's a minimal count of tiles, which you should replace to reach tempai. In this hand any tile of 12345m get pair and tempai. Yes, it's matters if you write a bot for maximal efficiency, but not for real value. If it matters, I maybe can analyze waitings of forms in hand to calculate count of need tiles and they accessibility in wall. At now it's not needed. but with live analysis and suggestions It's interesting. I want a trainer (mb online?) with suggestions for newbies and intermediate players. Maybe with bots, maybe for Tenhou or similar server. Which tile is better to discard and why? Why your choise is incorrect? What yakus you missed by your choise? Is tile dangerous or not? And many other questions... There are need many algorithms and riichi theory. Who seeks shall find. | ||
|
spinesheath
Germany8679 Posts
On December 19 2013 06:16 teplofizik wrote: It seems difficult o.o I too. I didn't use any optimisations of algorithm. Algorithm run throught the hand (which describe in Tehai array, index of array - tile type, value - count of tiles) and recursively cut pairs, sets (mentsu and ankou) and on the end simply forms (kanchan, penchan, ryanmen, pair) in all possible variations. One pair or form substract one shanten, one set - two shanten. Used tiles are removed from array and restore after recursive call of CutMentsu function. Accounted only first 4 forms (other does not give shanten number reduction). After each variant of dissection shanten counted as (8 - 2 * sets - forms [- 2 * opened sets]). Minimal value is used as real shanten number. No, all suits are divided by one cell (indexes 10, 20, 30), which always contains zero. Algorithm is correct and irrelevant to tiles count in hand (if hand has some opened sets). Of course, nuki should not be counted. If honors completed to set, it's one shanten. Shanten number irrelevant to unaccesible tiles - it's a minimal count of tiles, which you should replace to reach tempai. In this hand any tile of 12345m get pair and tempai. Yes, it's matters if you write a bot for maximal efficiency, but not for real value. If it matters, I maybe can analyze waitings of forms in hand to calculate count of need tiles and they accessibility in wall. At now it's not needed. It's interesting. I want a trainer (mb online?) with suggestions for newbies and intermediate players. Maybe with bots, maybe for Tenhou or similar server. Which tile is better to discard and why? Why your choise is incorrect? What yakus you missed by your choise? Is tile dangerous or not? And many other questions... There are need many algorithms and riichi theory. Who seeks shall find. Oh, I see, splitting the color groups by 1 empty index works. Turns out I didn't think that example through in detail. I'm still not convinced it always works just like that, seems hard to prove. What will your algorithm yield for this hand: closed: 12m 11p called: 3333m 123p 123p | ||
|
teplofizik
Russian Federation13 Posts
12m 11p called: 3333m 123p 123p It's a karaten. Tempai without live outs. Maybe problems with limited forms with not declared kan (I never seen such hands), for example: 3333p [opened sets] should be ishanten. I would check this tomorrow (upd: fixed). If not - it can be handled by additional condition: if tempai hand has only one waiting and hand contains all 4 tiles, shanten should be increased to 1. Hmm. Hm, what kind of statanalysis you want to perform? =) 5 yakuman (normal one for sure, maybe kazoe 6?) No, kazoe 5 too (see limit hands table). + Show Spoiler + http://tenhou.net/0/?log=2013111412gm-0089-0000-c5f1ee27&ts=6&tw=3 - kazoe yakuman <AGARI ba="1,2" hai="16,17,53,57,61,116,117,119" m="22528,10240" machi="61" ten="70,48000,5" yaku="1,1,4,1,0,1,29,2,52,4,54,2,53,4" doraHai="26,86,25" doraHaiUra="85,102,21" who="3" fromWho="3" sc="250,-161,304,-161,210,-161,216,503" /> | ||
|
Benawii
United States51 Posts
On December 19 2013 03:35 spinesheath wrote: You can browse the code here. The actual calculator is ShantenCounter.cs. The rest is mainly code to create the ShantenCounter. I looked at your code (very nice and clean code by the way) and see that you're basically summarizing each suit separately in the first step. I didn't look into the second step, but it's most likely the look-up table with perhaps some optimizations to get it down to 20MB. Actually I didn't believe you could do even the first step in 20MB at first, as I thought the number of monocolored hands alone would still be in the billions. I couldn't estimate this using combinatorics so I wrote a program to do that instead. Guess what the number is. It's only 93,600. This is very nice because you can make things fast if you can limit the dependency between different suits (not saying this is easy). On December 19 2013 03:35 spinesheath wrote: Humans vs computers in Mahjong is (at least that's my view at it) very similar to the same situation in chess. Except that chess (probably) has less board states and only two players. Computers do very well at short term, tactical play, but they are not very good at strategic play. Well, chess computers got fairly good at that too by now, but still, tactical play is their true strength. In Mahjong, there is short term tile efficiency and safety - which tile discard gives me the best chance to improve my shanten by one, which tile is safest to discard right now? But as soon as you look ahead a couple of turns, the problem becomes insanely difficult to compute. Which discard gives me the best chance to improve my shanten by 2 or 3 and leaves me with a good tenpai hand worth enough that it should be pursued? Does this plan lead to a series of potentially dangerous discards? Each turn you look ahead increases the computational effort by a very large factor. Mahjong is definitely more difficult than chess, but the best chess engines are already at the level of world champions. Due to uncertainty from the tile shuffling (within a round and also the rounds after) and multiple opponents, I think it is better compared to poker. Despite being studied a lot more than Mahjong, poker AI is still nowhere near human players when there are 3+ opponents. We probably won't see a good computer Mahjong player any time soon, although having the computer assist a human player is definitely doable. | ||
|
spinesheath
Germany8679 Posts
- winning (14 tile) hand is -1 shanten instead of 0. Obviously a winning hand shouldn't be the same as a tenpai hand. On December 19 2013 07:15 teplofizik wrote: It's a karaten. Tempai without live outs. Maybe problems with limited forms with not declared kan (I never seen such hands), for example: 3333p [opened sets] should be ishanten. I would check this tomorrow (upd: fixed). If not - it can be handled by additional condition: if tempai hand has only one waiting and hand contains all 4 tiles, shanten should be increased to 1. Hmm. Hm, what kind of statanalysis you want to perform? =) No, kazoe 5 too (see limit hands table). + Show Spoiler + http://tenhou.net/0/?log=2013111412gm-0089-0000-c5f1ee27&ts=6&tw=3 - kazoe yakuman <AGARI ba="1,2" hai="16,17,53,57,61,116,117,119" m="22528,10240" machi="61" ten="70,48000,5" yaku="1,1,4,1,0,1,29,2,52,4,54,2,53,4" doraHai="26,86,25" doraHaiUra="85,102,21" who="3" fromWho="3" sc="250,-161,304,-161,210,-161,216,503" /> So we have different definitions of shanten. 12m 11p called: 3333m 123p 123p This hand is 1 shanten with my definition: either of 1m or 2m puts you in tenpai by discarding the other of the two. It is not tenpai because you can not legally complete the hand with a single draw if you had all the tiles available that are not in your hand. If you start introducing additional conditions in some specific cases, you're likely to miss something else. But this is precisely why your recursive algorithm is a lot faster than mine: I keep track of "reserved" tiles which leads to a lot more combinations that have to be checked. I wonder how tenhou handles this case. Here's how I want to analyze: 1) pick something that could prove to be statistically relevant, say the colors in a player's hand in relation to his first 3 discards. 2) analyze 3) check if it actually is statistically relevant 4) use this data to give better recommendations by the AI You can find all replays of all 3 Tenhou ranked players on tenhou.net (10000 or so replays total), so that's where I would be getting my most of my data from at the start. 5 yakuman (normal one for sure, maybe kazoe 6?) Is quoted that from my code? I'm careful with the information on arcturus.su, but nice to have an actual example. On December 19 2013 07:34 Benawii wrote: I looked at your code (very nice and clean code by the way) and see that you're basically summarizing each suit separately in the first step. I didn't look into the second step, but it's most likely the look-up table with perhaps some optimizations to get it down to 20MB. Actually I didn't believe you could do even the first step in 20MB at first, as I thought the number of monocolored hands alone would still be in the billions. I couldn't estimate this using combinatorics so I wrote a program to do that instead. Guess what the number is. It's only 93,600. This is very nice because you can make things fast if you can limit the dependency between different suits (not saying this is easy). Not clean enough for my tastes yet. But time is always short. I have calculated the number of combinations of monocolored hands too. You can actually reduce the number by about half because you can invert the numbers (for each color individually) without any change to shanten. Honors can be reduced even more than that, you can just sort them by their multiplicity in hand. For single color hands with 0 to 13 tiles you get: + Show Spoiler + 1 5 25 85 255 649 1481 3042 5739 9987 16196 24551 34988 46976 sum: 143980 For honors: + Show Spoiler + 1 1 2 3 5 6 9 11 14 16 19 20 23 23 sum: 153 And when you combine everything with the flipping colors and sorting honors trick applied, and also apply another trick (it you can sort the 3 colors by the total number of tiles in each color) you get a total of 437710054 relevant hands. However, you can't just use a lookup table since a lookup table needs an index (you certainly don't want to search the table, WAY too many entries). The total number of relevant hands is way too large anyways. And we haven't even looked into hands with called melds yet. Here's what my algorithm does in brief (simplified): + Show Spoiler + At first I tried to put all of these hands into a DFA. A DFA takes a so called word (the hand) and looks at it letter by letter (the number of tiles of each kind) and then walks down a graph based on what each letter is. Once it's done with the word, it will arrive at a final node, in our case we would have one final node for each possible shanten number. DFAs can be compacted by a lot. But even with perfect compaction (a mathematically proven minimal size), storing all relevant hands straight up would require me to work with 64 bit integers for address space reasons, and the total size of the DFA would exceed 8 GB. That's why I split it into 2 parts, and it wasn't easy to come up with this solution. First, I need a so called ArrangementValue. An ArrangementValue has 3 properties: Number of occupied pairs, number of occupied melds, value. A pair can be occupied by an actual pair, or just half a pair (1 tile that has room to grow into a pair), similarly with melds: 1, 2, or 3 tiles of a triplet or row. Value is the number of tiles used to occupy the pairs/melds in. Then I split each hand into the 3 colors and the honors, and calculate the list of ArrangementValues for each part (ArrangementValues can not be fully sorted, just partially, so we end up with more than one that has to be considered). Next I iterate though all possible combinations of the ArrangementValues of the 4 hand parts and pick the one that doesn't occupy more than 1 pair and 4 melds and has the highest total value. 13 - total value = shanten. Calculating the ArrangementValues for each part is step one, that is done by DFAs. The result is a binary string where each bit represents one ArrangementValue (there are only about 50 variations of these). Then I concatenate the 4 result strings and use them as the input for the final DFA which returns the shanten count. | ||
|
Benawii
United States51 Posts
On December 20 2013 03:28 spinesheath wrote: Here's what my algorithm does in brief (simplified): + Show Spoiler + At first I tried to put all of these hands into a DFA. A DFA takes a so called word (the hand) and looks at it letter by letter (the number of tiles of each kind) and then walks down a graph based on what each letter is. Once it's done with the word, it will arrive at a final node, in our case we would have one final node for each possible shanten number. DFAs can be compacted by a lot. But even with perfect compaction (a mathematically proven minimal size), storing all relevant hands straight up would require me to work with 64 bit integers for address space reasons, and the total size of the DFA would exceed 8 GB. That's why I split it into 2 parts, and it wasn't easy to come up with this solution. First, I need a so called ArrangementValue. An ArrangementValue has 3 properties: Number of occupied pairs, number of occupied melds, value. A pair can be occupied by an actual pair, or just half a pair (1 tile that has room to grow into a pair), similarly with melds: 1, 2, or 3 tiles of a triplet or row. Value is the number of tiles used to occupy the pairs/melds in. Then I split each hand into the 3 colors and the honors, and calculate the list of ArrangementValues for each part (ArrangementValues can not be fully sorted, just partially, so we end up with more than one that has to be considered). Next I iterate though all possible combinations of the ArrangementValues of the 4 hand parts and pick the one that doesn't occupy more than 1 pair and 4 melds and has the highest total value. 13 - total value = shanten. Calculating the ArrangementValues for each part is step one, that is done by DFAs. The result is a binary string where each bit represents one ArrangementValue (there are only about 50 variations of these). Then I concatenate the 4 result strings and use them as the input for the final DFA which returns the shanten count. Thanks for the explanation. I think I understand the idea now. This is probably the best one can do for shanten computing. Combining this with some computation you can compute the (approximately) fastest way to reach tenpai, and possibly while taking hand value into account if you can prune the search space enough. Now that sounds useful even to an intermediate player. | ||
|
Rhaegar99
Australia1190 Posts
![[image loading]](http://i.imgur.com/WddPSxr.png) He was 3shanten at start of the round and made it to 1shanten in 3 tiles. Noone saw it coming. Luckily south took the bullet and dealt into it  | ||
|
teplofizik
Russian Federation13 Posts
So we have different definitions of shanten. I agree... Is there any way to ask a japanese pro (japanese players's opinion about karaten - noten or not)?>< If you start introducing additional conditions in some specific cases, you're likely to miss something else No, fix only one: waiting not exists if concealed part of hand aleady contain all 4 tiles. In no one waiting exists in tempai - it's noten (ishanten?). I can easily count tiles in sets if it matters (and form 12 [3333] will be count as ishanten), but I don't know which is right... Maybe try to play with computer on tenhou with aim to build such hand and go to draw?=D 4444p hand is noten anyway (on tenhou and in Akagi anime). Here's how I want to analyze Hmm, it's sound interesting... Any results are exists at now?) I buy the book "科学する麻雀" with many graphs and tables about hands and probabilities, but japanese language is difficult (especially with mix a math and riichi-therminology) to understood this info... You can find all replays of all 3 Tenhou ranked players on tenhou.net Are you about Phoenix lobby replays? I know only about it. Any other games published only as result, without link to replay... Is quoted that from my code? Yes =) I had a look to code and related docs... I'm not familiar with this level of C# =D | ||
|
spinesheath
Germany8679 Posts
On December 20 2013 07:42 Benawii wrote: Thanks for the explanation. I think I understand the idea now. This is probably the best one can do for shanten computing. Combining this with some computation you can compute the (approximately) fastest way to reach tenpai, and possibly while taking hand value into account if you can prune the search space enough. Now that sounds useful even to an intermediate player. Computing the fastest way to reach tenpai still is rough. You have to keep in mind that the effort for each extra turn you look ahead increases by about a factor of 30. That's massive. A potential speed improvement would be to extend the algorithm even further to cover "15 tile hands". But I have no idea by how much the memory footprint of the algorithm grows in that case, and creating the algorithm would also take a lot longer (already takes over 24 hours...). On December 20 2013 17:53 teplofizik wrote: I agree... Is there any way to ask a japanese pro (japanese players's opinion about karaten - noten or not)?>< No, fix only one: waiting not exists if concealed part of hand aleady contain all 4 tiles. In no one waiting exists in tempai - it's noten (ishanten?). I can easily count tiles in sets if it matters (and form 12 [3333] will be count as ishanten), but I don't know which is right... Maybe try to play with computer on tenhou with aim to build such hand and go to draw?=D 4444p hand is noten anyway (on tenhou and in Akagi anime). Hmm, it's sound interesting... Any results are exists at now?) I buy the book "科学する麻雀" with many graphs and tables about hands and probabilities, but japanese language is difficult (especially with mix a math and riichi-therminology) to understood this info... Are you about Phoenix lobby replays? I know only about it. Any other games published only as result, without link to replay... Yes =) I had a look to code and related docs... I'm not familiar with this level of C# =D Well, I'm pretty sure I read somewhere that a hand is only tenpai if it can be legally completed using any tiles that are not in your own hand or melds. But I have no idea where. If you cover this case with a special condition, you should make sure it actually is the ONLY case where a result would be wrong. And it's unlikely you can prove that very easily. I don't have any relevant analysis results yet. I'm talking about the replays of the 3 players who made it to the highest rank on tenhou.net, which is called Tenhou. I don't have access to other player's replays. | ||
|
teplofizik
Russian Federation13 Posts
"15 tile hands" Recursive algorithm can parse such hands if it need without any changes. Well, I'm pretty sure I read somewhere that a hand is only tenpai if it can be legally completed using any tiles that are not in your own hand or melds. But I have no idea where. Okay, I ask in different places about it and search such games in replays =) "Ki ni narimasu!" If you cover this case with a special condition, you should make sure it actually is the ONLY case where a result would be wrong. And it's unlikely you can prove that very easily. I don't know hands which has tempai with 0 possible outs (all waitings on already used tiles) =D This fix don't disturb common hands. But I'd create some tests in future with common and unusual hands. I'm talking about the replays of the 3 players who made it to the highest rank on tenhou.net, which is called Tenhou. I don't have access to other player's replays. ASAPIN and so? I know about logs from this page: http://tenhou.net/sc/raw/ (radiobutton "鳳凰卓"), archives contain actual links to phoenix lobby (unreal upper dan lobby) replays for everyday, as example scc2013121200.html.gz (I cannot use direct links, they are dies fast). Page has js interface in json format for automatic downloading (see on page's bottom "ログの自動ダウンロードについて"). Maybe, somewhere (arcturus.su) exists full archives for all time. You can use it for statistics =) | ||
| ||
