Re: [Numpy-discussion] documentation, sound and music [was: doc? music through mathematical relations between LPCM samples and musical elements/characteristics]

[Renato Fabbri]

I think you gave me the answers:

0) It seems reasonable to just use sphinx,
no jekyll or anything more, only if a need for it is found.
I might use some HTML generated by vimwiki for pure convenience.

1) Make the main documentation with sphinx.
That means joining:

and


2) github.io, gitbook, readthedocs, all is just as fine.
Maybe github.io makes it easier and has more features,
while readthedocs is maybe more traditional for these kinds
of python-related docs.

3) just realese on pypi, make the documentation fine
and tell the list. If any major release deserves a message,
it is ok to send.

3.1) A scikit to make psychoacoutic experiments, synthesize audio and music,
is not absurd nor deeply compelling.

4) Am I loosing something? Being mindful of this question is always good,
but that is it,
we are on track.
(the python and latex files are on github, so there is an issue tracker,
a wiki etc etc there if anything comes up)

tx++



On Wed, Jan 31, 2018 at 9:20 PM, Robert Kern  wrote:

> On Thu, Feb 1, 2018 at 7:38 AM, Renato Fabbri 
> wrote:
> >
> > Dear Scipy-ers,
> >
> > If you think I should split the message so that
> > things get more clear...
> >
> > But the things are:
> > 1) How to document numpy-heavy projects?
>
> There is nothing particularly special about numpy-heavy projects with
> respect to documentation. The tools used for numpy and scipy's
> documentation may (or may not) be useful to you. For example, you may want
> to embed matplotlib plots into your documentation.
>
>   https://pypi.python.org/pypi/numpydoc
>
> But if not, don't worry about it. Sphinx is all most numpy-heavy projects
> need, like most Python projects. Hosting the documentation on either
> readthedocs or Github is fine. Do whatever's convenient for you. Either is
> just as convenient for us.
>
> > 2) How to better make these contributions available
> > to the numpy/scipy community?
>
> Having it up on Github and PyPI is all you need to do. Participate in
> relevant mailing list conversations. While we don't forbid release
> announcement emails on either of the lists, I wouldn't do much more than
> announce the initial release and maybe a really major update (i.e. not for
> every bugfix release).
>
> > Directions will be greatly appreciated.
> > I suspect that this info is all gathered somewhere
> > I did not find.
>
> Sorry this isn't gathered anywhere, but truly, the answer is "there is not
> much to it". You're doing everything right. :-)
>
> --
> Robert Kern
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>


-- 
Renato Fabbri
GNU/Linux User #479299
labmacambira.sourceforge.net
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] documentation, sound and music [was: doc? music through mathematical relations between LPCM samples and musical elements/characteristics]

[Robert Kern]

On Thu, Feb 1, 2018 at 7:38 AM, Renato Fabbri 
wrote:
>
> Dear Scipy-ers,
>
> If you think I should split the message so that
> things get more clear...
>
> But the things are:
> 1) How to document numpy-heavy projects?

There is nothing particularly special about numpy-heavy projects with
respect to documentation. The tools used for numpy and scipy's
documentation may (or may not) be useful to you. For example, you may want
to embed matplotlib plots into your documentation.

  https://pypi.python.org/pypi/numpydoc

But if not, don't worry about it. Sphinx is all most numpy-heavy projects
need, like most Python projects. Hosting the documentation on either
readthedocs or Github is fine. Do whatever's convenient for you. Either is
just as convenient for us.

> 2) How to better make these contributions available
> to the numpy/scipy community?

Having it up on Github and PyPI is all you need to do. Participate in
relevant mailing list conversations. While we don't forbid release
announcement emails on either of the lists, I wouldn't do much more than
announce the initial release and maybe a really major update (i.e. not for
every bugfix release).

> Directions will be greatly appreciated.
> I suspect that this info is all gathered somewhere
> I did not find.

