[cctbxbb] repr for flex arrays

Fri Sep 14 11:00:25 PDT 2018

Hi, I think avoiding a copy is good.  What about this:

Flex type <type(a)>, focus: <a.focus()>, size: <len(a)> memory address
<address>, first and last element if len(a)>0: <a[0]>, <a[-1]>

Like numpy does, let's avoid printing every element.

On Fri, Sep 14, 2018 at 10:50 AM Nicholas Sauter <nksauter at lbl.gov> wrote:

> Yes, there is a philosophical objection to using .as_numpy_array().  Numpy
> only deals with a fixed number of data types, such as int, double, etc.
> Flex arrays can be extended to many other types such as Bragg spots,
> 2-vectors, 3-vectors, and 3x3 matrices.  Therefore, if we are going to take
> the performance hit and do a copy, I would simply recommend using a Python
> list:
>
> __repr__(a) :== list(a)
>
> Nick
>
> Nicholas K. Sauter, Ph. D.
> Senior Scientist, Molecular Biophysics & Integrated Bioimaging Division
> Lawrence Berkeley National Laboratory
> 1 Cyclotron Rd., Bldg. 33R0345
> Berkeley, CA 94720
> (510) 486-5713
>
> On Fri, Sep 14, 2018 at 9:56 AM, Nicholas Devenish <ndevenish at gmail.com>
> wrote:
>
>> I think as_numpy_array was just a suggestion of the simplest possible
>> starting implementation.
>>
>> But is there a philosophical objection to them being added?
>>
>> Nick
>>
>> On Fri, Sep 14, 2018 at 5:27 PM Graeme.Winter at Diamond.ac.uk
>> <Graeme.Winter at diamond.ac.uk> wrote:
>> >
>> > Does it? Dang! Thought it would be fly weight and just make the data
>> structures needed.
>> >
>> > If that’s the case then completely agree.
>> >
>> > Cheers Graeme
>> > ________________________________
>> > From: cctbxbb-bounces at phenix-online.org <
>> cctbxbb-bounces at phenix-online.org> on behalf of Aaron Brewster <
>> asbrewster at lbl.gov>
>> > Sent: 14 September 2018 17:23:41
>> > To: cctbx mailing list
>> > Subject: Re: [cctbxbb] repr for flex arrays
>> >
>> > Hi Graeme, I'm not sure what the right answer here is except I don't
>> think it is as_numpy_array().__repr__ as that does a copy.  No good for big
>> arrays.
>> >
>> >
>> >
>> >
>> > On Fri, Sep 14, 2018 at 7:30 AM Graeme.Winter at Diamond.ac.uk<mailto:
>> Graeme.Winter at Diamond.ac.uk> <Graeme.Winter at diamond.ac.uk<mailto:
>> Graeme.Winter at diamond.ac.uk>> wrote:
>> > Hi Folks,
>> >
>> > Is there a reason for not having a helpful __repr__ for flex arrays i.e.
>> >
>> > Grey-Area:002-decide-when graeme$ dials.python
>> > Python 2.7.14 (default, Apr 17 2018, 15:02:10)
>> > [GCC 4.2.1 Compatible Apple LLVM 9.1.0 (clang-902.0.39.1)] on darwin
>> > Type "help", "copyright", "credits" or "license" for more information.
>> > >>> from dials.array_family import flex
>> > >>> a = flex.double([1, 2, 3])
>> > >>> print a
>> > <scitbx_array_family_flex_ext.double object at 0x1095673c0>
>> >
>> > (I have a feeling I asked this before but cannot find reference)
>> >
>> > For example
>> >
>> > >>> print a.as_numpy_array()
>> > [ 1.  2.  3.]
>> >
>> > is more useful… but annoying to type
>> >
>> > I appreciate a could be “big” but numpy seems to handle this OK
>> >
>> > even - could __repr__ be punned to as_numpy_array(),__repr__()?
>> >
>> > Currently it prints the type of the array and its location in ram,
>> which are adequately served by
>> >
>> > >>> type(a)
>> > <class 'scitbx_array_family_flex_ext.double'>
>> > >>> print id(a)
>> > 4451627968
>> >
>> > If I print an array I more often want to see the content and less often
>> the storage class and location (I humbly assert)
>> >
>> > Thoughts? I know this tends to confuse and annoy people who are new to
>> flex arrays (and veterans who are busy debugging stuff…)
>> >
>> > Many thanks Graeme
>> >
>> >
>> > --
>> > This e-mail and any attachments may contain confidential, copyright and
>> or privileged material, and are for the use of the intended addressee only.
>> If you are not the intended addressee or an authorised recipient of the
>> addressee please notify us of receipt by returning the e-mail and do not
>> use, copy, retain, distribute or disclose the information in or attached to
>> the e-mail.
>> > Any opinions expressed within this e-mail are those of the individual
>> and not necessarily of Diamond Light Source Ltd.
>> > Diamond Light Source Ltd. cannot guarantee that this e-mail or any
>> attachments are free from viruses and we cannot accept liability for any
>> damage which you may sustain as a result of software viruses which may be
>> transmitted in or with the message.
>> > Diamond Light Source Limited (company no. 4375679). Registered in
>> England and Wales with its registered office at Diamond House, Harwell
>> Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
>> >
>> > _______________________________________________
>> > cctbxbb mailing list
>> > cctbxbb at phenix-online.org<mailto:cctbxbb at phenix-online.org>
>> > http://phenix-online.org/mailman/listinfo/cctbxbb
>> >
>> > _______________________________________________
>> > cctbxbb mailing list
>> > cctbxbb at phenix-online.org
>> > http://phenix-online.org/mailman/listinfo/cctbxbb
>>
>> _______________________________________________
>> cctbxbb mailing list
>> cctbxbb at phenix-online.org
>> http://phenix-online.org/mailman/listinfo/cctbxbb
>>
>
> _______________________________________________
> cctbxbb mailing list
> cctbxbb at phenix-online.org
> http://phenix-online.org/mailman/listinfo/cctbxbb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phenix-online.org/pipermail/cctbxbb/attachments/20180914/2306b339/attachment-0001.htm>