Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 11 2018 11:47

    rparini on master

    Test against Sage-8.4 Import scipy.integrate Merge pull request #167 from ab… (compare)

  • Nov 11 2018 11:47
    rparini closed #167
  • Nov 10 2018 19:26
    rparini opened #167
  • Nov 04 2018 17:00

    rparini on sage-8.4

    Import scipy.integrate (compare)

  • Oct 28 2018 21:38

    rparini on sage-8.4

    Test against Sage-8.4 (compare)

  • Oct 28 2018 21:35

    rparini on sage-8.4

    (compare)

  • Oct 02 2018 08:31

    rparini on master

    Add some advice on sage -pip s… Add sage 8.3 tests nodes() is now NodeDataView In… and 23 more (compare)

  • Oct 02 2018 08:31
    rparini closed #166
  • Oct 01 2018 19:13
    rparini synchronize #166
  • Oct 01 2018 19:13

    rparini on sage-8.3

    Rearrange to make more uniform (compare)

  • Oct 01 2018 18:48
    rparini synchronize #166
  • Oct 01 2018 18:48

    rparini on sage-8.3

    Fix torrent download link (compare)

  • Oct 01 2018 18:35
    rparini synchronize #166
  • Oct 01 2018 18:35

    rparini on sage-8.3

    Fix .yml syntax error (compare)

  • Oct 01 2018 12:52
    rparini synchronize #166
  • Oct 01 2018 12:52

    rparini on sage-8.3

    Fix TypeError on Linux (compare)

  • Oct 01 2018 12:25
    rparini synchronize #166
  • Oct 01 2018 12:25

    rparini on sage-8.3

    Install sage for Linux via torr… (compare)

  • Sep 30 2018 09:05
    rparini commented #166
  • Sep 29 2018 20:40
    rparini synchronize #166
Chris Swierczewski
@cswiercz
@SatorisX That's "absolutely" true. Good catch!
Based on the output you showed me, I suppose this means that we were losing accuracy with the old method. This is especially important for my plans with theta in the paper I mentioned.
Chris Swierczewski
@cswiercz
Take a look at the format in test_abelfunctions.py and test_puiseux.py here for example on how to implement the tests.
James Collins
@collijk

@cswiercz
Hey Chris, I fetched your merged code, and it compiles okay, but I'm getting a number of errors with I try to run test or clean, or when I try to import abelfunctions to do anything.

I'd like to share the error output with you, but I'm having trouble figuring out how to send the Traceback to a txt file. The only thing I've been able to find is the command line redirect operator ">", but when I use that when running python setup.py test > testerror.txt, for instance, all I end up with is a .txt file that contains "running test". Any tips?

When running clean I get
File "setup.py", line 80, in run to_remove.remove(f) ValueError: list.remove(x): x not in list

When running test I get a ton of unittest.loader.ModuleImportFailure statements.

When I try to import abelfunctions in a python console I get
ValueError: abelfunctions.differentials.Differential has the wrong size, try recompiling.

Chris Swierczewski
@cswiercz

@SartorisX Unfortunately, I'm aware of non-passing tests. The tests pass for the example I'm doing on the RCV paper so I'm holding off on fixing the other examples.

I don't know how to capture the output from python setup.py test.

As for clean, I'm not sure why you're getting this error. One thing I do recall from way back when is that Python has constructs for navigating directories in an OS-independent way. My guess is that I haven't done that in setup.py which may be why it can't find the appropriate directories when running clean. The way test searches for directories may also be influenced by this but I doubt it.

When running test did you compile first? python setup.py build_ext --inplace.

The differentials error is definitely a recompile error. It's a thing that happens when comparing the objects stored in the .so Cython outputs to the contents of the .pxd headers.

James Collins
@collijk

@cswiercz Hey, I wrote you another post about stuff I'd done since the last update, but my internet got trippy last night and it seemed to send but apparently didn't. First, to your response: I did end up getting test and import statements to run, which is good. I was pretty sure I compiled first, but I've been mucking around in code for many hours since then so its completely possible that it was a simple error like you suggested.

I think I might have been having collision errors with the merged code I pulled and stuff in my working directory. The rcv branch is still using (importantly importing) the riemanntheta.py and not the .pyx version. Anyway, before I finally got this stuff to work I've been trying some other things:

I copied over the riemann_theta.pyx code into a new director and cribbed your setup.py to compile theta by itself. This is mostly for my benefit so I could shrink the scope of the codebase and maybe get a better understanding of what's going on. I got it to compile fine, but I'm again having import issues. Specifically the following:

import riemanntheta
Traceback (most recent call last):

  File "<ipython-input-1-4f7caa86dc4f>", line 1, in <module>
    import riemanntheta

  File "C:\Users\James\Documents\Theta\riemanntheta\__init__.py", line 1, in <module>
    from .riemann_theta import theta

  File "riemanntheta\riemann_theta.pyx", line 891, in init riemanntheta.riemann_theta (riemanntheta\riemann_theta.c:28223)
    theta = RiemannTheta_Function()

  File "riemanntheta\riemann_theta.pyx", line 400, in riemanntheta.riemann_theta.RiemannTheta_Function.__init__ (riemanntheta\riemann_theta.c:3680)
    self.uniform = True

AttributeError: 'riemanntheta.riemann_theta.RiemannTheta_Function' object has no attribute 'uniform'

I tried a handful of things to resolve this. Removing uniform from the__init__ just throws the error on deriv_accuracy_radius, the next attribute in the __init__. From what I can find on stackexchange and elsewhere, this sort of error is frequently caused by whitespace issues, which I spent quite some time checking, or cyclic import statements that confuse the interpreter (i.e. mutually dependent modules), which I don't believe are present.

I spent some time on this and wasn't making any progress, so I've moved on to working on the c/cython bridge. I'm mostly just moving stuff from the bridge over to the main code body right now and making notes of where the if/else statements can be pared down, where documentation needs to be written, etc. Anyway, I'll talk to you shortly!

Chris Swierczewski
@cswiercz

@SartorisX I'm not sure what the situation is with setup.py. Things have been working well from my side of things. Giant merges are always tricky. It's tough to avoid with young code.

I think I had the same issue with my branch. I'll upload my current status to the rcv_theta branch so you can see what I changed. The entire Riemann theta code needs to be reworked anyway so I'm not too worried.

Well, I'm not sure if I want to commit what I did. It's nearly a complete deletion of the current Riemann theta code. Let me finish up the RCV paper and then I'll think about how to best organize the code. AT the moment I might end up writing a simple pointwise Riemann theta just to get something working. We can build off of it from there.
Chris Swierczewski
@cswiercz
Oh man. My numpy implementation is so slow...compared to the C-implementation.
James Collins
@collijk
@cswiercz I think it would be much easier to work with a clean and readable version of theta even if it's slow. I spend massively more time just trying to figure out exactly what's happening than I do modifying/writing code. The benefit of git is that even if your rework erases most of what's already there, I still have my copies and can figure out how to work the important things in.
Chris Swierczewski
@cswiercz

@SartorisX That's probably a good idea. (Refactors sometimes require complete rewrites.) There are some chunks that should remain as they are (lattice_reduce.c, the C code containing the finite sum stuff) but should definitely be looked at for errors and thoroughly tested. Much of the Cython stuff needs to be reworked, especially to take advantage of memoryviews since Grady and I discovered that the approach we're using is OS-dependent. (!)

I still recommend branching from dev and putting your work into there. Don't worry about including a depreciated directory. Git will take care of keeping track of old stuff.

Once I'm done with this RCV stuff I'd like to work with you more closely on Riemann theta. It's always been something I've wanted to make more robust.

Chris Swierczewski
@cswiercz
Testing 1...2...3...
lesshaste
@lesshaste
hi
Chris Swierczewski
@cswiercz
Hello
Chris Swierczewski
@cswiercz
Ping
Chris Swierczewski
@cswiercz
@jupsal Do you have a moment to chat?
Chris Swierczewski
@cswiercz
I just wanted to bounce some ideas off of you for testing radiusN. I'm working on a test suite already. The most basic test is to compare the output of radiusN with radius1 and radius2 with identical input. I don't know what data is out there for direct comparison testing. Maybe we can test against some Maple output?
The problem with testing against Maple output is that we're not guaranteed that the Maple code is correct by some other measure. Still, it may be valuable.
Jeremy Upsal
@jupsal
Hello
Chris Swierczewski
@cswiercz
Sup.
I'm just writing up a response in the PR.
Jeremy Upsal
@jupsal
Okay
Chris Swierczewski
@cswiercz
Take a look at my last comment in particular.
Jeremy Upsal
@jupsal
Are you talking about rewriting LLL in particular?
Chris Swierczewski
@cswiercz
Well, that's one quick fix. I'm very proud of Grady and his hard work writing LLL from scratch in C. However, people who are experts in understanding the algorithm wrote the Sage implementation. Additionally, Grady's code only works for double matrices whereas Sage's LLL works for a wider range of data types.
I was referring mostly to the finite sum code.
My main reason for playing with the idea of rewriting (using the data structures in that Trac patch I showed you) is that I don't know to what degree Numpy output is considered "normal" in Sage code.
Jeremy Upsal
@jupsal
I lean towards not rewriting it right now for some sort of a reason which boils down to "I don't want to."
But if adding more code seems hacky then we should probably do it right.
Chris Swierczewski
@cswiercz
I agree with the "I don't want to" reason.
Jeremy Upsal
@jupsal
Of course that reason can also be "I don't want to right now, but maybe later."
Chris Swierczewski
@cswiercz
I think the code has enough weight and momentum such that we should prefer the option of writing the necessary C code...which maybe we can do together via pair programming.
Jeremy Upsal
@jupsal
That sounds right to me.
Chris Swierczewski
@cswiercz
Eh, so far it hasn't been a problem for either of us. If it becomes a problem for a future user then they can implement it themselves. :)
Cool. Want to meet at a cafe or in your office sometime soon?
I have two lunch meetings this week, both downtown, (jobs) so I would suggest we meet in the afternoon.
Jeremy Upsal
@jupsal
That sounds good to me. Are you in today? Otherwise tomorrow afternoon works for me.
Chris Swierczewski
@cswiercz
Let's do tomorrow afternoon.
Jeremy Upsal
@jupsal
Okay sounds good. 1? 2?
Chris Swierczewski
@cswiercz
Is 3 okay? I have a lunch meeting with someone in Bellevue so it'll take some time for me to get back here.
Jeremy Upsal
@jupsal
Works for me. I prefer my office since I am not much of a coffee drinker. See you then?
Chris Swierczewski
@cswiercz
Sounds good.
See you then. I recommend taking a brief look at finite_sum.c before we meet. It should me self-explainatory. I also have a couple of minor improvements I want to implement since my C skills have improved since 2012.
Jeremy Upsal
@jupsal
I am looking at it now. My C skills have certainly not so this will be fun.
Chris Swierczewski
@cswiercz
(For example, I didn't know back then that C99 allowed dynamic stack-allocated arrays.)
Ha ha. No worries. It's a very dumb language in the sense that you need to do a lot of things manually. It'll mostly be a bookkeeping exercise.
It might not hurt to write up some Maple tests beforehand. There is a philosophy called "test-driven development" where developers will write tests first before actually writing the code.
I'm pushing my tests and changes soon.
Jeremy Upsal
@jupsal
Okay I will take a look at it once you push.
Chris Swierczewski
@cswiercz
I think for those derivative value tests we should put them in test_theta.py.