Changeset 10074:77003de2365f in orange


Ignore:
Timestamp:
02/08/12 14:53:35 (2 years ago)
Author:
Lan Zagar <lan.zagar@…>
Branch:
default
rebase_source:
811365dd84849cbee71114bc3b9d585e7608868f
Message:

Corrected code fragments in rst.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • Orange/classification/lookup.py

    r10068 r10074  
    2222fields of constructed 
    2323features to facilitate their automatic computation. For instance, 
    24 the following script shows how to translate the `monks-1.tab` data set 
     24the following script shows how to translate the ``monks-1.tab`` data set 
    2525features into a more useful subset that will only include the features 
    2626``a``, ``b``, ``e``, and features that will tell whether ``a`` and ``b`` 
     
    259259 
    260260 
    261 In `table_s`, we have prepared a table in which instances are described 
    262 only by `a`, `b`, `e` and the class. The learner constructs a 
    263 :obj:`ClassifierByDataTable` and stores instances from `table_s` into its 
     261In ``table_s``, we have prepared a table in which instances are described 
     262only by ``a``, ``b``, ``e`` and the class. The learner constructs a 
     263:obj:`ClassifierByDataTable` and stores instances from ``table_s`` into its 
    264264:obj:`~ClassifierByDataTable.sorted_examples`. Instances are merged so that 
    265265there are no duplicates. 
     
    310310    >>> y2.get_value_from = abe 
    311311 
    312 Although `abe` determines the value of `y2`, `abe.class_var` is still `y`. 
     312Although ``abe`` determines the value of ``y2``, ``abe.class_var`` is still ``y``. 
    313313Orange doesn't mind (the whole example is artificial - the entire data set 
    314314will seldom be packed in an :obj:`ClassifierByDataTable`), but this can still 
     
    336336Let us, for the end, show another use of :obj:`LookupLearner`. With the 
    337337alternative call arguments, it offers an easy way to observe feature 
    338 interactions. For this purpose, we shall omit `e`, and construct a 
    339 :obj:`ClassifierByDataTable` from `a` and `b` only (part of 
     338interactions. For this purpose, we shall omit ``e``, and construct a 
     339:obj:`ClassifierByDataTable` from ``a`` and ``b`` only (part of 
    340340:download:`lookup-table.py <code/lookup-table.py>`): 
    341341 
     
    344344 
    345345The script's output show how the classes are distributed for different 
    346 values of `a` and `b`:: 
     346values of ``a`` and ``b``:: 
    347347 
    348348    ['1', '1', '1'] <0.000, 48.000> 
     
    356356    ['3', '3', '1'] <0.000, 48.000> 
    357357 
    358 For instance, when `a` is '1' and `b` is '3', the majority class is '0', 
     358For instance, when ``a`` is '1' and ``b`` is '3', the majority class is '0', 
    359359and the class distribution is 36:12 in favor of '0'. 
    360360 
     
    376376    classifier is of type :obj:`ClassifierByLookupTable`, 
    377377    :obj:`ClassifierByLookupTable2` or :obj:`ClassifierByLookupTable3`, with 
    378     `class_var` and bound set set as given. 
    379  
    380     For example, using the data set `monks-1.tab`, to construct a new feature 
    381     from features `a` and `b`, this function can be called as follows. 
     378    ``class_var`` and bound set set as given. 
     379 
     380    For example, using the data set ``monks-1.tab``, to construct a new feature 
     381    from features ``a`` and ``b``, this function can be called as follows. 
    382382     
    383383        >>> new_var = Orange.feature.Discrete() 
     
    387387        <?, ?, ?, ?, ?, ?, ?, ?, ?> 
    388388 
    389     Function `lookup_from_bound` does not initialize neither `new_var` nor 
     389    Function ``lookup_from_bound`` does not initialize neither ``new_var`` nor 
    390390    the lookup table... 
    391391 
    392392.. function:: lookup_from_function(class_var, bound, function) 
    393393 
    394     ... and that's exactly where `lookup_from_function` differs from 
    395     :obj:`lookup_from_bound`. `lookup_from_function` first calls 
     394    ... and that's exactly where ``lookup_from_function`` differs from 
     395    :obj:`lookup_from_bound`. ``lookup_from_function`` first calls 
    396396    :obj:`lookup_from_bound` and then uses the function to initialize the 
    397397    lookup table. The other difference between this and the previous function 
    398     is that `lookup_from_function` also accepts bound sets with more than three 
     398    is that ``lookup_from_function`` also accepts bound sets with more than three 
    399399    features. In this case, it construct a :obj:`ClassifierByDataTable`. 
    400400 
     
    403403    properly initialized. 
    404404 
    405     For exercise, let us construct a new feature called `a=b` whose value will 
    406     be "yes" when `a` and `b` are equal and "no" when they are not. We will then 
     405    For exercise, let us construct a new feature called ``a=b`` whose value will 
     406    be "yes" when ``a`` and ``b`` are equal and "no" when they are not. We will then 
    407407    add the feature to the data set. 
    408408     
     
    424424        ... 
    425425 
    426     The feature was inserted with use of `orngCI.addAnAttribute`. By setting 
    427     `new_var.get_value_from` to `lookup` we state that when converting domains 
    428     (either when needed by `addAnAttribute` or at some other place), `lookup` 
    429     should be used to compute `new_var`'s value. (A bit off topic, but 
     426    The feature was inserted with use of ``orngCI.addAnAttribute``. By setting 
     427    ``new_var.get_value_from`` to ``lookup`` we state that when converting domains 
     428    (either when needed by ``addAnAttribute`` or at some other place), ``lookup`` 
     429    should be used to compute ``new_var``'s value. (A bit off topic, but 
    430430    important: you should never call 
    431431    :obj:`~Orange.feature.Descriptor.get_value_from` directly, but always  
     
    448448.. function:: dump_lookup_function(func) 
    449449 
    450     `dump_lookup_function` returns a string with a lookup function in 
    451     tab-delimited format. Argument `func` can be any of the above-mentioned 
     450    ``dump_lookup_function`` returns a string with a lookup function in 
     451    tab-delimited format. Argument ``func`` can be any of the above-mentioned 
    452452    classifiers or a feature whose 
    453453    :obj:`~Orange.feature.Descriptor.get_value_from` points to one of such 
    454454    classifiers. 
    455455 
    456     For instance, if `lookup` is such as constructed in the example for 
    457     `lookup_from_function`, it can be printed by:: 
     456    For instance, if ``lookup`` is such as constructed in the example for 
     457    ``lookup_from_function``, it can be printed by:: 
    458458     
    459459        >>> print dump_lookup_function(lookup) 
Note: See TracChangeset for help on using the changeset viewer.