2020-12-30 13:07:18 +0100 | received badge | ● Popular Question (source) |

2020-12-30 13:07:18 +0100 | received badge | ● Notable Question (source) |

2020-12-27 15:00:53 +0100 | received badge | ● Notable Question (source) |

2019-01-13 09:58:49 +0100 | received badge | ● Famous Question (source) |

2018-06-16 21:49:30 +0100 | received badge | ● Notable Question (source) |

2018-02-03 17:51:10 +0100 | received badge | ● Popular Question (source) |

2016-06-07 11:02:08 +0100 | received badge | ● Notable Question (source) |

2014-01-09 14:01:43 +0100 | received badge | ● Popular Question (source) |

2013-10-23 22:04:46 +0100 | received badge | ● Popular Question (source) |

2013-06-20 09:10:16 +0100 | received badge | ● Taxonomist |

2011-01-11 10:41:45 +0100 | marked best answer | Time-consuming of compiled files First, while compiling something will often cause a slight increase in speed when the loop itself is a problem, mostly the real speedup comes not just from compiling functions but by marking them up with type information ("cdef int a") and so on. The reason interpreted languages like Python are slower than compiled languages isn't because of the interpreter, that's a common misconception. (If that were so then removing the interpreter loop and executing the bytecode directly would be fast, and it's not: people have tried.) The reason they're slow is more because of "multiple dispatch": when you give Python "a+b", it has to check the types of a and b, see whether there's an add method, etc., all of which takes lots and lots of cycles while C just compiles to (say) one flop and a copy. So the real gain comes from specifying types, but of course this comes at a cost: C doesn't have a type corresponding to an arbitrary-length integer, for example. As for your particular functions, you can understand the behaviour if you actually look at what the functions return (I added a "return f" to the end of each function, which is something I think you probably should have done first): Two things are going on: the first is that the operations are binding differently, so it's parsing
which isn't what we wanted. The following code
(more) |

2011-01-11 10:36:10 +0100 | commented answer | Time-consuming of compiled files Thank you very much - I did lots of mistakes (Im beginner in Sage/Python and not much experience in programming in general, so that comment helps!). I experiment with my implementations of modern integer-factoring algorithm, so the integers have usually >>20 digits - so theres no straight-forward way to speed up with Cython I guess? |

2011-01-11 08:01:38 +0100 | received badge | ● Editor (source) |

2011-01-11 08:00:50 +0100 | asked a question | Time-consuming of compiled files I have made two files, first named "speedtest.sage", second "speedtest_compiled.spyx" speedtest.sage: speedtest.spyx: They are equal (modulo names of the speedtest-function). I have this output on my notebook: The interpretated Python-Code of speedtest() behaves absolutely normal, as you can see - BUT the compiled Cython-Code behaves strange, not only that it is so extremely slow, its consumed time is not even close to linear in n (notice that I could not evaluate speedtest_compiled(10^6), it took too long. What is the explanation for this - and how to compile correctly to gain the 10-1000x speedup I've read about? |

2011-01-11 07:52:02 +0100 | commented answer | Efficient kernel-computing of sparse GF2 matrices Ok, thank you, perhaps it will be implemented in coming versions. |

2011-01-10 12:40:07 +0100 | commented answer | Efficient kernel-computing of sparse GF2 matrices First didn't change the speed, probably it uses the same algorithm with sparse=True?! Did not find one of the algorithm, Im a bit surprised about that, they should be of general interest, but Im new to sage, maybe I just didnt see it. Yes, implementation is always possible, but I hoped for done work :) |

2011-01-09 22:30:58 +0100 | asked a question | Efficient kernel-computing of sparse GF2 matrices To compute the kernel of a sparse GF(2) matrix A I simply do But for (highly) sparse GF(2) matrices there are (many) much faster algorithm to compute the kernel, surely some of them are implemented in sage, but by which command I apply them? (Tutorial and online help could'nt answer that) |

2011-01-09 16:06:01 +0100 | commented answer | Converting kernel to matrix That is it! Thank you. |

2011-01-09 16:05:36 +0100 | marked best answer | Converting kernel to matrix (Showing my work). The first thing I tried was the obvious: which didn't work. So looked at B: and saw that it clearly knows about the matrix I think you're looking for. In Sage, functionality often lives inside objects, so if you type help(B) or or type "B." and then tab, you can see the list of internal functions, and I found both .matrix and .basis_matrix. I think either should work here, so: Is that what you were after? |

2011-01-09 16:05:36 +0100 | received badge | ● Scholar (source) |

2011-01-09 07:15:35 +0100 | asked a question | Converting kernel to matrix I construct a matrix A and compute its kernel by Now I want to convert B to a matrix, such that I can use .nrows() and other matrix-methods, how to do that? |

2011-01-08 16:37:16 +0100 | received badge | ● Student (source) |

2011-01-08 11:07:17 +0100 | commented answer | Compiling .spyx-files Yes, sorry, thank you Mike and DSM - it seems as if I intended to annoy people here with this. I did correct that in my posting, but didn't realize that this could be the mistake ... To be sure: On my machine theres absolutely no speed-up of the compiled version (its even a bit slower), whys that? |

2011-01-08 11:05:44 +0100 | received badge | ● Supporter (source) |

2011-01-08 08:11:29 +0100 | asked a question | Compiling .spyx-files This is an implementation of the pollard-rho factorization-algorithm in sage (filename: exp.sage) I load it with " But trying to compile named as " What is wrong here? Probably many things - im totally new to Sage, coming from Pari-gp and work in console-mode - no experiences with C or Python. Thank you. |

Copyright Sage, 2010. Some rights reserved under creative commons license. Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.