Sorry this isn't gathered anywhere, but truly, the answer is "there is not
much to it". You're doing everything right. :-)

--
Robert Kern
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Extending C with Python

[Stefan Seefeld]

On 31.01.2018 17:58, Chris Barker wrote:
> I'm guessing you could use Cython to make this easier.

... or Boost.Python (http://boostorg.github.io/python), which has
built-in support for NumPy
(http://boostorg.github.io/python/doc/html/numpy/index.html), and
supports both directions: extending Python with C++, as well as
embedding Python into C++ applications.


Stefan

-- 

  ...ich hab' noch einen Koffer in Berlin...


___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Extending C with Python

[Chris Barker]

I'm guessing you could use Cython to make this easier. It's usually used
for calling C from Python, but can do the sandwich in both directions...

Just a thought -- it will help with some of that boilerplate code...

-CHB




On Tue, Jan 30, 2018 at 10:57 PM, Jialin Liu  wrote:

> Amazing! It works! Thank you Robert.
>
> I've been stuck with this many days.
>
> Best,
> Jialin
> LBNL/NERSC
>
> On Tue, Jan 30, 2018 at 10:52 PM, Robert Kern 
> wrote:
>
>> On Wed, Jan 31, 2018 at 3:25 PM, Jialin Liu  wrote:
>>
>>> Hello,
>>> I'm extending C with python (which is opposite way of what people
>>> usually do, extending python with C), I'm currently stuck in passing a C
>>> array to python layer, could anyone plz advise?
>>>
>>> I have a C buffer in my C code and want to pass it to a python function.
>>> In the C code, I have:
>>>
>>> npy_intp  dims [2];
 dims[0] = 10;
 dims[1] = 20;
 import_array();
 npy_intp m=2;
 PyObject * py_dims = PyArray_SimpleNewFromData(1, , NPY_INT16 ,(void
 *)dims ); // I also tried NPY_INT
 PyObject_CallMethod(pInstance, method_name, "O", py_dims);
>>>
>>>
>>> In the Python code, I want to just print that array:
>>>
>>> def f(self, dims):
>>>
>>>print ("np array:%d,%d"%(dims[0],dims[1]))
>>>
>>>
>>>
>>> But it only prints the first number correctly, i.e., dims[0]. The second
>>> number is always 0.
>>>
>>
>> The correct typecode would be NPY_INTP.
>>
>> --
>> Robert Kern
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
>>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] documentation, sound and music [was: doc? music through mathematical relations between LPCM samples and musical elements/characteristics]

[Renato Fabbri]

Dear Scipy-ers,

If you think I should split the message so that
things get more clear...

But the things are:
1) How to document numpy-heavy projects?
2) How to better make these contributions available
to the numpy/scipy community?

Directions will be greatly appreciated.
I suspect that this info is all gathered somewhere
I did not find.

PS. I apologize for the cross-post, this is a message
sent to numpy list but without any replies, so I found
fit to send the message to both lists.

Thanks in advance,
Best,
R.

-- Forwarded message --
From: Renato Fabbri 
Date: Tue, Jan 30, 2018 at 8:32 PM
Subject: doc? music through mathematical relations between LPCM samples and
musical elements/characteristics
To: Discussion of Numerical Python 


the half-shape suite:
archive.org/details/ShapeSuite
was completely synthesized using psychophysical relations
for each resulting 16bit 44kHz samples:
https://arxiv.org/abs/1412.6853

I am thinking about the ways in which to make the documentation
at least to:
* mass (music and audio in sample sequences): the framework.
It might be considered a toolbox, but it is not a package:
https://github.com/ttm/mass/

* music: a package for making music, including the routines
used to make the half-shape suite:
https://github.com/ttm/music

==
It seems reasonable at first to:

* upload the package to PyPI (mass is not a package),
music is there (beta but there).

