mutable numeric type

[Andreas Beyer]

There has been quite some traffic about mutable and immutable data types
on this list. I understand the issues related to mutable numeric data
types. However, in my special case I don't see a better solution to the
problem.
Here is what I am doing:

I am using a third party library that is performing basic numerical
operations (adding, multiplying, etc.) with objects of unknown type. Of
course, the objects must support the numerical operators. In my case the
third party library is a graph algorithm library and the assigned
objects are edge weights. I am using the library to compute node
distances, etc.

I would like to be able to change the edge weights after creating the
edges. Otherwise, I would have to remove the edges and re-create them
with the new values, which is quite costly. Since I also didn't want to
change the code of the graph library, I came up with a mutable numeric
type, which implements all the numerical operators (instances are of
course not hashable). This allows me to change the edge weights after
creating the graph.

I can do the following:

>>x = MutableNumeric(10)
y = MutableNumeric(2)
x*y

20

>>x.value = 1.3
x*y

2.6000000000000001

>>>

The effect of numerical operations is determined by the contained basic
data types:

>>x.value = 3
x/2

1

>>x.value = 3.0
x/2

1.5

>>>

Augmented operations change the instance itself:

>>x.value = 0
id(x)

-1213448500

>>x += 2
x

MutableNumeric(2)

>>id(x) # show that same instance

-1213448500

>>>

Is there anything wrong with such design? I am a bit surprised that
Python does not already come with such data type (which is really simple
to implement). Is there something that I am missing here?

Thanks!
Andreas

[Steven D'Aprano]

On Mon, 01 Jan 2007 19:20:21 -0800, Andreas Beyer wrote:

I am using a third party library that is performing basic numerical
operations (adding, multiplying, etc.) with objects of unknown type. Of
course, the objects must support the numerical operators. In my case the
third party library is a graph algorithm library and the assigned
objects are edge weights. I am using the library to compute node
distances, etc.

I would like to be able to change the edge weights after creating the
edges. Otherwise, I would have to remove the edges and re-create them
with the new values, which is quite costly.

You've measured it or you're guessing?

Presumably the edges and/or nodes store the weights somewhere. Why not
just reassign the weight directly in place?

It isn't easy to judge whether your scheme is good bad or indifferent when
we know so little about the graph library you are using.

Since I also didn't want to change the code of the graph library,

You could subclass the graph class.

Another possibility is to dynamically modify the library, without changing
its source code. E.g.
from GraphLibrary import GraphWalker as _gw
import GraphLibrary

def myGraphWalker(args):
x = _gw(args)
do_something_to(x)
return x

GraphLibrary.GraphWalker = myGraphWalker
# now use GraphWalker as normal, except it has your
# code instead of the original

This works for class methods as well.

I came up with a mutable numeric
type, which implements all the numerical operators (instances are of
course not hashable). This allows me to change the edge weights after
creating the graph.

This is another alternative, although I still don't understand why you
can't just reassign the weights in place.
--
Steven D'Aprano

[pgarrone]

Way to go.
Try doing this.
x = MutableNumeric(42)
y = x
x += 42
print y

[Helmut Jarausch]

pg******@acay.com.au wrote:

Way to go.
Try doing this.
x = MutableNumeric(42)

^^^^^^^^^^^^^^
where is this defined?

y = x
x += 42
print y

--
Helmut Jarausch

Lehrstuhl fuer Numerische Mathematik
RWTH - Aachen University
D 52056 Aachen, Germany

[Peter Otten]

Andreas Beyer wrote:

There has been quite some traffic about mutable and immutable data types
on this list. I understand the issues related to mutable numeric data
types. However, in my special case I don't see a better solution to the
problem.
Here is what I am doing:

I am using a third party library that is performing basic numerical
operations (adding, multiplying, etc.) with objects of unknown type. Of
course, the objects must support the numerical operators. In my case the
third party library is a graph algorithm library and the assigned
objects are edge weights. I am using the library to compute node
distances, etc.

I would like to be able to change the edge weights after creating the
edges. Otherwise, I would have to remove the edges and re-create them
with the new values, which is quite costly. Since I also didn't want to
change the code of the graph library, I came up with a mutable numeric
type, which implements all the numerical operators (instances are of
course not hashable). This allows me to change the edge weights after
creating the graph.

I can do the following:

>>x = MutableNumeric(10)
>>y = MutableNumeric(2)
>>x*y

20

>>x.value = 1.3
>>x*y

2.6000000000000001

>>>

The effect of numerical operations is determined by the contained basic
data types:

>>x.value = 3
>>x/2

1

>>x.value = 3.0
>>x/2

1.5

>>>

Augmented operations change the instance itself:

>>x.value = 0
>>id(x)

-1213448500

>>x += 2
>>x

MutableNumeric(2)

>>id(x) # show that same instance

-1213448500

>>>

Is there anything wrong with such design?

The library you are planning to feed with your mutable numbers has to be
designed with such somewhat unusual beasts in mind. For instance, it can no
longer cache intermediate values as their constituents may have changed
without notification.
Don't use that design unless the library's designers explicitly allow it or
at least after extensive testing. Be aware that in the latter case every
new version of the library may break your app beyond fixability.

I am a bit surprised that
Python does not already come with such data type (which is really simple
to implement).

I'm guessing: Such a type is not normally useful -- and if you need it it is
really simple to implement :-)

Peter

[Diez B. Roggisch]

Helmut Jarausch schrieb:

pg******@acay.com.au wrote:

>Way to go.
Try doing this.
x = MutableNumeric(42)

^^^^^^^^^^^^^^
where is this defined?

In the OPs example.

Diez