Github user jkbradley commented on the issue:
https://github.com/apache/spark/pull/16002
@yanboliang Sorry for missing earlier discussion. I'm OK with declaring
defeat here, though I still disagree about using exceptions. I agree that
passing an obscure error code up is not ideal.
Github user yanboliang commented on the issue:
https://github.com/apache/spark/pull/16002
I'm OK with not to change this, so I'll close this PR. Thanks for all your
comments.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as
Github user srowen commented on the issue:
https://github.com/apache/spark/pull/16002
@yanboliang what do you think of that?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user MLnick commented on the issue:
https://github.com/apache/spark/pull/16002
Doesn't seem like a final decision was made here - I'm generally in
agreement with @srowen @sethah that it doesn't really seem worth changing the
current mechanism.
@yanboliang you mention
Github user sethah commented on the issue:
https://github.com/apache/spark/pull/16002
That's a good point about IRLS. If we can find a nice, functional way to
handle this error and propagate it out to WLS, then I'm for the change. But I
think the current way is acceptable now and
Github user yanboliang commented on the issue:
https://github.com/apache/spark/pull/16002
@sethah @srowen Thanks for all your comments.
The main reason that I support error code solution is that this fallback is
not very rare, since ```IterativelyReweightedLeastSquares``` will
Github user srowen commented on the issue:
https://github.com/apache/spark/pull/16002
Yes, echoing @sethah, can I ask what the problem being solved is? I
understand being careful with what exactly is thrown from _public_ methods
because they end up forming part of the API, but this
Github user sethah commented on the issue:
https://github.com/apache/spark/pull/16002
I understand the desire to avoid exception handling, but I am not convinced
this is a better solution. Some comments:
* We are pushing an integer "error code" from lapack up about 3 levels
Github user yanboliang commented on the issue:
https://github.com/apache/spark/pull/16002
cc @sethah @jkbradley
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and
Github user AmplabJenkins commented on the issue:
https://github.com/apache/spark/pull/16002
Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/69127/
Test PASSed.
---
Github user AmplabJenkins commented on the issue:
https://github.com/apache/spark/pull/16002
Merged build finished. Test PASSed.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user SparkQA commented on the issue:
https://github.com/apache/spark/pull/16002
**[Test build #69127 has
finished](https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/69127/consoleFull)**
for PR 16002 at commit
Github user SparkQA commented on the issue:
https://github.com/apache/spark/pull/16002
**[Test build #69127 has
started](https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/69127/consoleFull)**
for PR 16002 at commit
13 matches
Mail list logo
