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
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.
Maybe a couple under the TestMaple TestCase?
Jeremy Upsal
@jupsal
Yeah that sounds like a good place for them.
Chris Swierczewski
@cswiercz
I've always wanted to do some numerical derivative approximations for additional testing but I've always had an aversion to long and messy formulas. :) One day, right? :)
I just have to say that I really appreciate working with you on this bit of Abelfunctions. Writing for it has been really lonely over the past few years. Writing code with other people is much more fun than writing code alone.
Chris Swierczewski
@cswiercz
@jupsal I'm checking out for now. I'm going to update the PR so that it encompasses the radius calculation as well as the actual derivative calculation we'll implement tomorrow.
Jeremy Upsal
@jupsal
Sorry messages weren't showing up on my screen! I will take a look at stuff soon and see you tomorrow!
Chris Swierczewski
@cswiercz
No worries. See you then.
Ian Stuart
@perllaghu
Afternoon folks.
I'm trying to install AbelFunctions into a Jupyter notebook (derived from jupyter/scipy-notebook, version-locked to the last version before Jupyter removed Python 2.7)
The sage setup commands want SAGE_ROOT set, however I've just been using the Conda Sage libraries, so there is no full Sage install...