Ignore:
Files:
10 edited

Legend:

Unmodified
Added
Removed
  • Orange/classification/svm/__init__.py

    r11423 r11397  
    11931193 
    11941194class RFE(object): 
    1195     """ 
    1196     Iterative feature elimination based on weights computed by a 
     1195 
     1196    """Iterative feature elimination based on weights computed by 
    11971197    linear SVM. 
    11981198 
    1199     Example: 
     1199    Example:: 
    12001200 
    12011201        >>> table = Orange.data.Table("promoters.tab") 
     
    12121212    def __init__(self, learner=None): 
    12131213        """ 
    1214         :param learner: A linear svm learner for use for scoring (this 
    1215             learner is passed to :class:`ScoreSVMWeights`) 
    1216  
    1217         :type learner: :class:`LinearSVMLearner` or :class:`SVMLearner` with 
    1218             linear kernel 
    1219  
    1220         .. seealso:: :class:`ScoreSVMWeights` 
     1214        :param learner: A linear svm learner for use with 
     1215            :class:`ScoreSVMWeights`. 
    12211216 
    12221217        """ 
  • docs/extend-widgets/rst/api.rst

    r11424 r11049  
    1818Following is an example that defines two output channels:: 
    1919 
    20     self.outputs = [("Sampled Data", orange.ExampleTable), 
    21                     ("Learner", orange.Learner)] 
     20    self.outputs = [("Sampled Data", orange.ExampleTable), ("Learner", orange.Learner)] 
    2221 
    2322:obj:`self.outputs` should thus be a list of tuples, within 
     
    6362 
    6463    def receiveData(self, data): 
    65         # handle data in some way 
    66  
     64    # handle data in some way 
    6765 
    6866Any time our widget would receive a token, :obj:`receiveData` 
     
    7876deleted, Orange Canvas would automatically send :obj:`None` to 
    7977the receiving widget. Make sure your widget handles :obj:`None` 
    80 tokens appropriately! 
     78tokens appropriately!` 
    8179 
    8280There are cases when widget would like to know about the origin of 
     
    9593 
    9694   def learner(self, learnertoken, tokenid): 
    97        # handle learnertoken and tokeid in some way 
     95   # handle learnertoken and tokeid in some way 
    9896 
    9997Widgets such as :obj:`OWTestLearners` and alike use such 
     
    104102 
    105103    self.inputs = [("Data", orange.ExampleTable, self.maindata), 
    106                    ("Additional Data", orange.ExampleTable, self.otherdata)] 
     104               ("Additional Data", orange.ExampleTable, self.otherdata)] 
    107105 
    108106and we connect this widget in Orange Canvas to a sending widget 
    109107that has a single orange.ExampleTable output channel, Canvas would 
    110 bring up *Set Channels* dialog. There, a sending widget's channel could 
     108bring up Set Channels dialog. There, a sending widget's channel could 
    111109be connected to both receiving channels. As we would often prefer to 
    112110connect to a single (default) channel instead (still allowing user of 
     
    116114 
    117115    self.inputs = [("Data", orange.ExampleTable, self.maindata, Default), 
    118                    ("Additional Data", orange.ExampleTable, self.otherdata)] 
     116               ("Additional Data", orange.ExampleTable, self.otherdata)] 
  • docs/extend-widgets/rst/basics.rst

    r11424 r11408  
    4242categories. For instance, under windows and default settings, a 
    4343directory that stores all the widgets displayed in the Evaluate pane is 
    44 *C:\\Python23\\Lib\\site-packages\\Orange\\OrangeWidgets\\Evaluate*. Figure 
     44C:\Python23\Lib\site-packages\orange\OrangeWidgets\Evaluate. Figure 
    4545above shows that at the time of writing of this text there were five 
    4646widgets for evaluation of classifiers, and this is how my Evaluate 
     
    8080something like:: 
    8181 
    82     self.inputs = [("Test Data Set", ExampleTable, self.cdata), 
    83                    ("Learner", orange.Learner, self.learner, 0)] 
     82    self.inputs = [("Test Data Set", ExampleTable, self.cdata), ("Learner", orange.Learner, self.learner, 0)] 
    8483    self.outputs = [("Evaluation Results", orngTest.ExperimentResults)] 
    8584 
     
    9291now the following is important: 
    9392 
    94    - Widgets are defined in a Python files. 
    95    - For Orange and Orange canvas to find them, they reside in subdirectories 
    96      in OrangeWidgets directory of Orange installation. The name of the 
    97      subdirectory matters, as this is the name of the widget category. Widgets 
    98      in the same directory will be grouped in the same pane of widget toolbox 
    99      in Orange Canvas. 
    100    - A file describing a widget starts with a header. This, given in sort of 
    101      XMLish style, tells about the name, short description, location of an 
    102      icon and priority of the widget. 
    103    - The sole role of priority is to specify the placement (order) of widgets 
    104      in the Orange Canvas toolbox. 
    105    - Somewhere in the code (where we will learn later) there are two lines 
    106      which tell which channels the widgets uses for communication. These, 
    107      together with the header information, completely specify the widget as it 
    108      is seen from the outside. 
     93   -  Widgets are defined in a Python files. 
     94   - For Orange and Orange canvas to find them, they reside in subdirectories in OrangeWidgets directory of Orange installation. The name of the subdirectory matters, as this is the name of the widget category. Widgets in the same directory will be grouped in the same pane of widget toolbox in Orange Canvas. 
     95   - A file describing a widget starts with a header. This, given in sort of XMLish style, tells about the name, short description, location of an icon and priority of the widget. 
     96   - The sole role of priority is to specify the placement (order) of widgets in the Orange Canvas toolbox. 
     97   - Somewhere in the code (where we will learn later) there are two lines which tell which channels the widgets uses for communication. These, together with the header information, completely specify the widget as it is seen from the outside. 
    10998 
    11099Oh, by the way. Orange caches widget descriptions to achieve a faster 
  • docs/extend-widgets/rst/channels.rst

    r11424 r11408  
    2626Say we want to build a widget that takes a data set and test 
    2727various predictive modelling techniques on it. A widget has to have an 
    28 input data channel, and this we know how to deal with from our 
    29 :doc:`previous <settings>` lesson. But, somehow differently, we 
     28input data channel, and this we know how to deal with from our :doc:`previous <settings>` 
     29lesson. But, somehow differently, we 
    3030want to connect any number of widgets which define learners to our 
    3131testing widget. Just like in a schema below, where three different 
  • docs/extend-widgets/rst/graphing.rst

    r11424 r11408  
    3939    self.setGraphGrid() 
    4040 
    41 :obj:`OWGrap` is a convenience subclass of QwtPlot and is imported from 
    42 OWGraph module. For the graph, we use :obj:`setAxisAutoScale` to 
     41:obj:`OWGrap` is a convenience subclass of QwtPlot and is imported from OWGraph module. For the graph, we use :obj:`setAxisAutoScale` to 
    4342request that the axis are automatically set in regard to the data that 
    4443is plotted in the graph. We plot the graph in using the following 
  • docs/extend-widgets/rst/owgui.rst

    r11424 r11408  
    3434`value` (required) 
    3535   String with the name of the master's attribute that synchronizes with the 
    36    state of the control (and vice-versa - when this attribute is changed, the 
    37    control changes as well). This attribute should usually be also included 
    38    the master's :obj:`settingsList`, so that it is automatically saved and 
    39    retrieved. 
     36   state of the control (and vice-versa - when this attribute is changed, the control changes as well). This attribute should usually be also included the master's :obj:`settingsList`, so that it is automatically saved and retrieved. 
    4037 
    4138`box` (default: None) 
    42    Indicates if there should be a box that is drawn around the control. 
    43    If `box` is ``None``, no box is drawn; if it is a string, it is also used 
    44    as box's name. If `box` is any other true value (such as ``True`` :), 
    45    an unlabeled box is drawn. 
     39   Indicates if there should be a box that is drawn around the control. If `box` is ``None``, no box is drawn; if it is a string, it is also used as box's name. If `box` is any other true value (such as ``True`` :), an unlabeled box is drawn. 
    4640 
    4741`callback` (default: None) 
     
    5751 
    5852`tooltip` (default: None) 
    59    A string that is displayed in a tooltip that appears when mouse is over the 
    60    control. 
     53   A string that is displayed in a tooltip that appears when mouse is over the control. 
    6154 
    6255`label` (default: None) 
     
    6760 
    6861`orientation` (default: "vertical") 
    69    When label is used, determines the relative placement of the label and the 
    70    control. Label can be above the control, "vertical", or in the same line 
    71    with control, "horizontal". Instead of "vertical" and "horizontal" you can 
    72    also use ``True`` and ``False`` or 1 and 0, respectively. (Remember this 
    73    as "vertical" being the usual order of controls in the widgets, so vertical 
    74    is "true".) 
     62   When label is used, determines the relative placement of the label and the control. Label can be above the control, "vertical", or in the same line with control, "horizontal". Instead of "vertical" and "horizontal" you can also use ``True`` and ``False`` or 1 and 0, respectively. (Remember this as "vertical" being the usual order of controls in the widgets, so vertical is "true".) 
    7563 
    7664`disabled` (default: False) 
     
    7866 
    7967`addSpace` (default: False) 
    80    If true, a space of 8 pixels is added after the widget by calling 
    81    :func:`separator`. `addSpace` can also be an integer specifying the height 
    82    of the added space. 
     68   If true, a space of 8 pixels is added after the widget by calling :func:`separator`. `addSpace` can also be an integer specifying the height of the added space. 
    8369 
    8470 
     
    8975This section describes the OWGUI wrappers for controls like check boxes, buttons 
    9076and similar. All the important Qt's controls can be constructed through this 
    91 functions. 
    92  
    93 .. 
    94    You should always use them instead of calling Qt directly, not only 
    95    because they are convenient, but also because they set up a lot of things 
    96    that happen in behind. 
     77functions. You should always use them instead of calling Qt directly, not only 
     78because they are convenient, but also because they set up a lot of things that happen in behind. 
    9779 
    9880 
     
    10688 
    10789   `disables` (default: []) 
    108       If the check box needs to disable some other controls they can be given 
    109       in list  `disables`, e.g. ``disables=[someOtherCheckBox, someLineEdit]``. 
    110       If the other control should be disabled when the checkbox is checked, do 
    111       it like this: ``disables=[someOtherCheckBox, (-1, someLineEdit)]`` - now 
    112       `someOtherCheckBox` will be enabled when this check box is checked, 
    113       while `someLineEdit` will be enabled when the check box is unchecked. 
     90      If the check box needs to disable some other controls they can be given in list  `disables`, e.g. ``disables=[someOtherCheckBox, someLineEdit]``. If the other control should be disabled when the checkbox is checked, do it like this: ``disables=[someOtherCheckBox, (-1, someLineEdit)]`` - now `someOtherCheckBox` will be enabled when this check box is checked, while `someLineEdit` will be enabled when the check box is unchecked. 
    11491 
    11592   `labelWidth` (default: None) 
     
    125102 
    126103   `valueType` (default: str) 
    127       A type into which the `value` is cast. 
     104      A type into which the value is cast. 
    128105 
    129106   `validator` (default: None) 
     
    175152 
    176153   `items` (default: []) 
    177       A list of combo box's items. Unlike most OWGUI, `items` have one 
    178       Orange-specific quirk: its element can be either a string, in which 
    179       case it is used as a label, or a tuple, where the first element is a 
    180       label name and the last is the attribute type which is used to create 
    181       an icon. Most attribute lists in Orange Widgets are constructed this way. 
     154      A list of combo box's items. Unlike most OWGUI, `items` have one Orange-specific quirk: its element can be either a string, in which case it is used as a label, or a tuple, where the first element is a label name and the last is the attribute type which is used to create an icon. Most attribute lists in Orange Widgets are constructed this way. 
    182155 
    183156   `sendSelectedValue` (default: 0) 
    184       If false, attribute `value` will be assigned the index of the selected 
    185       item. Otherwise, it is assigned the currently selected item's label. 
     157      If false, attribute `value` will be assigned the index of the selected item. Otherwise, it is assigned the currently selected item's label. 
    186158 
    187159   `control2attributeDict` (default: {}) 
    188       A dictionary for translating the item's label into `value`. It is used 
    189       only is `sendSelectedValue` is true, and even then a label is translated 
    190       only if an item with such a key is found in the dictionary; otherwise, 
    191       label is written to `value` as it is. 
     160      A dictionary for translating the item's label into `value`. It is used only is `sendSelectedValue` is true, and even then a label is translated only if an item with such a key is found in the dictionary; otherwise, label is written to `value` as it is.  
    192161 
    193162   `emptyString` (default: "") 
    194       Tells which combo box's item corresponds to an empty `value`. This is 
    195       typically used when combo box's labels are attribute names and an item 
    196       "(none)", which allows user to select no attribute. If we give 
    197       ``emptyString="(none)"``, `value` will be an empty string when the user 
    198       selects "(none)". This is equivalent to specifying 
    199       ``control2attributeDict={"(none)": ""}`` (and is actually implemented 
    200       like that), but far more convenient. 
     163      Tells which combo box's item corresponds to an empty `value`. This is typically used when combo box's labels are attribute names and an item "(none)", which allows user to select no attribute. If we give ``emptyString="(none)"``, `value` will be an empty string when the user selects "(none)". This is equivalent to specifying ``control2attributeDict={"(none)": ""}`` (and is actually implemented like that), but far more convenient. 
    201164 
    202165   `valueType` (default: str or unicode) 
    203       A function through which the currently selected item's label is  
    204       converted prior to looking into `control2attributeDict`. Needed to 
    205       convert Qt's QString. 
     166      A function through which the currently selected item's label is converted prior to looking into `control2attributeDict`. Needed to convert Qt's QString. 
    206167 
    207168 
     
    210171 
    211172This control, which might be the most complicated control in OWGUI, is a 
    212 sophisticated wrapper around QListBox. It's complexity arises from 
    213 synchronization. 
     173sophisticated wrapper around QListBox. It's complexity arises from synchronization. 
    214174 
    215175 
     
    220180 
    221181   `labels` (required) 
    222       The name of master's attribute containing the list box's labels. Similar 
    223       to `items` in combo box, list `labels` have one Orange-specific quirk: 
    224       its element can be either a string, in which case it is used as a label 
    225       or a tuple, where the first element is a label name and the second can 
    226       be either an icon on an integer, representing the attribute type which 
    227       is used to create an icon. Most attribute lists in Orange Widgets are 
    228       constructed this way. 
     182      The name of master's attribute containing the list box's labels. Similar to `items` in combo box, list `labels` have one Orange-specific quirk: its element can be either a string, in which case it is used as a label, or a tuple, where the first element is a label name and the second can be either an icon on an integer, representing the attribute type which is used to create an icon. Most attribute lists in Orange Widgets are constructed this way. 
    229183 
    230184   `selectionMode` (default: QListWidget.SingleSelection) 
    231       Tells whether the user can select a single item 
    232       (:obj:`QListWidget.SingleSelection`), multiple items 
    233       (:obj:`QListWidget.MultiSelection`, :obj:`QListWidget.ExtendedSelection`) 
    234       or nothing (:obj:`QListWidget.NoSelection`). 
    235  
    236    `value` is automatically cast to :obj:`OWGUI.ControlledList` (this is 
    237    needed because the list should report any changes to the control, the list 
    238    box; :obj:`OWGUI.ControlledList` is like an ordinary Python :obj:`list` 
    239    except that it triggers synchronization with the list box at every change). 
    240  
    241    `labels` is only partially synchronized with the list box: if a new list 
    242    is assigning to `labels` attribute, the list will change. If elements of 
    243    the existing list are changed or added, the list box won't budge. You 
    244    should never change the list, but always assign a new list (or reassign 
    245    the same after it's changed). If the labels are stored in 
    246    ``self.listLabels`` and you write ``self.listLabels[1]="a new label"``, 
    247    the list box won't change. To trigger the synchronization, you should 
    248    continue by ``self.listLabels = self.listLabels``. This may seem awkward, 
    249    but by our experience a list of selected items is seldom changed changed 
    250    "per-item", so we were too lazy to write the annoyingly complex backward 
    251    callbacks. 
     185      Tells whether the user can select a single item (:obj:`QListWidget.SingleSelection`), multiple items (:obj:`QListWidget.MultiSelection`, :obj:`QListWidget.ExtendedSelection`) or nothing (:obj:`QListWidget.NoSelection`). 
     186 
     187   `value` is automatically cast to :obj:`OWGUI.ControlledList` (this is needed because the list should report any changes to the control, the list box; :obj:`OWGUI.ControlledList` is like an ordinary Python :obj:`list` except that it triggers synchronization with the list box at every change). 
     188 
     189   `labels` is only partially synchronized with the list box: if a new list is assigning to `labels` attribute, the list will change. If elements of the existing list are changed or added, the list box won't budge. You should never change the list, but always assign a new list (or reassign the same after it's changed). If the labels are stored in ``self.listLabels`` and you write ``self.listLabels[1]="a new label"``, the list box won't change. To trigger the synchronization, you should continue by ``self.listLabels = self.listLabels``. This may seem awkward, but by our experience a list of selected items is seldom changed changed "per-item", so we were too lazy to write the annoyingly complex backward callbacks. 
     190 
    252191 
    253192 
     
    266205****** 
    267206 
    268 A wrapper around QSlider that allows user setting a numerical value between 
    269 the given bounds. 
     207A wrapper around QSlider that allows user setting a numerical value between the given bounds. 
    270208 
    271209.. function:: hSlider(widget, master, value[, box, minValue, maxValue, step, callback, labelFormat, ticks, divideFactor]) 
     
    276214 
    277215   `ticks` (default: 0) 
    278       If non-zero, it gives the interval between two ticks. The ticks will 
    279       appear below the groove. 
     216      If non-zero, it gives the interval between two ticks. The ticks will appear below the groove. 
    280217 
    281218   `labelFormat` (default: " %d") 
    282       Defines the look of the label on the righthand side of the slider. It 
    283       has to contain one format character (like %d in the default), but can 
    284       contain other text as well. 
     219      Defines the look of the label on the righthand side of the slider. It has to contain one format character (like %d in the default), but can contain other text as well. 
    285220 
    286221   `divideFactor` (default: 1.0) 
     
    291226******************* 
    292227 
    293 Check box with spin, or, essentially, a wrapper around OWGUI.checkBox and 
    294 OWGUI.spin. 
     228Check box with spin, or, essentially, a wrapper around 
     229OWGUI.checkBox and OWGUI.spin. 
    295230 
    296231.. function:: checkWithSpin(widget, master, label, min, max, checked, value[, posttext, step, tooltip, checkCallback, spinCallback, labelWidth]) 
     
    315250****** 
    316251 
    317 There are two functions for constructing labels. The first is a simple wrapper 
    318 around QLabel which differs only in allowing to specify a fixed width without 
    319 needing an extra line. Note that unlike most other OWGUI widgets, this one 
    320 does not have the argument `master`. 
     252There are two functions for constructing labels. The first is a simple wrapper around QLabel which differs only in allowing to specify a fixed width without needing an extra line. Note that unlike most other OWGUI widgets, this one does not have the argument `master`. 
    321253 
    322254.. function:: widgetLabel(widget, label[, labelWidth]) 
    323255 
    324    The second is a label which can synchronize with values of master widget's 
    325    attributes. 
     256   The second is a label which can synchronize with values of master widget's attributes. 
    326257 
    327258.. function:: label(widget, master, label[, labelWidth]) 
     
    395326************************* 
    396327 
    397 Many widgets have a "Send" button (perhaps named "Apply", "Commit"...) 
    398 accompanied with a check box "Send automatically", having the same effect as 
    399 if the user pressed the button after each change. A well behaved widget cares 
    400 to: 
     328Many widgets have a "Send" button (perhaps named "Apply", "Commit"...) accompanied with a check box "Send automatically", having the same effect as if the user pressed the button after each change. A well behaved widget cares to: 
    401329 
    402330* disable the button, when the check box is checked; 
    403 * when the user checks the check box, the data needs to be send (or the 
    404   changes applied), but only if there is any pending change which has not been 
    405   (manually) sent yet. 
    406  
    407 Programming this into every widget is annoying and error-prone; at the time 
    408 when the function described here was written, not many widgets actually did 
    409 this properly. 
     331* when the user checks the check box, the data needs to be send (or the changes applied), but only if there is any pending change which has not been (manually) sent yet. 
     332 
     333Programming this into every widget is annoying and error-prone; at the time when the function described here was written, not many widgets actually did this properly. 
    410334 
    411335.. function:: setStopper(master, sendButton, stopCheckbox, changedFlag, callback) 
     
    415339 
    416340   `stopCheckbox` 
    417       Check box that decides whether the changes are sent/commited/applied 
    418       automatically. 
     341      Check box that decides whether the changes are sent/commited/applied automatically. 
    419342 
    420343   `changedFlag` 
    421       The name of the `master`'s attribute which tells whether there is a 
    422       change which has not been sent/applied yet. 
     344      The name of the `master`'s attribute which tells whether there is a change which has not been sent/applied yet. 
    423345 
    424346   `callback` 
    425       The function that sends the data or applies the changes. This is 
    426       typically the function which is also used as the `sendButton`'s callback. 
    427  
    428  
    429 :obj:`setStopper` is a trivial three lines long function which connects a few 
    430 signals. Its true importance is in enforcing the correct procedure for 
    431 implementing such button-check box combinations. 
     347      The function that sends the data or applies the changes. This is typically the function which is also used as the `sendButton`'s callback. 
     348 
     349 
     350:obj:`setStopper` is a trivial three lines long function which connects a few signals. Its true importance is in enforcing the correct procedure for implementing such button-check box combinations. 
    432351 
    433352.. 
     
    435354 
    436355   Missing, where did it go? 
     356 
  • docs/extend-widgets/rst/settings.rst

    r11424 r11408  
    176176state so that when the user changes a check box, the attribute changes 
    177177and vice-versa. Although you can create such a link manually, you 
    178 should always use the module :doc:`OWGUI <owgui>` instead; 
     178should always use the module :doc:`OWGUI <owgui.rst>` instead; 
    179179for instance, for a check box, use :obj:`OWGUI.checkBox` and not 
    180180simply the Qt's :obj:`QCheckBox`. 
     
    183183the data, while other are context-dependent. For the first to be saved 
    184184properly, you only need to list them in the :obj:`settingsList` 
    185 in the widget definition, as already described :doc:`elsewhere <settings>` 
     185in the widget definition, as already described :doc:`elsewhere <settings.rst>` 
    186186 
    187187************************** 
     
    237237In general, the function should go like this. 
    238238 
    239 * Do any clean-up you need, but without clearing any of the settings that need 
    240   to be saved. Scatter plot needs none. 
    241 * Call :obj:`self.closeContext()`; this ensures that all the context dependent 
    242   settings (e.g. attribute names from the list boxes) are remembered. 
    243 * Get the data (or whatever you do) and set the controls to some defaults as 
    244   if there were no context retrieving mechanism. Scatter plot does it by 
    245   calling :obj:`initAttrValues()` which assigns the first two attributes to 
    246   the x and y axis and the class attribute to the color. At this phase, you 
    247   shouldn't call any functions that depend on the settings, such as drawing 
    248   the graph. 
    249 * Call :obj:`self.openContext` (more about the arguments later). This will 
    250   search for a suitable context and assign the controls new values if one is 
    251   found. If there is no saved context that can be used, a new context is 
    252   created and filled with the default values that were assigned at the previous 
    253   point. 
    254 * Finally, adjust the widget according to the retrieved controls. Scatter plot 
    255   now plots the graph by calling :obj:`updateGraph`. 
    256  
    257  
    258 :obj:`closeContext` has an argument, the name of the context. If omitted 
    259 (like above), the default name (:obj:`""`) is used. When opening the context, 
    260 we give the name and some arguments on which the context depends. In case of 
    261 :obj:`DomainContextHandler`, which scatter plot uses, we can give it a domain 
    262 or any object that has a field :obj:`domain` containing a domain. Whether a 
    263 saved context can be reused is judged upon the presence of attributes in the 
    264 domain. 
    265  
    266 If the widget is constructed appropriately (that is, if it strictly uses OWGUI 
    267 controls instead of the Qt's), no other administration is needed to switch the 
    268 context. 
    269  
    270 Except for declaring the context settings, that is. Scatter plot has this just 
    271 below the :obj:`settingsList`:: 
     239* Do any clean-up you need, but without clearing any of the settings that need to be saved. Scatter plot needs none. 
     240* Call :obj:`self.closeContext`; this ensures that all the context dependent settings (e.g. attribute names from the list boxes) are remembered. 
     241* Get the data (or whatever you do) and set the controls to some defaults as if there were no context retrieving mechanism. Scatter plot does it by calling :obj:`initAttrValues()` which assigns the first two attributes to the x and y axis and the class attribute to the color. At this phase, you shouldn't call any functions that depend on the settings, such as drawing the graph. 
     242* Call :obj:`self.openContext` (more about the arguments later). This will search for a suitable context and assign the controls new values if one is found. If there is no saved context that can be used, a new context is created and filled with the default values that were assigned at the previous point. 
     243* Finally, adjust the widget according to the retrieved controls. Scatter plot now plots the graph by calling :obj:`updateGraph`. 
     244 
     245 
     246:obj:`closeContext` has an argument, the name of the context. If omitted (like above), the default name (:obj:`""`) is used. When opening the context, we give the name and some arguments on which the context depends. In case of :obj:`DomainContextHandler`, which scatter plot uses, we can give it a domain or any object that has a field :obj:`domain` containing a domain. Whether a saved context can be reused is judged upon the presence of attributes in the domain. 
     247 
     248If the widget is constructed appropriately (that is, if it strictly uses OWGUI controls instead of the Qt's), no other administration is needed to switch the context. 
     249 
     250Except for declaring the context settings, that is. Scatter plot has this just below the :obj:`settingsList`:: 
    272251 
    273252    contextHandlers = {"": DomainContextHandler("", 
     
    278257       ("attrSize", DomainContextHandler.Optional)])} 
    279258 
    280 :obj:`contextHandlers` is a dictionary whose keys are contexts' names. Each 
    281 widget can have multiple contexts; for an unrealistic example, consider a 
    282 scatter plot which gets two data sets and uses one attribute from the first 
    283 for the x axis, and an attribute from the other for y. Since we won't see this 
    284 often, the default name for a context is an empty string. 
    285  
    286 The values in the dictionary are context handlers. Scatter plot declares that 
    287 it has a DomainContextHandler with name "" (sorry for the repetition) with 
    288 attributes "attrX", "attrY", "attrLabel", "attrShape" and "attrSize". The 
    289 first two are required, while the other three are optional. 
     259:obj:`contextHandlers` is a dictionary whose keys are contexts' names. Each widget can have multiple contexts; for an unrealistic example, consider a scatter plot which gets two data sets and uses one attribute from the first for the x axis, and an attribute from the other for y. Since we won't see this often, the default name for a context is an empty string. 
     260 
     261The values in the dictionary are context handlers. Scatter plot declares that it has a DomainContextHandler with name "" (sorry for the repetition) with attributes "attrX", "attrY", "attrLabel", "attrShape" and "attrSize". The first two are required, while the other three are optional. 
    290262 
    291263********************************* 
     
    293265********************************* 
    294266 
    295 What we said above is not exactly true. :obj:`DomainContextHandler.Required` 
    296 is the default flag, so :obj:`("attrX", DomainContextHandler.Required)` can 
    297 be replaced by simply :obj:`"attrX"`. And the latter three have the 
     267What we said above is not exactly 
     268true. :obj:`DomainContextHandler.Required` is the default flag, 
     269so :obj:`("attrX", DomainContextHandler.Required)` can be 
     270replaced by simply :obj:`"attrX"`. And the latter three have the 
    298271same flags, so they can be grouped into :obj:`(["attrLabel", 
    299272"attrShape", "attrSize"], DomainContextHandler.Optional)`. So 
     
    304277       (["attrLabel", "attrShape", "attrSize"], DomainContextHandler.Optional)])} 
    305278 
    306 What do ``Optional`` and ``Required`` mean? Say that you used the 
     279What do "optional" and "required" mean? Say that you used the 
    307280scatter plot on the data with attributes A, B, C and D; A and B are 
    308281used for the x and y axis and D defined the colors of examples. Now 
     
    322295:obj:`DomainContextHandler`. 
    323296 
    324 :class:`DomainContextHandler`'s constructor has the following arguments 
    325  
    326 `contextName` 
    327    The name of the context; it should consist of letters and digits (it is 
    328    used as a part of a variable name). In case the widget has multiple 
    329    contexts, they should have unique names. In most cases there will be only 
    330    one context, so you can leave it empty. 
    331  
    332 `fields` 
    333    The names of the attributes to be saved and the corresponding flags. They 
    334    are described in more details below. 
    335  
    336 `cloneIfImperfect` 
    337    States that when the context doesn't match perfectly, that is, unless the 
    338    domain is exactly the same as the domain from which the context was 
    339    originally created, :obj:`openContext` shouldn't reuse a context but create 
    340    a copy of the best matching context instead. Default is :obj:`True`. 
    341  
    342 `loadImperfect` 
    343    tells whether the contexts that do not match perfectly (see above) should 
    344    be used or not. Default is :obj:`True`. 
    345  
    346 `findImperfect` 
    347    Tells whether imperfect contexts match at all or not (this flag is 
    348    somewhat confused with :obj:`loadImperfect`, but it may come useful some 
    349    day). Default is :obj:`True` again. 
    350  
    351 `syncWithGlobal` 
    352    Tells whether instances of this widget should have a shared list of 
    353    contexts (default). The alternative is that each keeps its own list; 
    354    each individual list is merged with the global when the widget is deleted 
    355    from the canvas (or when the canvas is closed). This setting only applies 
    356    to canvas, while in saved applications widgets always have separate settings 
    357    lists. 
    358  
    359 `maxAttributesToPickle` 
    360    To keep the size of the context file small, settings for domains exceeding 
    361    a certain number of attributes are not pickled. Default is 100, but you can 
    362    increase (or decrease this) if you need to. 
     297DomainContextHandler's constructor has the following arguments 
     298 
     299contextName 
     300The name of the context; it should consist of letters and digits (it is used as a prt of a variable name). In case the widget has multiple contexts, they should have unique names. In most cases there will be only one context, so you can leave it empty. 
     301 
     302fields 
     303The names of the attributes to be saved and the corresponding flags. They are described in more details below. 
     304 
     305cloneIfImperfect 
     306states that when the context doesn't match perfectly, that is, unless the domain is exactly the same as the domain from which the context was originally created, :obj:`openContext` shouldn't reuse a context but create a copy of the best matching context instead. Default is :obj:`True`. 
     307 
     308loadImperfect 
     309tells whether the contexts that do not match perfectly (see above) should be used or not. Default is :obj:`True`. 
     310 
     311findImperfect 
     312tells whether imperfect contexts match at all or not (this flag is somewhat confused with :obj:`loadImperfect`, but it may come useful some day. Default is :obj:`True` again. 
     313 
     314syncWithGlobal 
     315tells whether instances of this widget should have a shared list of contexts (default). The alternative is that each keeps its own list; each individual list is merged with the global when the widget is deleted from the canvas (or when the canvas is closed). This setting only applies to canvas, while in saved applications widgets always have separate settings lists. 
     316 
     317maxAttributesToPickle 
     318To keep the size of the context file small, settings for domains exceeding a certain number of attributes are not pickled. Default is 100, but you can increase (or decrease this) if you need to. 
    363319 
    364320 
     
    370326name (just like in :obj:`settingsList`) and a flag. Here are the possible flags: 
    371327 
    372 * :obj:`DomainContextHandler.Optional`, 
    373   :obj:`DomainContextHandler.SelectedRequired` and 
    374   :obj:`DomainContextHandler.Required` state whether the attribute is optional 
    375   or required, as explained above. Default is :obj:`Required`. 
    376   :obj:`DomainContextHandler.SelectedRequired` is applicable only if the 
    377   control is a list box, where it means that the attributes that are selected 
    378   are required while the other attributes from the list are not. 
    379  
    380 * :obj:`DomainContextHandler.NotAttribute` the setting is not an attribute 
    381   name. You can essentially make a check box context dependent, but we very 
    382   strongly dissuade from this since it can really confuse the user if some 
    383   check boxes change with the data while most do not. 
    384  
    385 * :obj:`DomainContextHandler.List` tells that the attribute corresponds to a 
    386   list box. 
     328* :obj:`DomainContextHandler.Optional`, :obj:`DomainContextHandler.SelectedRequired` and :obj:`DomainContextHandler.Required` state whether the attribute is optional or required, as explained above. Default is :obj:`Required`. :obj:`DomainContextHandler.SelectedRequired` is applicable only if the control is a list box, where it means that the attributes that are selected are required while the other attributes from the list are not. 
     329* :obj:`DomainContextHandler.NotAttribute` the setting is not an attribute name. You can essentially make a check box context dependent, but we very strongly dissuade from this since it can really confuse the user if some check boxes change with the data while most do not. 
     330* :obj:`DomainContextHandler.List` tells that the attribute corresponds to a list box. 
    387331 
    388332 
     
    404348But the tuples are actually a shortcut for instances of 
    405349:obj:`ContextField`. When you say :obj:`"attrX"` this is actually 
    406 :obj:`ContextField("attrX", DomainContextHandler.Required)` 
    407  
    408 .. 
    409    But see this monster from widget "Select Attributes" (file OWDataDomain.py):: 
    410  
    411        contextHandlers = {"": DomainContextHandler("", 
    412            [ContextField("chosenAttributes", 
    413                           DomainContextHandler.RequiredList, 
    414                           selected="selectedChosen", reservoir="inputAttributes"), 
    415             ContextField("classAttribute", 
    416                           DomainContextHandler.RequiredList, 
    417                           selected="selectedClass", reservoir="inputAttributes"), 
    418             ContextField("metaAttributes", 
    419                           DomainContextHandler.RequiredList, 
    420                           selected="selectedMeta", reservoir="inputAttributes") 
    421        ])} 
    422  
    423  
    424    :obj:`ContextField`'s constructor gets the name and flags and a list of 
    425    arguments that are written directly into the object instance. To follow the 
    426    example, recall what Select Attributes looks like: it allows you to select a 
    427    subset of attributes, the class attribute and the meta attributes that you 
    428    want to use; the attributes in the corresponding three list boxes are stored 
    429    in the widget's variables :obj:`chosenAttributes`, :obj:`classAttribute` 
    430    and :obj:`metaAttributes` respectively. When the user selects some attributes 
    431    in any of these boxes, the selection is stored in :obj:`selectedChosen`, 
    432    :obj:`selectedClass` and :obj:`selectedMeta`. The remaining attributes 
    433    - those that are not in any of these three list boxes - are in the leftover 
    434    listbox on the left-hand side of the widget, and the content of the box is 
    435    stored in the widget's variable :obj:`inputAttributes`. 
    436  
    437    The above definition tells that the context needs to store the contents of 
    438    the three list boxes by specifying the corresponding variables; the list of 
    439    attributes is given as the name of the field and the list of selected 
    440    attributes is in the optional named attribute :obj:`selected`. By 
    441    :obj:`reservoir` we told the context handler that the attributes are taken 
    442    from :obj:`inputAttributes`. So, when a context is retrieved, all the 
    443    attributes that are not in any of the three list boxes are put into 
    444    :obj:`inputAttributes`. 
    445  
    446    Why the mess? Couldn't we just store :obj:`inputAttributes` as the fourth 
    447    list box? Imagine that the user first loads the data with attributes A, B, 
    448    C, D, E and F, puts A, B, C in chosen and D in class. E and F are left in 
    449    :obj:`inputAttributes`. Now she loads another data which has attributes A, 
    450    B, C, D, E, and G. The contexts should match (the new data has all the 
    451    attributes we need), but :obj:`inputAttributes` should now contain E and 
    452    G, not E and F, since F doesn't exist any more, while G needs to be made 
    453    available. 
    454  
    455    You can use :obj:`ContextField` (instead of tuples and strings) for 
    456    declaring any fields, but you will usually need them only for lists or, 
    457    maybe, some complicated future controls. 
     350:obj:`ContextField("attrX", DomainContextHandler.Required)` (you should 
     351appreciate the shortcurt, right?). But see this monster from widget "Select 
     352Attributes" (file OWDataDomain.py):: 
     353 
     354    contextHandlers = {"": DomainContextHandler("", 
     355        [ContextField("chosenAttributes", 
     356                       DomainContextHandler.RequiredList, 
     357                       selected="selectedChosen", reservoir="inputAttributes"), 
     358         ContextField("classAttribute", 
     359                       DomainContextHandler.RequiredList, 
     360                       selected="selectedClass", reservoir="inputAttributes"), 
     361         ContextField("metaAttributes", 
     362                       DomainContextHandler.RequiredList, 
     363                       selected="selectedMeta", reservoir="inputAttributes") 
     364    ])} 
     365 
     366 
     367:obj:`ContextField`'s constructor gets the name and flags and a list of 
     368arguments that are written directly into the object instance. To follow the 
     369example, recall what Select Attributes looks like: it allows you to select a 
     370subset of attributes, the class attribute and the meta attributes that you 
     371want to use; the attributes in the corresponding three list boxes are stored 
     372in the widget's variables :obj:`chosenAttributes`, :obj:`classAttribute` 
     373and :obj:`metaAttributes` respectively. When the user selects some attributes 
     374in any of these boxes, the selection is stored in :obj:`selectedChosen`, 
     375:obj:`selectedClass` and :obj:`selectedMeta`. The remaining attributes 
     376- those that are not in any of these three list boxes - are in the leftover 
     377listbox on the left-hand side of the widget, and the content of the box is 
     378stored in the widget's variable :obj:`inputAttributes`. 
     379 
     380The above definition tells that the context needs to store the contents of 
     381the three list boxes by specifying the corresponding variables; the list of 
     382attributes is given as the name of the field and the list of selected 
     383attributes is in the optional named attribute :obj:`selected`. By 
     384:obj:`reservoir` we told the context handler that the attributes are taken 
     385from :obj:`inputAttributes`. So, when a context is retrieved, all the 
     386attributes that are not in any of the three list boxes are put into 
     387:obj:`inputAttributes`. 
     388 
     389Why the mess? Couldn't we just store :obj:`inputAttributes` as the fourth 
     390list box? Imagine that the user first loads the data with attributes A, B, 
     391C, D, E and F, puts A, B, C in chosen and D in class. E and F are left in 
     392:obj:`inputAttributes`. Now she loads another data which has attributes A, 
     393B, C, D, E, and G. The contexts should match (the new data has all the 
     394attributes we need), but :obj:`inputAttributes` should now contain E and 
     395G, not E and F, since F doesn't exist any more, while G needs to be made 
     396available. 
     397 
     398You can use :obj:`ContextField` (instead of tuples and strings) for 
     399declaring any fields, but you will usually need them only for lists or, 
     400maybe, some complicated future controls. 
    458401 
    459402 
     
    462405***************************** 
    463406 
    464 Avoid it if you can. If you can't, here's the list of the methods you may need 
    465 to implement. You may want to copy as much from the :obj:`DomainContextHandler` 
    466 as you can. 
    467  
    468  
    469 :obj:`__init__` 
    470    Has the same arguments as the :obj:`DomainContextHandler`'s, except for the 
    471    :obj:`fields`. 
    472  
    473 :obj:`newContext()` 
    474    Creates and returns a new context. In :obj:`ContextHandler` it returns an 
    475    instance of :obj:`Context`; you probably won't need to change this. 
    476  
    477 :obj:`openContext(widget, *args)` 
    478    The method is given a widget and some additional arguments based on which 
    479    the contexts are compared. In case of :obj:`DomainContextHandler` this is 
    480    a domain. There can be one or more such arguments. Note that the method 
    481    :obj:`openContext` which we talked about above is a method of 
    482    :obj:`OWBaseWidget`, while here we describe a method of context handlers. 
    483    Actually, :obj:`OWBaseWidget.openContext(self,contextName, *args)` calls 
    484    the context handler's, passing it's :obj:`self` and :obj:`*args`. 
    485  
    486    It needs to find a matching context and copy its settings to the widget or 
    487    construct a new context and copy the settings from the widget. Also, when an 
    488    old context is reused, it should be moved to the beginning of the list. 
    489    :obj:`ContextHandler` already defines this method, which should usually 
    490    suffice. :obj:`DomainContextHandler` adds very little to it. 
    491  
    492 :obj:`closeContext` 
    493    Copies the settings from the widget by calling :obj:`settingsFromWidget`. 
    494    You probably won't need to overwrite it. 
    495  
    496 :obj:`match` 
    497    The method is called by :obj:`openContext` to find a matching context. 
    498    Given an existing context and the arguments that were given to 
    499    :obj:`openContext` (for instance, a domain), it should decide whether the 
    500    context matches or not. If it returns 2, it is a perfect match (e.g. 
    501    domains are the same). If it returns 0, the context is not applicable 
    502    (e.g. some of the required attributes are missing). In case it returns a 
    503    number between 0 and 1 (excluding 0), the higher the number the better the 
    504    match. :obj:`openContext` will use the best matching context (or the 
    505    perfect one, if found). 
    506  
    507 :obj:`settingsToWidget` / :obj:`settingsFromWidget` 
    508    Copy the settings to and from the widget. 
    509  
    510 :obj:`fastSave` 
    511    This function is called by the widget's :obj:`__setattr__` each time any 
    512    widget's variable is changed to immediately synchronize the context with 
    513    the state of the widget. The method is really needed only when 
    514    :obj:`syncWithGlobal` is set. When the context is closed, 
    515    :obj:`closeContext` will save the settings anyway. 
    516  
    517 :obj:`cloneContext` 
    518    Given an existing context, it prepares and returns a copy. The method is 
    519    optional; :obj:`copy.deepcopy` can be used instead. 
     407Avoid it if you can. If you can't, here's the list of the methods you may need to implement. You may want to copy as much from the :obj:`DomainContextHandler` as you can. 
     408 
     409 
     410__init__ 
     411Has the same arguments as the :obj:`DomainContextHandler`'s, except for the :obj:`fields`. 
     412 
     413newContext 
     414Creates and returns a new context. In :obj:`ContextHandler` is returns an instance of :obj:`Context`; you probably won't need to change this. 
     415 
     416openContext 
     417The method is given a widget and some additional arguments based on which the contexts are compared. In case of :obj:`DomainContextHandler` this is a domain. There can be one or more such arguments. Note that the method :obj:`openContext` which we talked about above is a method of :obj:`OWBaseWidget`, while here we describe a method of context handlers. Actually, :obj:`OWBaseWidget(self, contextName, *args)` calls the context handler's, passing it's :obj:`self` and :obj:`*args`. 
     418 
     419It needs to find a matching context and copy its settings to the widget or construct a new context and copy the settings from the widget. Also, when an old context is reused, it should be moved to the beginning of the list. :obj:`ContextHandler` already defines this method, which should usually suffice. :obj:`DomainContextHandler` adds very little to it. 
     420 
     421closeContext 
     422Copies the settings from the widget by calling :obj:`settingsFromWidget`. You probably won't need to overwrite it. 
     423 
     424match 
     425The method is called by :obj:`openContext` to find a matching context. Given an existing context and the arguments that were given to :obj:`openContext` (for instance, a domain), it should decide whether the context matches or not. If it returns 2, it is a perfect match (e.g. domains are the same). If it returns 0, the context is not applicable (e.g. some of the required attributes are missing). In case it returns a number between 0 and 1 (excluding 0), the higher the number the better the match. :obj:`openContext` will use the best matching context (or the perfect one, if found). 
     426 
     427settingsToWidget/settingsFromWidget 
     428Copy the settings to and from the widget. 
     429 
     430fastSave 
     431This function is called by the widget's :obj:`__setattr__` each time any widget's variable is changed to immediately synchronize the context with the state of the widget. The method is really needed only when :obj:`syncWithGlobal` is set. When the context is closed, :obj:`closeContext` will save the settings anyway. 
     432 
     433cloneContext 
     434Given an existing context, it prepares and returns a copy. The method is optional; :obj:`copy.deepcopy` can be used instead. 
    520435 
    521436 
     
    525440 
    526441Settings can be saved in two different places. Orange Canvas save 
    527 settings in .ini files in its application data directory. Each widget type has 
    528 a separate file; for instance, the scatter plot's settings are saved in 
     442settings in .ini files in directory 
     443Orange/OrangeWidgets/widgetSettings. Each widget type has its separate 
     444file; for instance, the scatter plot's settings are saved in 
    529445:obj:`ScatterPlot.ini`. Saved schemas and applications save 
    530446settings in .sav files; the .sav file is placed in the same directory 
     
    535451Saving and loading is done automatically by canvas or the 
    536452application. In a very rare case you need it to run these operations 
    537 manually, the functions involved are :obj:`loadSettings(self, file=None)`, 
    538 :obj:`saveSettings(self, file=None)`, :obj:`loadSettingsStr(self, str)`, 
     453manually, the functions involved are :obj:`loadSettings(self, file = 
     454None)`, :obj:`saveSettings(self, file = None)`, 
     455:obj:`loadSettingsStr(self, str)`, 
    539456:obj:`saveSettingsStr(self)`. The first two load and save from 
    540457the file; if not given, the default name (widget's name + 
  • docs/widgets/rst/visualize/linearprojection.rst

    r11422 r11359  
    4444nicely characterizes mamals from the other organisms, and that laying eggs is 
    4545something that birds do. This specific visualization was obtained using FreeViz 
    46 ([1]_), while the widget also implements an interface to supervised 
    47 principal component analysis ([2]_), partial least squares (for a nice 
    48 introduction, see [3]_), and RadViz visualization and 
     46([Demsar2007]_), while the widget also implements an interface to supervised 
     47principal component analysis ([Koren2003]_), partial least squares (for a nice 
     48introduction, see [Boulesteix2007]_), and RadViz visualization and 
    4949associated intelligent data visualization technique called VizRank  
    50 ([4]_) 
     50([Leban2006]_) 
    5151 
    5252.. image:: images/LinearProjection-Zoo.png 
     
    7777order to understand how a change of one anchor affects the positions of the 
    7878data points. Controls in :obj:`Forces` box are used to set the parameters that 
    79 define the type of the forces between the data points (see [1]_). 
     79define the type of the forces between the data points (see [Demsar2007]_). 
    8080In any linear projection, projections of unit vector that are very short 
    8181compared to the others indicate that their associated attribute is not very 
     
    9393 
    9494The fourth projection search technique that can be accessed from this widget 
    95 is VizRank search algorithm with RadViz visualization ([4]_). This is 
     95is VizRank search algorithm with RadViz visualization ([Leban2006]_). This is 
    9696essentially the same visualization and projection search method as implemented 
    9797in :ref:`Radviz`. 
     
    107107---------- 
    108108 
    109 .. [1] Demsar J, Leban G, Zupan B. FreeViz-An intelligent multivariate 
     109.. [Demsar2007] Demsar J, Leban G, Zupan B. FreeViz-An intelligent multivariate 
    110110   visualization approach to explorative analysis of biomedical data. J Biomed 
    111111   Inform 40(6):661-71, 2007. 
    112112 
    113 .. [2] Koren Y, Carmel L. Visualization of labeled data using linear 
     113.. [Koren2003] Koren Y, Carmel L. Visualization of labeled data using linear 
    114114   transformations, in: Proceedings of IEEE Information Visualization 2003 
    115115   (InfoVis'03), 2003. `PDF <http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=3DDF0DB68D8AB9949820A19B0344C1F3?doi=10.1.1.13.8657&rep=rep1&type=pdf>`_ 
    116116 
    117 .. [3] Boulesteix A-L, Strimmer K (2006) Partial least squares: 
     117.. [Boulesteix2007] Boulesteix A-L, Strimmer K (2006) Partial least squares: 
    118118   a versatile tool for the analysis of high-dimensional genomic data, 
    119119   Briefings in Bioinformatics 8(1): 32-44.  
    120120   `Abstract <http://bib.oxfordjournals.org/cgi/content/abstract/8/1/32>`_ 
    121121 
    122 .. [4] Leban, G., B. Zupan, et al. (2006). "VizRank: Data Visualization 
     122.. [Leban2006] Leban, G., B. Zupan, et al. (2006). "VizRank: Data Visualization 
    123123   Guided by Machine Learning." Data Mining and Knowledge Discovery 13(2): 
    124124   119-136. 
  • docs/widgets/rst/visualize/radviz.rst

    r11422 r11359  
    3333----------- 
    3434 
    35 Radviz ([1]_) is a neat non-linear multi-dimensional visualization 
     35Radviz ([Hoffman1997]_) is a neat non-linear multi-dimensional visualization 
    3636technique that can display data on three or more attributes in a 2-dimensional 
    3737projection. The visualized attributes are presented as anchor points equally 
     
    4747 
    4848The snapshot shown below shows a Radviz widget with a visualization of the 
    49 data set from functional genomics ([2]_). In this particular 
     49data set from functional genomics ([Brown2000]_). In this particular 
    5050visualization the data instances are colored according to the corresponding 
    5151class, and the visualization space is colored according to the computed class 
     
    6464"spo mid") is quite characteristic for instance of class Ribo, which at the 
    6565same time have comparable lower value of other attributes. High values of 
    66 heat 20 and diau f are characteristic for Resp class. See [3]_ and 
    67 [5]_ for further illustrations of utility of Radviz in analysis of 
     66heat 20 and diau f are characteristic for Resp class. See [Leban2006]_ and 
     67[Mramor2007]_ for further illustrations of utility of Radviz in analysis of 
    6868this and similar data set from functional genomics. Other options in the 
    6969:obj:`Settings` tab are quite standard. The :obj:`Point size` controls the size 
     
    8686 
    8787Just like all point-based visualizations, this widget includes tools for 
    88 intelligent data visualization (VizRank and FreeViz, see [3]_) and 
    89 [4]_) and interface for explorative data analysis - selection of data 
     88intelligent data visualization (VizRank and FreeViz, see [Leban2006]_) and 
     89[Demsar2007]_) and interface for explorative data analysis - selection of data 
    9090points in visualization. Just like in :ref:`Scatter Plot` widget, intelligent 
    9191visualization can be used to find a set of attributes that would result in an 
     
    103103---------- 
    104104 
    105 .. [1] Hoffman,P.E. et al. (1997) DNA visual and analytic data mining. 
     105.. [Hoffman1997] Hoffman,P.E. et al. (1997) DNA visual and analytic data mining. 
    106106   In the Proceedings of the IEEE Visualization. Phoenix, AZ, pp. 437-441. 
    107107 
    108 .. [2] Brown, M. P., W. N. Grundy, et al. (2000). 
     108.. [Brown2000] Brown, M. P., W. N. Grundy, et al. (2000). 
    109109   "Knowledge-based analysis of microarray gene expression data by using 
    110110   support vector machines." Proc Natl Acad Sci U S A 97(1): 262-7. 
    111111 
    112 .. [3] Leban, G., B. Zupan, et al. (2006). "VizRank: Data Visualization 
     112.. [Leban2006] Leban, G., B. Zupan, et al. (2006). "VizRank: Data Visualization 
    113113   Guided by Machine Learning." Data Mining and Knowledge Discovery 13(2): 
    114114   119-136. 
    115115 
    116 .. [4] Demsar J, Leban G, Zupan B. FreeViz-An intelligent multivariate 
     116.. [Demsar2007] Demsar J, Leban G, Zupan B. FreeViz-An intelligent multivariate 
    117117   visualization approach to explorative analysis of biomedical data. J Biomed 
    118118   Inform 40(6):661-71, 2007. 
    119119 
    120 .. [5] Mramor M, Leban G, Demsar J, Zupan B. Visualization-based 
     120.. [Mramor2007] Mramor M, Leban G, Demsar J, Zupan B. Visualization-based 
    121121   cancer microarray data classification analysis. Bioinformatics 23(16): 
    122122   2147-2154, 2007. 
  • docs/widgets/rst/visualize/scatterplot.rst

    r11422 r11359  
    6868all the pairs of attributes to find interesting scatterplots. Intelligent data 
    6969visualizations techniques are about finding such visualizations automatically. 
    70 Orange's Scatterplot includes one such tool called VizRank ([1]_), that 
     70Orange's Scatterplot includes one such tool called VizRank ([Leban2006]_), that 
    7171can be in current implementation used only with classification data sets, that 
    7272is, data sets where instances are labeled with a discrete class. The task of 
     
    9898learning it would be best to leave them at their defaults. The options are 
    9999grouped according to the different aspects of the methods as described in 
    100 [1]_. The projections are evaluated through testing a selected 
     100[Leban2006]_. The projections are evaluated through testing a selected 
    101101classifier (:obj:`Projection evaluation method` default is k-nearest neighbor 
    102102classification) using some standard evaluation technique 
     
    202202---------- 
    203203 
    204 .. [1] Leban G, Zupan B, Vidmar G, Bratko I. VizRank: Data 
     204.. [Leban2006] Leban G, Zupan B, Vidmar G, Bratko I. VizRank: Data 
    205205   Visualization Guided by Machine Learning. Data Mining and Knowledge 
    206206   Discovery 13(2): 119-136, 2006. 
Note: See TracChangeset for help on using the changeset viewer.