Table of contents:

What the software can and cannot do?

This software is designed to conduct batch double-dummy analysis on a set of deals generated based on user-defined conditions and produce an average number of double-dummy tricks taken in defined contracts (denominations + declaring hands).

This application is targeted at bridge players with minimal programming skills, so if you find it somehow limiting, you may find it easier to use Dealer scripts with its bulit-in GIB support.

The application can:

The application cannot:

Please, be aware that the Dealer software itself allows for extensive statistical analysis of generated deals. For more information, refer to the description of Dealer's "average" and "frequency" actions.

Exemplary uses:

Getting started

To run the application, you must have the .NET 3.5 runtime environment installed on your computer.

The installation of this software is reduced to extracting the program files from an archive to a desired destination folder and running Analizator9000.exe contained within it.

Make sure that with the archive, you've extracted all the subfolders, required for the application to run:

Main program window consist of three major sections (as marked on the graphic):

  1. deal generating section (left-hand side of the application window)
  2. double-dummy analysis section (upper-right-hand side of the application window)
  3. status and results display section (lower-right-hand side of the application window)

Generating section and double-dummy section can be used completely independently (but not simultaneously).


Analizator9000 uses Dealer software to generate a set of deals for analysis. You may need to familiarize yourself with basic Dealer input scripts syntax. The reference is available from the Dealer documentation.

This section of the application consists of input controls for deal set generating parameters. The description uses an example of complexity sufficient to demonstrate most application features.

  1. Pre-dealt cards section. Fill in the fields for cards which positions are fixed before random deal generating. You can use both small and capital letters, 'T' symbol for '10' card, and both English (AKQJ) and Polish (AKDW) figure symbols. The example shows North assigned with AK9854 AK942 8 9, with no other player's cards revealed.
  2. Condition section. Define the conditions checked for every generated deal, accordingly to the Dealer syntax. The text put into this field will become the content of "condition" section of resulting Dealer input script. Do not use variable assignments. The example shows a basic condition for a non-forcing 1NT response after Polish 1 opening: 7-11 HCP without spade support, a 6+ card suit allowed only if 7-9 HCP.
  3. Expressions to calculate the average. Input a single expression in every line and Dealer will calculate the average value of that expression within the deal set. You can prefix the expression with a label, which later will be prepended to the average value in Dealer output. The example defines one expression, labeled "piki dłuższe od kierów" (Polish for "spades longer than hearts"), which will show the percentage of deals in which the spade fit in longer than the heart fit on both hands combined.
  4. Deal number limits. The upper value defines a maximum number of deals for Dealer to randomly generate. The lower - a maximum number of deals that meet the conditions defined by user. Dealer stops generating new deals the moment either of this limits is achieved. In our example, we want Dealer to produce 1,000 deals with generating no more than 100,000 deals.
  5. Generate button. Initiates deal generating.
  6. File selection dialog. Allows to fill in the fields from an existing Dealer input script. Note: not all information contained within the Dealer script may be preserved. The application will take the "predeal" section from the script and fill in the predeal fields, the "condition" section and put it in the condition field, "generate" and "produce" limit values and all "average" actions from "action" section. All other instructions (including variable assignements before "predeal" or "condition" sections or all actions other than "average") will be ignored.

After clicking the button, deal set is being generated. You can observe the progress and Dealer output in status display section of application window. Every generated deal will be printed as a new line in the output field.

When the generator finishes its work, a brief summary from Dealer output will be presented in the status field. It will contain a number of deals generated and produced, Dealer execution time and the average values of expressions defined by the user. In the example, as shown below, Dealer randomly generated 3,937 deals, from which the desired 1,000 met our defined conditions. In 27.1 per cent of the deals spades North-South's spade fit was longer than their heart fit. It took Dealer 2 seconds to work.

Generating process finished with two additional outcomes. As seen on the last line of status field, our generated deals were save in a text file (*.deals) inside the application's "files" directory. Dealer input script, compiled from user input, was also saved (as a *.dealer file). You can re-use the script later for replicating the same conditions for another set of deals. Both files are shown below.

