[yt-dev] Sequence of buff_size

Matthew Turk matthewturk at gmail.com
Fri Apr 1 09:11:32 PDT 2016


Hi Yi-Hao,

The actual usage of _MPL.c shouldn't be user-facing.  So I think as
long as the things that are public APIs (such as the data returned
from a FixedResolutionBuffer object) remain the same, I am a strong +1
on this.

-Matt

On Fri, Apr 1, 2016 at 10:19 AM, Yi-Hao Chen <ychen at astro.wisc.edu> wrote:
> Hi all,
>
> Running this test script
> http://paste.yt-project.org/show/6379/
> will result in this image
> https://slack-files.com/T042F73QM-F0X0YJE3V-4a579d9431
>
> Apparently, the sequence of buff_size is switched so that
>
> set_buff_size((8,4))
>
> gives a 4 by 8 image.
>
> I have traced down the codes and found the following lines are the cause of
> the problem.
> https://bitbucket.org/yt_analysis/yt/src/d18f33211199f71e2fac4d927307b015d513a328/yt/utilities/lib/pixelization_routines.pyx?at=yt&fileviewer=file-view-default#pixelization_routines.pyx-61
>
> https://bitbucket.org/yt_analysis/yt/src/d18f33211199f71e2fac4d927307b015d513a328/yt/utilities/lib/pixelization_routines.pyx?at=yt&fileviewer=file-view-default#pixelization_routines.pyx-216
>
> If rows=nx and cols=ny, the two functions (pixelize_cartesian and
> pixelize_off_axis_cartesian) should take rows first and then cols.
>
> The same API has been around in _MPL.c since 2010 and thus changing it will
> be backward incompatible.
>
> However, to be consistent with other parts of the code (e.g. here, here,
> here, and here), in which buff_size = (nx, ny) is assumed and used, I
> propose to change the behavior of the above two functions.
>
> What do you think? Anyone has other suggestions?
>
> Thanks!
> Yi-Hao
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>



More information about the yt-dev mailing list