#9863: Error in sage/graphs/genus.pyx on ia64-Linux-suse
-----------------------+----------------------------------------------------
Reporter: mpatel | Owner: mvngu
Type: defect | Status: new
Priority: blocker | Milestone: sage-4.6
Component: doctest | Keywords:
Author: | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
-----------------------+----------------------------------------------------
Comment(by mderickx):
I also think that testing equality might by to strikt. While reading the
source code I read how get_memory_usage() works. And on linux it works by
asking top or prstat or the /proc filesystem how much memory the entire
python process is using in which sage is running. To fully understand the
fluctuations in the memory usage, we would need to know all the details of
the implementation of the CPython virtual machine which interprets the
python bytecode.
I suspect that the virtual machine is not asking memory from the os using
malloc for every python object it creates, but instead it uses malloc to
sometimes ask for a chuck of memory in which it can fiddle around and only
asks for a new peace of memory after it filled the old one (all this for
performance reasons). So deallocating memory would also proably go in the
same chunks. The scenario described above, and maybe many other scenarios
might cause that changes in how many memory is used by python objects
might not be in a 1-1 correspodence with changes in the total memory used
by the python process.
I'm curious if the observed change in memory usages really has something
to do with genus backtracker code. To bad I don't have acces to a linux
machine with a sage install, for then I could test certain things myself.
I really wonder if the problem also occurs if you change the assignment:
gb = sage.graphs.genus.simple_connected_genus_backtracker(G._backend._cg)
to something else.
The observed difference in precision is probably because of the way that
python prints floats.
{{{
sage: 2.132311r-2.132311r
0.0
}}}
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9863#comment:12>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