The second outcome is a convenience for the second stage - deal analysis. The application inserted newly generated deal set file into the file selection field within the analysis section of the window.


The analysis section of the application is less complex than the generating section. It consist of:

  1. Deal set file selection dialog. You have to load a file, containing deals. If you've just generated some deals with the application, this field will be automatically filled in.
  2. Contract selection checkboxes. You can select any player as a declarer and any denomination as trumps for analysis. Clicking on row and column labels toggles whole rows and columns, clicking on the corner button toggles all contracts. Following the example from previous section, we want BCalc to calculate number of tricks taken when the opener plays in either of majors and when the responder plays no trump.
  3. Analysis button. Launches the analysis. WARNING! The analysis may take long time if you're overambitious on the contract selection and/or sample size. Experiment with reason!
  4. Abort button. Allows you to stop the analysis once it's started. Aborting the analysis preserves (archives) the partial results, but at the moment it's not possible to resume the analysis from the point it's been aborted on.

You can use any .deals file generated by Analizator9000 and saved in the "files" directory. You can provide the deal set yourself, as well, as long as it follows the format (at least currently, until some revisions):

Once the analysis starts, current results are displayed in the text box below, as shown on the screenshot. The results are formatted as a table, spanning all denominations and declaring players. The current average number of tricks and the standard deviation is displayed. Every single double dummy analysis result is written in the status box, and saved to a result file, as well.

Screenshots below present the results of an aborted analysis and results of a completed analysis. Note that the application runs multiple deal analysis simultaneously (currently up to 10) and it may take different amounts of time to analyze different deals, depening on the layout.

After the analysis is completed (or aborted), the results are saved in "files" directory for revision. All results of double-dummy analysis (per deal, per contract) are being written into the file as they're conducted. The final result (a summary of average values) is appended to the end of the file. The screenshots below show the contents of "files" folder for our example analysis: North takes the average of 10.4 tricks playing hearts, 10.0 tricks playing spades, and South takes the average of 7.6 tricks playing no trump.

Contract analysis (new in v0.10)

Version 0.10 introduced new feature to the application: contract analysis from score, matchpoint and IMP result point of view.

"Contract analysis" tab [1] in the analysis section allows you to define average outcome for specified contracts, each evaluated for every deal from the input deal set.

Contracts are defined by:

After defining all the contracts destined for analysis, and specifying vulnerability of the board, analysis may proceed. Progress of the process is displayed on the common progress bar of the analysis section of the window and, as the analysis is run, on the right hand side of the contract input section. [6]

Analysis is conducted by determining the outcome and score of all specified contracts. These scores are then converted to matchpoint and IMP result for every contract in the traveller. Finally, all these results are averaged for all deal within the generated set.

All accumulated results are calculated relative to the declarer (negative numbers indicate undertricks) and are aligned to the left for N/S and to the right for E/W, to increase clarity.

As an example for that feature, image above show analysis for a weak hand with 5-6 hearts against classical, strong, non-trump opening. There are two alternative contracts specified: 1NT and 2, both played from the opener's hand.

We've generated [1] 300 deals following very rudimentary conditions for both hands (15-17 HCP without any 5-card suit for the opener, 0-4 HCP with 5-6 hearts for the responder; the analysis does not take any potential strong transfer accepting bids by the opener).

We then specified both contracts [2], played by North, in the traveller section. Since we don't want to simulate tournament behavior, only compare both contracts without broader context (so we only take the "pass vs. transfer" decision into account), we leave both contracts' frequencies as 1.

As we trigger the analysis [3], all necessary denomination-declarer combinations are automatically set for double-dummy analysis. The progress of said analysis is displayed in the common status area of the window.

After the analysis concludes, we can see the results next to the contracts (image to the right): transfer is the winning decision in about 83% matchpoint deals and gains an average of about 2.7 IMP when non-vulnerable.

Analysis details are present in the status area of application window and are written to the log file, along with analysis summary.

Since version 0.10.1, contract success rate among the generated sample is also calculated.