* Make available some summary of the file tree, including
some automated code documentation.
As I follow numpy's convention (or try to), and the package and framework
are
particularly useful for proficient numpy users,
I used Sphinx. The very preliminary version is:
https://pythonmusic.github.io/

* Make a nice readthedocs documentation.
"music" project name was taken so I made:
http://music-documentation.readthedocs.io/en/latest/
"mass" project name was also taken so I made:
http://musicmass.readthedocs.io/en/latest/

And I found these URLs clumsy. Is there a standard or would you go with
musicpackage.read.. and
massframework.read...
?

More importantly:
* would you use readthedocs for the sphinx/doxigen
output?
* would you use readthedocs.org or a gitbook would be better or...?

Should I contact the scipy community to make available a scikit or
integrate it to numpy in any way beyond using and citing
it appropriately?.

BTW. I am using vimwiki with some constant attempt to organize and track
my I/O:
https://arxiv.org/abs/1712.06933
So maybe a unified solution for all these documentation instances
using a wiki structure seems reasonable at the moment.
Maybe upload the generated html from Sphinx and from Vimwiki
to readthedocs...?

Best,
R.


-- 
Renato Fabbri
GNU/Linux User #479299
labmacambira.sourceforge.net



-- 
Renato Fabbri
GNU/Linux User #479299
labmacambira.sourceforge.net
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Using np.frombuffer and cffi.buffer on array of C structs (problem with struct member padding)

[Allan Haldane]

On 01/31/2018 02:06 AM, Joe wrote:

Does someone know of a function or a convenient way to automatically
derive a dtype object from a C typedef struct string or a cffi.typeof()?


I remember when I wrote those docs over a year ago, I searched for an 
established way to do this but didn't find one. If you find/come up with 
one, let us know and I might add a pointer or description of it in the docs.


Searching just now, I came across this recent gist:

https://gist.github.com/inactivist/4ef7058c2132fa16759d

So it looks like we can do something like:

# typemap from C type to numpy type may need some work...
typemap = {'char': 'byte', 'short': 'short', 'int': 'intc',
   'long long': 'longlong', 'size_t': 'intp',
   'float': 'float', 'double': 'double'}

def extract_field_info(tp):
fields = []
for field, fieldtype in tp.fields:
if fieldtype.type.kind == 'primitive':
format = typemap[fieldtype.type.cname]
else:
format = extract_field_info(fieldtype.type)
fields.append((field, format, fieldtype.offset))
return fields

 from cffi import FFI
 ffi = FFI()
 ffi.cdef("struct foo { int a; char b; double d;};")
 tp = ffi.typeof('struct foo')

 names, formats, offsets = zip(*extract_field_info(tp))
 np.dtype({'names': names, 'formats': formats, 'offsets': offsets})
 # compare to: np.dtype('i4,i1,f8', align=True)

I just made that up now and it may be buggy and have missing corner 
cases. But if you agree it works, maybe we can mention it in the 
structured array docs instead of the vague sentence there now, that 
"some work may be needed to obtain correspondence with the C struct".


Allan


Am 27.01.2018 10:30 schrieb Joe:

Thanks for your help on this! This solved my issue.


Am 25.01.2018 um 19:01 schrieb Allan Haldane:

There is a new section discussing alignment in the numpy 1.14 structured
array docs, which has some hints about interfacing with C structs.

These new 1.14 docs are not online yet on scipy.org, but in the meantime
  you can view them here:
https://ahaldane.github.io/user/basics.rec.html#automatic-byte-offsets-and-alignment 



(That links specifically to the discussion of alignments and padding).

Allan

On 01/25/2018 11:33 AM, Chris Barker - NOAA Federal wrote:




The numpy dtype constructor takes an “align” keyword that will pad it
for you.


https://docs.scipy.org/doc/numpy-1.13.0/reference/generated/numpy.dtype.html 



-CHB



___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion



___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion


___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion


___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion