[Numpy-discussion] (no subject)
Hi, I would like to make a sanity test to check that calling the same function with different parameters actually gives different results. I am currently using:: try: npt.assert_almost_equal(numpy_result, result) except AssertionError: assert True else: assert False But maybe you have a better way? I couldn't find a 'assert_not_equal' and the above just feels stupid. thanks for your advice. V- -- Valentin Hänel Scientific Software Developer Blue Brain Project http://bluebrain.epfl.ch/ ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] (no subject)
* Olivier Delalleau [120120]: > Not sure if there's a better way, but you can do it with > > assert not numpy.allclose(numpy_result, result) Okay, thats already better than what I have. thanks V- ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [OFFTOPIC] creating/working NumPy-ndarrays in C++
* Michael Droettboom [2012-04-03]: > On 04/03/2012 12:48 PM, Chris Barker wrote: > >It would be nice to have a clean C++ wrapper around ndarrays, but > >that doesn't exist yet (is there a good reason for that?) > Check out: > > http://code.google.com/p/numpy-boost/ Just out of curiosity, any idea how this compares to: http://www.eos.ubc.ca/research/clouds/software/pythonlibs/num_util/num_util_release2/Readme.html ? It's just that with: http://code.google.com/p/numpy-boost/ which was also mentioned on this list, I now know of four alternatives for boost+NumPy (including the built-in support). Would anyone like to share perhaps a sentence or two about their experience in using either? (comparisons, of course, are highly appreciated :D ) Thanks! V- ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [OFFTOPIC] creating/working NumPy-ndarrays in C++
Hi Chris, thanks for your answer. * Chris Barker [2012-04-09]: > 2012/4/8 Hänel Nikolaus Valentin >: > http://www.eos.ubc.ca/research/clouds/software/pythonlibs/num_util/num_util_release2/Readme.html > > that looks like it hasn't been updated since 2006 -- I"d say that > makes it a non-starter Yeah, thats what I thought... Until I found it in several production codes... > The new numpy-boost project looks promising, though. > > > which was also mentioned on this list, I now know of four alternatives > > for boost+NumPy (including the built-in support). > > 4? http://www.boost.org/doc/libs/1_49_0/libs/python/doc/v2/numeric.html (old) https://github.com/ndarray/Boost.NumPy (new) http://code.google.com/p/numpy-boost/ http://www.eos.ubc.ca/research/clouds/software/pythonlibs/num_util/num_util_release2/Readme.html Or am I missing something? V- ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [OFFTOPIC] creating/working NumPy-ndarrays in C++
* Chris Barker [2012-04-09]: > 2012/4/9 Hänel Nikolaus Valentin : > > http://www.eos.ubc.ca/research/clouds/software/pythonlibs/num_util/num_util_release2/Readme.html > >> > >> that looks like it hasn't been updated since 2006 -- I"d say that > >> makes it a non-starter > > > > Yeah, thats what I thought... Until I found it in several production > > codes... > > are they maintaining it? Well, no... thats «legacy code» that was handed down to me, more or less. > >> 4? > > > > http://www.boost.org/doc/libs/1_49_0/libs/python/doc/v2/numeric.html > > (old) > > > > https://github.com/ndarray/Boost.NumPy > > (new) > > > > http://code.google.com/p/numpy-boost/ > (also pretty old -- I see this:) > > - Numpy (numpy.scipy.org) (Tested versions: 1.1.1, though >= 1.0 should work) > - Python (www.python.org) (Tested versions: 2.5.2, though >= 2.3 should work) > > both pretty old versions. > > http://www.eos.ubc.ca/research/clouds/software/pythonlibs/num_util/num_util_release2/Readme.html > > > also pretty old. > > So I'd go with the actively maintained on -- or Cython -- what I can > tell you is that Cython is being very widely used in the > numerical/scientific computing community -- but I haven't seen a lot > of Boost users. Maybe they use different mailing lists, and dont go to > SciPy or Pycon... Yeah, I would choose cython... if I had a choice... I have had boost.python mentioned a single time throughout the last four editions of EuroScipy2012 > I'm not sure you made your use case clear -- are you writing C++ > specifically for calling form Python? or are you working on a C++ lib > that will be used in C++ apps as well as Python apps? Currently just curious about the different tools available to fascilitate interoperability between numpy and boost.python. V- ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove current 1.7 branch?
Hi, * Charles R Harris [2012-07-12]: > Travis and I agree that it would be appropriate to remove the current 1.7.x > branch and branch again after a code freeze. That way we can avoid the pain > and potential errors of backports. It is considered bad form to mess with > public repositories that way, so another option would be to rename the > branch, although I'm not sure how well that would work. Suggestions? I am a silent listener on this list, but in this case I may have some valuable insights to share, on the two proposed options: 1) delete the branch You can delete the branch in the remote repository. Anyone using the --prune option for fetch, pull or remote update will have their corresponding remote-tracking-branch deleted (pruned) automatically. The problem arises, if people have created a local branch from the remote-tracking-branch, they need to explicitly delete it. If they don't, they risk pushing that branch again after it has been recreated in the remote repository (depends on the setting of 'push.default'). In fact, what I have seen in the past is people not deleting their local branch and when the branch is recreated, they receive a message from git when they push, that the branch could not be updated. This is because their setting for 'push.default' is set to 'matching' (which is the default) and suddenly the branch has appeared again in the remote repo, so git tries to push the local branch to remote branch (since they have the same name). But their local version of this branch is still at the old position and because the new remote branch does not contain the old branch's commits, a fast-forward is not possible and they end up merging the old commits into the new branch in a feeble attempt to somehow get rid of the annoying error message. In the end, you have a really bad mess including random merge commits that make no sense and suddenly re-appearing commits that were supposed to have been long forgotten. Do you trust everyone to a) read the mail the explains the need to delete their local branch and b) actually go and delete it? ;) Incidentally, if you wish the commits on the branch to be included in master, you must cherry-pick them, but from what I gather that has already been done. 2) merge the branch to master You can merge the branch to master and leave it at that. In this case, when you wish to make use of the branch again at a later stage, you fast-forward the branch to the commit from where it should be used again (which is most probably the commit that master points to) and then commit on that branch to actually create the bifurcation. With this option, nobody needs to take any explicit action. Anyone who has created a local branch to track that branch can simply merge the new remote-tracking-branch by fast-forward as and when it is used again. Of course, you must include all commits that are on that branch. If there are any commits who's changes you would not like to see in master, first merge, and the use 'git revert' on those commits to undo the changes. So, as you can see it depends on the git skill-level of the developers, how much risk you are willing to take, and how clean and pure you would like to have your history. Personally, I would favour option 1) since it is the cleaner solution, but in the light of the probable number of forks of the numpy repo, option 2) sounds like a safer bet IMHO. Hope that helps. V- ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Remove current 1.7 branch?
Hi,
* Ralf Gommers [2012-07-19]:
> On Thu, Jul 19, 2012 at 4:14 PM, Charles R Harris > On Thu, Jul 19, 2012 at 7:45 AM, Travis Oliphant wrote:
> >
> >> I'm not sure what the conclusion actually was from this long thread.
> >>
> >> But, in trying to update the 1.7.x branch, I ended up in a very odd state
> >> with respect to the github pages. I used git filter-branch to try and get
> >> rid of "empty" commits that were showing up for some reason. However,
> >> this resulted in a branch that seemed fine on my local version but when
> >> pushed to github ended up duplicating nearly every commit in the
> >> maintenance branch so that the commits page for maintenance/1.7.x showed a
> >> duplicate commit for every actual commit,
> >>
> >> I didn't know how to fix this except to delete the branch (after doing a
> >> diff with master), recreate the branch, and apply the saved diff as a
> >> patch. I'm very sorry if I messed anyone up.
> >>
> >> I thought the plan was to delete the branch anyway. There could be
> >> something else wrong as well, but I'm not sure what the implication of your
> >> message is, exactly.
> >>
> >> People using the maintenance/1.7.x branch (how many people were actually
> >> using it?) will need to delete their local branch and re-pull from github.
> >>
> >>
> > I agree that the easiest thing to do is remove the current 1.7 branch and
> > branch again. It isn't quite according to the book of Linus, but it will
> > get us where we need to be.
> >
> > git push upstream :maintenance/1.7.x
> >
>
> No, why? The damage is already done, this doesn't change anything. The
> point was, as several people pointed out, to merge 1.7.x into master. Then
> it could have either been deleted and recreated, or fast-forwarded. The
> merge should have been straightforward. Nathaniel provided all commands
> needed.
Indeed, deleting the branch is no longer required, as the wrong history
which was erroneously pushed has already been deleted. I suppose it
would be good to get confirmation that the maintenance/1.7.x branch
should now be at commit f93774d. Is that correct?
> For now, let's leave it as is. Everyone who was using 1.7.x should just
> delete his branch and recreate it. Then force push it to their own Github
> account if necessary.
+1
Alternatively you can use 'git reset --hard @{u}' where '@{u}' is short
for upstream-branch:
zsh» git co maintenance/1.7.x
Switched to branch 'maintenance/1.7.x'
Your branch and 'origin/maintenance/1.7.x' have diverged,
and have 4 and 124 different commits each, respectively.
zsh» git log -1 --oneline
95c84bf Merge pull request #318 from certik/ondrej1
zsh» git reset --hard @{u}
HEAD is now at f93774d Update release notes and version number.
zsh» git log -1 --oneline
f93774d Update release notes and version number.
Using '@{u}' requires you to have an appropriate upstream-branch set:
zsh» git config remote.origin.url
git://github.com/numpy/numpy.git
zsh» git config branch.maintenance/1.7.x.remote
origin
zsh» git config branch.maintenance/1.7.x.merge
refs/heads/maintenance/1.7.x
Or from the .git/config:
zsh» cat .git/config |& grep -A 2 "remote \"origin\""
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git://github.com/numpy/numpy.git
zsh» cat .git/config |& grep -A 3 maintenance/1.7.x
[branch "maintenance/1.7.x"]
remote = origin
merge = refs/heads/maintenance/1.7.x
Hope that helps.
V-
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
