NSLS-II / wishlist

an issue tracker for the big picture
1 stars 0 forks source link

Flexible delay in ct #106

Closed cmazzoli closed 8 years ago

cmazzoli commented 8 years ago

@danielballan Promemoria: please implement if possible. I believe that it would be helpful if we could discuss about the intended use before. Thanks!

tacaswell commented 8 years ago

Can you explain this a bit more?

danielballan commented 8 years ago

@tacaswell We discussed this offline. I'm on it.

Sent from Outlook Mobilehttps://aka.ms/qtex0l

On Sat, Feb 27, 2016 at 1:12 PM -0800, "Thomas A Caswell" notifications@github.com<mailto:notifications@github.com> wrote:

Can you explain this a bit more?

— Reply to this email directly or view it on GitHubhttps://github.com/NSLS-II/wishlist/issues/106#issuecomment-189726657.

cmazzoli commented 8 years ago

@tacaswell (@danielballan)

The idea is to be able to use functionalities of ct(), in particular ct(num=None) [by the way, why not num = 0??] to introducea variable delay along the series. Imagine that you have a signal decaying. You would love to get many point soon, to intercept fast variations, but also to go much further in time and detect the slow ones. Currently we need to compromise between the total number of points (if an areadet is defined = images) and total time. It might be particularly tricky/risky in case of an open series (num=None). With a variable delay, for example set in a exp increasing way, the above restrictions could be relaxed. Does it make sense? If so, the point is how to pass the list of delays in a clever way or, if you prefer, how to build up a flexible function that provides you with the necessary delay at any point (in particular for num = None..). Enjoy the sunny sunday!

danielballan commented 8 years ago

Sounds like we should let "delay" accept a (potentially infinite) iterable, which can draw points from any mathematical function you wish.

Sent from Outlook Mobilehttps://aka.ms/qtex0l

On Sun, Feb 28, 2016 at 9:32 AM -0800, "cmazzoli" notifications@github.com<mailto:notifications@github.com> wrote:

@tacaswellhttps://github.com/tacaswell (@danielballanhttps://github.com/danielballan)

The idea is to be able to use functionalities of ct(), in particular ct(num=None) [by the way, why not num = 0??] to introducea variable delay along the series. Imagine that you have a signal decaying. You would love to get many point soon, to intercept fast variations, but also to go much further in time and detect the slow ones. Currently we need to compromise between the total number of points (if an areadet is defined = images) and total time. It might be particularly tricky/risky in case of an open series (num=None). With a variable delay, for example set in a exp increasing way, the above restrictions could be relaxed. Does it make sense? If so, the point is how to pass the list of delays in a clever way or, if you prefer, how to build up a flexible function that provides you with the necessary delay at any point (in particular for num = None..). Enjoy the sunny sunday!

— Reply to this email directly or view it on GitHubhttps://github.com/NSLS-II/wishlist/issues/106#issuecomment-189912068.

tacaswell commented 8 years ago

Sounds reasonable. I am not convinced that shoe horning that complexity into ct is the best path on this. There is something to be said for maintaining exactly the spec api on the functions copied from spec.

None is used because it is the pythonic way to say 'there is no value here'. ct(0) could reasonable be expected to take no images, not to take images forever.

On Sun, Feb 28, 2016, 12:32 cmazzoli notifications@github.com wrote:

@tacaswell https://github.com/tacaswell (@danielballan https://github.com/danielballan)

The idea is to be able to use functionalities of ct(), in particular ct(num=None) [by the way, why not num = 0??] to introducea variable delay along the series. Imagine that you have a signal decaying. You would love to get many point soon, to intercept fast variations, but also to go much further in time and detect the slow ones. Currently we need to compromise between the total number of points (if an areadet is defined = images) and total time. It might be particularly tricky/risky in case of an open series (num=None). With a variable delay, for example set in a exp increasing way, the above restrictions could be relaxed. Does it make sense? If so, the point is how to pass the list of delays in a clever way or, if you prefer, how to build up a flexible function that provides you with the necessary delay at any point (in particular for num = None..). Enjoy the sunny sunday!

— Reply to this email directly or view it on GitHub https://github.com/NSLS-II/wishlist/issues/106#issuecomment-189912068.

cmazzoli commented 8 years ago

A part for the fact that pythonically speaking ct(0) should take 1 image (tié! ;) ), when do you need to count for no point?

The problem of complexity into ct was exactly my concern. Probably most of the time people would need:

General question, would it be possible/convenient to pass a function that is used to calculate the delay point by point? This would lift the complexity of ct into a slave function dedicated to the delay generation, totally under user control (and responsibility..).

Thanks a lot! On Feb 28, 2016 2:40 PM, "Thomas A Caswell" notifications@github.com wrote:

Sounds reasonable. I am not convinced that shoe horning that complexity into ct is the best path on this. There is something to be said for maintaining exactly the spec api on the functions copied from spec.

None is used because it is the pythonic way to say 'there is no value here'. ct(0) could reasonable be expected to take no images, not to take images forever.

On Sun, Feb 28, 2016, 12:32 cmazzoli notifications@github.com wrote:

@tacaswell https://github.com/tacaswell (@danielballan https://github.com/danielballan)

The idea is to be able to use functionalities of ct(), in particular ct(num=None) [by the way, why not num = 0??] to introducea variable delay along the series. Imagine that you have a signal decaying. You would love to get many point soon, to intercept fast variations, but also to go much further in time and detect the slow ones. Currently we need to compromise between the total number of points (if an areadet is defined = images) and total time. It might be particularly tricky/risky in case of an open series (num=None). With a variable delay, for example set in a exp increasing way, the above restrictions could be relaxed. Does it make sense? If so, the point is how to pass the list of delays in a clever way or, if you prefer, how to build up a flexible function that provides you with the necessary delay at any point (in particular for num = None..). Enjoy the sunny sunday!

— Reply to this email directly or view it on GitHub https://github.com/NSLS-II/wishlist/issues/106#issuecomment-189912068.

— Reply to this email directly or view it on GitHub https://github.com/NSLS-II/wishlist/issues/106#issuecomment-189931403.

ghost commented 8 years ago

@danielballan added this to bluesky