Re: type-checking support in Python?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Gabriel Genellina

    Re: type-checking support in Python?

    En Mon, 06 Oct 2008 11:19:58 -0300, Joe Strout <joe@strout.net escribió:
    Finally, one thing I've considered is adopting some identifier prefixes
    indicating type. Maybe "iFoo" for integer, "fFoo" for floating-point
    numbers, "d" for dictionary, "l" for list, "t" for tuple, "o" for
    object, and "v" for variable types that may be more than one of the
    above. I gather (from just a couple days of browsing) that such a
    naming convention isn't common in the Python community, but is there
    anyone else here who does it? I'd rather adopt an existing standard
    (even if it's not widely used) than make one up.
    Apart from the wise words that others have said, I'd add that I see no
    point in identifier prefixes when they merely indicate "type" (in the
    Python sense or even a broader sense) - called "system Hungarian notation"
    by some.
    In contrast, the prefix used in "apps Hungarian notation" declares the
    "kind" or "intent" of the variable, and it may be useful in some cases.
    This appears to be the original intent of Charles Simonyi when he wrote
    his paper [1]; the differences between both approaches are discussed here
    [2].
    As an example, in the oil industry here in my country there is a mix of
    measurement units in common usage. Depth is measured in meters, but pump
    stroke in inches; loads in lbs but pressures in kg/cm². So it's important
    to keep track of which unit some variable represents - its type would be
    always float, and that carries no information; but its unit *is* important
    informacion, so I sometimes use a postfix to indicate that.
    Variable names should be *meaningful* - before automatically sticking an
    "f" or "i" or "m_" prefix to something, think what you gain from it. If
    you always represent a street address using a string in your application,
    "szAddress" (or "sAddress") don't give you any more information than
    "address" alone, so the prefix is useless.

    [1] http://msdn.microsoft.com/en-us/library/Aa260976.aspx
    [2] http://blogs.msdn.com/ericlippert/ar.../12/52989.aspx

    --
    Gabriel Genellina

  • Lawrence D'Oliveiro

    #2
    Re: type-checking support in Python?

    In message <mailman.2089.1 223358567.3487. python-list@python.org >, Gabriel
    Genellina wrote:
    As an example, in the oil industry here in my country there is a mix of
    measurement units in common usage. Depth is measured in meters, but pump
    stroke in inches; loads in lbs but pressures in kg/cm².
    Isn't the right way to handle that to attach dimensions to each number?

    Comment

    • Lorenzo Gatti

      #3
      Re: type-checking support in Python?

      On 7 Ott, 08:36, Lawrence D'Oliveiro <l...@geek-
      central.gen.new _zealandwrote:
      In message <mailman.2089.1 223358567.3487. python-l...@python.org >, Gabriel
      >
      Genellina wrote:
      As an example, in the oil industry here in my country there is a mix of
      measurement units in common usage. Depth is measured in meters, but pump
      stroke in inches; loads in lbs but pressures in kg/cm².
      >
      Isn't the right way to handle that to attach dimensions to each number?
      Can you afford to avoid floats and ints? Attaching suffixes is the
      best one can do with the builtin types.
      In C++ one can check dimensions at compile time (http://www.boost.org/
      doc/libs/1_36_0/doc/html/boost_units.htm l) with a modest increase of
      cumbersomeness, but Python would need very heavyweight classes
      containing a value and its dimension and a replacement of all needed
      functions and operations.

      Regards,
      Lorenzo Gatti

      Comment

      • Gabriel Genellina

        #4
        Re: type-checking support in Python?

        En Tue, 07 Oct 2008 03:36:12 -0300, Lawrence D'Oliveiro
        <ldo@geek-central.gen.new _zealandescribi ó:
        In message <mailman.2089.1 223358567.3487. python-list@python.org >, Gabriel
        Genellina wrote:
        >
        >As an example, in the oil industry here in my country there is a mix of
        >measurement units in common usage. Depth is measured in meters, but pump
        >stroke in inches; loads in lbs but pressures in kg/cm².
        >
        Isn't the right way to handle that to attach dimensions to each number?
        Maybe, but I prefer the values to be plain float objects. In my case it's
        not that units are dynamic themselves: "this" file format has depth in
        feet, "that" one uses meters, but that's known from start. I think I'd
        attach units to values if they were dynamic and I had to reproduce the
        original format exactly, but hasn't happened yet (fortunately).

        --
        Gabriel Genellina

        Comment

        • Bas

          #5
          Re: type-checking support in Python?

          On Oct 7, 8:36 am, Lawrence D'Oliveiro <l...@geek-
          central.gen.new _zealandwrote:
          In message <mailman.2089.1 223358567.3487. python-l...@python.org >, Gabriel
          >
          Genellina wrote:
          As an example, in the oil industry here in my country there is a mix of
          measurement units in common usage. Depth is measured in meters, but pump
          stroke in inches; loads in lbs but pressures in kg/cm².
          >
          Isn't the right way to handle that to attach dimensions to each number?
          What they taught me as a physics undergrad is to always convert random
          units given as input to SI units as soon as possible, do all your
          calculations internally in SI units and (only if really needed)
          convert back to arbitrary units on output. Now, 15 years later, I am
          still trying to stick to this rule whenever possisble. This convention
          allows you to 'forget' about units and save your pre/post-fixes for
          the exceptional case:
          inch = 0.0254
          lenght_inch = some_user_input _in_inch()
          length = length_inch * inch

          I have heard about some python package which overloads numbers and
          calculations to include units (quick google found unum, not sure if
          that is the only one). I guess that unless you are dealing with life-
          critical equipment or are using extreme programming, this is overkill
          (but I guess python is not really the right language for that anyway,
          imagine a garbage collection just when you want to launch your
          shuttle).

          Bas

          Comment

          • Aaron \Castironpi\ Brady

            #6
            Re: type-checking support in Python?

            On Oct 7, 5:24 am, Bas <wegw...@gmail. comwrote:
            On Oct 7, 8:36 am, Lawrence D'Oliveiro <l...@geek-
            >
            central.gen.new _zealandwrote:
            In message <mailman.2089.1 223358567.3487. python-l...@python.org >, Gabriel
            >
            Genellina wrote:
            As an example, in the oil industry here in my country there is a mix of
            measurement units in common usage. Depth is measured in meters, but pump
            stroke in inches; loads in lbs but pressures in kg/cm².
            >
            Isn't the right way to handle that to attach dimensions to each number?
            >
            What they taught me as a physics undergrad is to always convert random
            units given as input to SI units as soon as possible, do all your
            calculations internally in SI units and (only if really needed)
            convert back to arbitrary units on output.
            (snip)

            If you think it's a potential source of error, a lightweight version
            wouldn't be hard to implement. This one is absolute minimal, using
            strings for the units. Multiplication is harder, since you want 'foot
            pounds' == 'pound feet'.
            >>class UnitScalar:
            .... def __init__( self, val, type ):
            .... self.val, self.type= val, type
            .... def __add__( self, other ):
            .... assert self.type== other.type, 'Must be same type'
            .... return self.__class__( self.val+ other.val,
            self.type )
            .... def __repr__( self ):
            .... return '<UnitScalar %f %s>'% ( self.val, self.type )
            ....
            >>a, b= UnitScalar( 2, 'feet' ), UnitScalar( 3, 'feet' )
            >>a+ b
            <UnitScalar 5.000000 feet>
            >>a, b= UnitScalar( 2, 'feet' ), UnitScalar( 3, 'inches' )
            >>a+ b
            Traceback (most recent call last):
            File "<stdin>", line 1, in <module>
            File "<stdin>", line 5, in __add__
            AssertionError: Must be same type

            Comment

            • Sebastien Binet

              #7
              Re: type-checking support in Python?

              hi,

              On Oct 7, 3:24 am, Bas <wegw...@gmail. comwrote:
              I have heard about some python package which overloads numbers and
              calculations to include units (quick google found unum, not sure if
              that is the only one). I guess that unless you are dealing with life-
              critical equipment or are using extreme programming, this is overkill
              (but I guess python is not really the right language for that anyway,
              imagine a garbage collection just when you want to launch your
              shuttle).
              FWIW, the python papers volume 3 issue 1 is mentionning another
              package, 'scalar':



              cheers,
              sebastien.

              Comment

              • dg.google.groups@thesamovar.net

                #8
                Re: type-checking support in Python?

                I also wrote a units package which I'm using for a project of my own
                (a spiking neural network simulator package called 'Brian'), released
                separately as a package called Piquant which you can get at
                sourceforge:

                Download Piquant for free. A Python package extending NumPy and SciPy to allow specification of numbers and arrays with physical units.


                I'm also looking for people to help improve it (get in touch!). The
                way the package works is to have a Quantity class derived from float,
                with extra operations. One thing that is different from the other
                packages out there (and the reason I went to the effort of writing my
                own package rather than using unum or scalar) is that we also have a
                QuantityArray or qarray class that derives from numpy.ndarray. There
                are at the moment two supported types of qarray, with homogeneous
                units (one unit for the whole array), and heterogeneous units
                (different unit for each item in the array). At the moment the
                heterogeneous units implementation is horrible and very slow, but I
                have a plan for a nicer version at some point (based on numpy's
                broadcasting rules, so allowing you to have one unit for each row or
                each column in a matrix for example).

                Actually I think it would be a really good idea for someone at some
                point to make a standardised system for units and add it to numpy/
                scipy. I'd love to do it myself, but at the moment I have grant
                applications, papers to finish, etc... :-(

                Dan

                Sebastien Binet wrote:
                hi,
                >
                On Oct 7, 3:24�am, Bas <wegw...@gmail. comwrote:
                I have heard about some python package which overloads numbers and
                calculations to include units (quick google found unum, not sure if
                that is the only one). I guess that unless you are dealing with life-
                critical equipment or are using extreme programming, this is overkill
                (but I guess python is not really the right language for that anyway,
                imagine a garbage collection just when you want to launch your
                shuttle).
                >
                FWIW, the python papers volume 3 issue 1 is mentionning another
                package, 'scalar':


                >
                cheers,
                sebastien.

                Comment

                • Erik Max Francis

                  #9
                  Re: type-checking support in Python?

                  dg.google.group s@thesamovar.ne t wrote:
                  I also wrote a units package which I'm using for a project of my own
                  (a spiking neural network simulator package called 'Brian'), released
                  separately as a package called Piquant which you can get at
                  sourceforge:
                  >
                  Download Piquant for free. A Python package extending NumPy and SciPy to allow specification of numbers and arrays with physical units.

                  >
                  I'm also looking for people to help improve it (get in touch!). The
                  way the package works is to have a Quantity class derived from float,
                  with extra operations. One thing that is different from the other
                  packages out there (and the reason I went to the effort of writing my
                  own package rather than using unum or scalar) is that we also have a
                  QuantityArray or qarray class that derives from numpy.ndarray. There
                  are at the moment two supported types of qarray, with homogeneous
                  units (one unit for the whole array), and heterogeneous units
                  (different unit for each item in the array).
                  I have a unit system module (unity) in progress as well (it's working
                  but it's as yet unreleased), but which takes a different approach which
                  I think has more promise. Instead of having multiple united types
                  derived from different fundamental types, it has its own type Quantity
                  which takes two arguments: the amount and the units (which are further
                  data structures). That way, the amount and the units are kept
                  separately and the unit system doesn't know anything specific about the
                  amount and only deals with the unit system. Operations between
                  quantities enforce the type system (either combining the units for
                  operations like multiplication, or requiring that they be compatible for
                  operations like addition or comparison), and simply perform the
                  appropriate operations on the amount without enforcing any type. This
                  allows you to have united operations on integers, floating point
                  numbers, decimals, vectors, matrices, quaternions -- whatever values you
                  may want to support units.

                  Mine is more of a dimensional analysis tool (as well as a general unit
                  converter) since it allows you to define a basis of units, then define
                  units within that basis and manipulate them -- thus it remembers the
                  definitions of all the units it has encountered. You can define whole
                  new unit systems (e.g., c.g.s. vs. SI) and have them all relate to each
                  other, or even define brand new unit systems (e.g., man-day-widgets for
                  questions like, "If it takes one man three days to make two widgets, how
                  many widgets can five men make in two weeks?").

                  --
                  Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
                  San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis
                  Those who forget the past are condemned to repeat it.
                  -- George Santayana

                  Comment

                  • Aaron \Castironpi\ Brady

                    #10
                    Re: type-checking support in Python?

                    On Oct 7, 3:52 pm, Erik Max Francis <m...@alcyone.c omwrote:
                    dg.google.gro.. .@thesamovar.ne t wrote:
                    (e.g., man-day-widgets for
                    questions like, "If it takes one man three days to make two widgets, how
                    many widgets can five men make in two weeks?").
                    Wouldn't that be 'widgets per man-day'?

                    Comment

                    • Steven D'Aprano

                      #11
                      Re: type-checking support in Python?

                      On Tue, 07 Oct 2008 19:36:12 +1300, Lawrence D'Oliveiro wrote:
                      In message <mailman.2089.1 223358567.3487. python-list@python.org >,
                      Gabriel Genellina wrote:
                      >
                      >As an example, in the oil industry here in my country there is a mix of
                      >measurement units in common usage. Depth is measured in meters, but
                      >pump stroke in inches; loads in lbs but pressures in kg/cm².
                      >
                      Isn't the right way to handle that to attach dimensions to each number?
                      This thread may be dead by now, but just for the record "dimensions " are
                      not "units". 1 inch and 1 kilometre have the same dimension (Length) but
                      obviously they can't be added to make 2 inches (or 2 kilometres).

                      On the other hand, dimensions are very handy for sanity results; if
                      somebody suggested to me that adding 15 inch second per gram to 195 cm
                      month per tonne gave 6.7 gallons per millgram hour, I don't even need to
                      do the conversion to see that this *must* be wrong because the dimensions
                      don't match: the original arguments have dimensions Length*Time/Mass but
                      the supposed argument has dimensions L**3/(M*T).

                      Dimensions are useful to check if quantities are compatible, but you
                      still need to convert them to a common unit.


                      --
                      Steven

                      Comment

                      • Arnaud Delobelle

                        #12
                        Re: type-checking support in Python?

                        On Oct 7, 9:52 pm, Erik Max Francis <m...@alcyone.c omwrote:
                        I have a unit system module (unity) in progress as well (it's working
                        but it's as yet unreleased), but which takes a different approach which
                        I think has more promise.  Instead of having multiple united types
                        derived from different fundamental types, it has its own type Quantity
                        which takes two arguments: the amount and the units (which are further
                        data structures).  That way, the amount and the units are kept
                        separately and the unit system doesn't know anything specific about the
                        amount and only deals with the unit system.  Operations between
                        quantities enforce the type system (either combining the units for
                        operations like multiplication, or requiring that they be compatible for
                        operations like addition or comparison), and simply perform the
                        appropriate operations on the amount without enforcing any type.  This
                        allows you to have united operations on integers, floating point
                        numbers, decimals, vectors, matrices, quaternions -- whatever values you
                        may want to support units.
                        >
                        Mine is more of a dimensional analysis tool (as well as a general unit
                        converter) since it allows you to define a basis of units, then define
                        units within that basis and manipulate them -- thus it remembers the
                        definitions of all the units it has encountered.  You can define whole
                        new unit systems (e.g., c.g.s. vs. SI) and have them all relate to each
                        other, or even define brand new unit systems (e.g., man-day-widgets for
                        questions like, "If it takes one man three days to make two widgets, how
                        many widgets can five men make in two weeks?").
                        >
                        --
                        Erik Max Francis && m...@alcyone.co m &&http://www.alcyone.com/max/
                          San Jose, CA, USA && 37 18 N 121 57 W && AIM, Y!M erikmaxfrancis
                           Those who forget the past are condemned to repeat it.
                            -- George Santayana
                        It's funny how many people have had the need for this! I have written
                        a module that seems to be very similar. It contains:

                        * A BasicDimension class whose objects are basis vectors in the
                        dimensions vector space.
                        * A Dimension class which is simply a vector in the dimension vector
                        space, which optionally can be named.

                        E.g.

                        distance = new_basic_dim(' distance', 'metre')
                        mass = new_basic_dim(' mass', 'gram')
                        time = new_basic_dim(' time', 'second')

                        speed = new_dim('speed' , distance/time)
                        accel = new_dim('accel' , speed/time)

                        area = new_dim('area', distance**2)
                        volume = new_dim('volume ', distance**3)

                        density = new_dim('densit y', mass/volume)

                        force = new_dim('force' , mass*accel)

                        Then:
                        >>volume/area
                        >>distance
                        >>speed*time
                        >>distance
                        * A Units class whose objects can registered with a dimension

                        * DObject class whose objects are just objects with a dimension. You
                        can do arithmetic with DObjects provided that you can do arithmetic
                        with their underlying objects.
                        >>s = Units(time, 1)
                        >>ms = Units(time, 0.001)
                        >>s.symbol = 's'
                        >>print DObject(2, s) + DObject(19, ms)
                        2.019 s
                        >>m = Units(distance, 1)
                        >>print DObject(3.0, m) / DObject(2.0, s)
                        1.5 [units distance*time**-1 1]
                        >>Units(distanc e/time, 1).symbol = 'm/s'
                        >>print DObject(3.0, m) / DObject(2.0, s)
                        1.5 m/s
                        >>print DObject(23.0, s).convert_to(m s)
                        23000 ms

                        * You can also have separate 'Dimensions systems', e.g. you can have
                        speed, force, time as basic dimensions instead of distance, mass, time
                        (IOW you have a different basis for the dimensions vector space).
                        Then you can convert DObjects between systems. Although this feature
                        is not working to my satisfaction.

                        I have designed this as part of a program to mark automatically online
                        maths/science worksheets, so speed is not really a consideration in my
                        implementation.

                        I have always thought of this as just a tool for my program, but I
                        suppose it can be seen as a sort of dynamic type checking system!

                        --
                        Arnaud

                        Comment

                        • Lawrence D'Oliveiro

                          #13
                          Re: type-checking support in Python?

                          In message <0100470d$0$206 46$c3e8da3@news .astraweb.com>, Steven D'Aprano
                          wrote:
                          ... just for the record "dimensions " are not "units".
                          Yeah, OK. "unit" = "dimensions " x "multiplier ".

                          Where "multiplier " can be arbitarily set to 1 for SI units.

                          Comment

                          • Lawrence D'Oliveiro

                            #14
                            Re: type-checking support in Python?

                            In message
                            <1df0ae7e-d5c5-4839-9788-703cd58232c5@q9 g2000hsb.google groups.com>, Bas
                            wrote:
                            What they taught me as a physics undergrad is to always convert random
                            units given as input to SI units as soon as possible, do all your
                            calculations internally in SI units and (only if really needed)
                            convert back to arbitrary units on output.
                            If only NASA's Mars Climate Orbiter engineers had followed that rule. :)

                            Comment

                            Working...