-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
exceptions
-based exceptions
#141
Comments
That's excellent suggestion! |
I've started addressing this here: https://github.com/DataHaskell/statistics/tree/exceptions-not-error |
I'm actually halfway through implementing it. Thing us once you touch
S.Sample you need to adjust basically everything
|
Yes, I noticed,
|
@Shimuuar would you like to join forces on this? I don't have an efficient implementation in mind for Matrix.generateSym , though |
@Shimuuar <https://github.com/Shimuuar> would you like to join forces on
this?
Sure although I won't be able to do anything till monday
… |
Hi @Shimuuar :) as discussed, if you point me to your working branch for this we can figure out how to collaborate :) |
I just pushed branch
|
@Shimuuar Re. monoid-statistics ; did you know of |
Yes. Main difference is |
Aha! that's a clever thing to have. However what do you think of setting up
speed benchmarks before looking into adding streaming capabilities?
I would like to start adding basic summary functionality to
`criterion-measurement` soon, to make it self-contained .
…On Wed, Jul 25, 2018 at 11:33 AM, Aleksey Khudyakov < ***@***.***> wrote:
Yes. Main difference is monoid-statistics exposes accumulator types and
allows to merge estimates with several data set without refolding them.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#141 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFoRqORK8RmfndEm34yTXJO7Ia-fMWfcks5uKDuFgaJpZM4S-3YM>
.
|
Why, of course! Without benchmarks all performance statements are just hopes and prayers |
Rather than Nothing/0/NaN etc. (the first option being way better than the others), it would be great to generalize code that may throw to the MonadThrow class from
exceptions
.This way, functions using
throwM (e :: Exception)
would have the signatureMonadThrow m => ... -> m ( ... )
, wherem
may becomeMaybe
, orEither e
, or evenIO
, according to the calling context.The text was updated successfully, but these errors were encountered: