Re: [Discuss] Next MXNet release
Thanks Patrick. Updated roadmap and next release content. Patrick - suggest to send a reminder to review the design doc and collect feedback. Are there still known issues or gaps before we declare MKL-DNN integration as GA? Regards, Steffen On Sat, Sep 29, 2018 at 1:31 AM Zhao, Patric wrote: > Thanks, Steffen. > > Regarding the next release note, two items from our side: > > 1. (-remove) MKL-DNN integration is done. I think we can remove this item. > 2. (+add) MKL-DNN based graph optimization and quantization by subgraph > Design doc: > https://cwiki.apache.org/confluence/display/MXNET/MXNet+Graph+Optimization+and+Quantization+based+on+subgraph+and+MKL-DNN > Lead Contributor: Patric Zhao, https://github.com/pengzhao-intel/ > > Regarding the Roadmap > (+add) Q1 2019: MKL-DNN RNN API supports > > BR, > > Thanks, > > --Patric > > > > -Original Message- > > From: kellen sunderland [mailto:kellen.sunderl...@gmail.com] > > Sent: Saturday, September 29, 2018 11:31 AM > > To: dev@mxnet.incubator.apache.org > > Subject: Re: [Discuss] Next MXNet release > > > > Sorry I meant to say next 'Regarding the *minor* release'. > > > > On Sat, Sep 29, 2018 at 5:27 AM kellen sunderland < > > kellen.sunderl...@gmail.com> wrote: > > > > > Thanks for transparently setting a rough timeline Steffen. I think > > > this will go a long way in helping the community plan their work, even > > > if the details change somewhat on the road to the release. > > > > > > Regarding the major release: I would propose we unify TensorRT with > > > the subgraph operator work. > > > > > > Regarding the patch release: There were a few minor stack/buffer > > > overflows exposed by ASAN that have been addressed. It's probably a > > > good idea to include them in a patch release, as they at best result > > > in non-deterministic behaviour. > > > > > > -Kellen > > > > > > > > > On Sat, Sep 29, 2018 at 1:39 AM Steffen Rochel > > > > > > wrote: > > > > > >> I updated > > >> > > >> https://cwiki.apache.org/confluence/display/MXNET/Project+Proposals+f > > >> or+next+MXNet+Release > > >> , > > >> removed the completed items from 1.3 release and would like to kick > > >> off discussion about the next release. Please suggest what you would > > >> like to see included in the next release together with link to design > > >> proposal (appropriately for the size and complexity of the proposal) > > >> or suggest changes. > > >> I suggest to target the next release for December 2018 to frame the > > >> discussion. > > >> Lets include review of > > >> https://cwiki.apache.org/confluence/display/MXNET/MXNet+Roadmap - > > >> time to update and discuss changes. > > >> > > >> From the 1.3 release we had discussion regarding > > >> https://github.com/apache/incubator-mxnet/issues/11849 and resolution > > >> in > > >> https://github.com/apache/incubator-mxnet/pull/12412 . > > >> Are you aware of critical issues and feedback from user which we > > >> should consider for a potential 1.3.1 patch release. Should we > > >> include PR 12412 in a potential patch release? > > >> > > >> Regards, > > >> Steffen > > >> > > > >
Re: Feedback request for new Java API
Qing, thanks for a great summary. The discussion(offline and much of it on Slack) was whether to add new APIs for Java that removed *Option* from parameters of the existing Scala APIs and add builders where necessary or refactor Scala APIs to achieve this. My answer and response was based on that ie., for a change like this we do not have different code paths and generate 200+ APIs, we could make existing Scala APIs work for this. My thought is that we cannot just stop with NDArrays and should probably do that for all APIs so users have a consistent experience. In this thread Yizhi proposed to add Builders(for arguments) to all APIs, Now if we were to do that shouldn't we do it for all APIs or at the least for Symbol so users have a consistent experience? As a reminder Symbol has the same set of APIs as NDArrays. Bob/Marco, i'll send how the APIs look for the 3 different approaches. currently working on something else, Qing if you already have please paste the generated APIs in a gist and link here. On Sun, Sep 30, 2018 at 6:31 PM Qing Lan wrote: > Here I have done a summary about the opinion most people holds: > > Naveen & Yizhi thoughts in a technical way: > Agreement: -1 for total Java conversion (build all wrappers from > Scala to Java) > Yizhi: A hybrid solution may works the best (Build only necessary > Java class for Java users and make best use on Scala Classes) > Naveen: Stop introducing much of the new things for Java users. > Think of changing the existing APIs to makes them compatible. > Yizhi: +1 on builder solution & Naveen +1 on building builders for > necessary operators > Naveen -1 on 2) Andrew proposed. > > There are some arguments in this thread that happened in our MXNet-Scala > Slack channel before on the topic of changing the existing Scala API to > make them more Java friendly (null problem with removal of optional). > Please ignore these portion and feel free to discuss them in the Slack > channel. > > Java users experience is the thing we care of: > Marco (thing big on this, someday we need a wider support for Java) > Chris (Don't makes Java user to learn Scala and let them say > goodbye) > Bob (please help us understand the core difference of the proposed > design) > Qing (we should think of how to make users use them happily > instead of taking too serious trade off on the design) > > Carin: We can think of generating Java api in Java > > On Andrew's approach 2) > Carin (+1) > Qing (+0.5) > Yizhi (+1) > Denis(+1) > Naveen (-1) > > The optimal goal for any of the design is the experience that Java user > holds: > I know what to use: All of the functions that we use are available > in Java (not something we have to learn Scala) > Easy to use: User write minimum code to create an > easy-to-understand functions > Performance: New Java API should have similar performance across > different language bindings > > Lastly I would like to +1 on Yizhi's recommendation: Makes Java API > hybrid: Implement only the classes that Java users may feel sick and > extends the rest of them to better support Java. It's a good trade of on > Build all wrappers in Java/Extends all Java functionalities on Scala. > > Thanks, > Qing > > > > > > > On 9/30/18, 10:05 AM, "Bob Paulin" wrote: > > +1 to this suggestion. Voting should be seen as a last resort to > resolve differences in the community. Perhaps a small POC of both > approaches (or maybe others as well) might help the community discuss > options in a more concrete way. Sometimes is very difficult to "see" > the differences between approaches in an email thread compared to 2 > branches of code. > > - Bob > > > On 9/30/2018 6:17 AM, Marco de Abreu wrote: > > Maybe we can take a step back and rather look at how we would like > our > > users and mxnet developers to use the API. Imagine like a mock or > pseudo > > code where we write a few examples with the "perfect" Java API. > After that, > > we think about the technical implementation details and how it can > be done > > (I know that we already had a lot of technical discussion, it's just > a > > method to get a second perspective). > > > > Our current discussion is around the technical limitations and > possible > > overhead a Java API might cause, but I think it's most important > that a > > user is actually able to use it. I think we have all been at the > point > > where we tried to use a package and the API was so strange that we > just > > picked an alternative. > > > > We should think a bit long term here. Java is a HUGE market with a > big user > > base, especially in the Enterprise segment. So, theoretically > speaking, > > even if we duplicate everything and decouple it from scala entirely, > we > > might have a good chance that - given a good
Re: Feedback request for new Java API
Here I have done a summary about the opinion most people holds: Naveen & Yizhi thoughts in a technical way: Agreement: -1 for total Java conversion (build all wrappers from Scala to Java) Yizhi: A hybrid solution may works the best (Build only necessary Java class for Java users and make best use on Scala Classes) Naveen: Stop introducing much of the new things for Java users. Think of changing the existing APIs to makes them compatible. Yizhi: +1 on builder solution & Naveen +1 on building builders for necessary operators Naveen -1 on 2) Andrew proposed. There are some arguments in this thread that happened in our MXNet-Scala Slack channel before on the topic of changing the existing Scala API to make them more Java friendly (null problem with removal of optional). Please ignore these portion and feel free to discuss them in the Slack channel. Java users experience is the thing we care of: Marco (thing big on this, someday we need a wider support for Java) Chris (Don't makes Java user to learn Scala and let them say goodbye) Bob (please help us understand the core difference of the proposed design) Qing (we should think of how to make users use them happily instead of taking too serious trade off on the design) Carin: We can think of generating Java api in Java On Andrew's approach 2) Carin (+1) Qing (+0.5) Yizhi (+1) Denis(+1) Naveen (-1) The optimal goal for any of the design is the experience that Java user holds: I know what to use: All of the functions that we use are available in Java (not something we have to learn Scala) Easy to use: User write minimum code to create an easy-to-understand functions Performance: New Java API should have similar performance across different language bindings Lastly I would like to +1 on Yizhi's recommendation: Makes Java API hybrid: Implement only the classes that Java users may feel sick and extends the rest of them to better support Java. It's a good trade of on Build all wrappers in Java/Extends all Java functionalities on Scala. Thanks, Qing On 9/30/18, 10:05 AM, "Bob Paulin" wrote: +1 to this suggestion. Voting should be seen as a last resort to resolve differences in the community. Perhaps a small POC of both approaches (or maybe others as well) might help the community discuss options in a more concrete way. Sometimes is very difficult to "see" the differences between approaches in an email thread compared to 2 branches of code. - Bob On 9/30/2018 6:17 AM, Marco de Abreu wrote: > Maybe we can take a step back and rather look at how we would like our > users and mxnet developers to use the API. Imagine like a mock or pseudo > code where we write a few examples with the "perfect" Java API. After that, > we think about the technical implementation details and how it can be done > (I know that we already had a lot of technical discussion, it's just a > method to get a second perspective). > > Our current discussion is around the technical limitations and possible > overhead a Java API might cause, but I think it's most important that a > user is actually able to use it. I think we have all been at the point > where we tried to use a package and the API was so strange that we just > picked an alternative. > > We should think a bit long term here. Java is a HUGE market with a big user > base, especially in the Enterprise segment. So, theoretically speaking, > even if we duplicate everything and decouple it from scala entirely, we > might have a good chance that - given a good design - other people will > step up and help maintaining and extending the API. If the process to > change anything in that API is super cryptic, we might block future efforts > because the entry barrier is too high. > > I think our python API is the best example. We are finally at a state where > it's super easy to extend, the usability is good (especially around gluon) > and it fits into the languages' idioms. Let's try to take that experience > and apply it to the Java API. This might be more work initially and create > redundancy, but we have seen that a good API (external as well as internal) > design increases contributions and attracts more users. > > I won't take any side here because I'm unfamiliar with the scala side of > mxnet, just wanted to add an external viewpoint. > > -Marco > > YiZhi Liu schrieb am So., 30. Sep. 2018, 05:15: > >> Yes agreement and disagreement stay at technical level only:) >> >> Back to the problem, they are unnecessary but good in terms of, >> 1. Still not good for java users to write 3 nulls in a function call with 5 >> or 4 args >> 2. Every
Re: [Discuss] Next MXNet release
Kellen - please send a list of PR to consider for patch release. Steffen On Fri, Sep 28, 2018 at 8:27 PM kellen sunderland < kellen.sunderl...@gmail.com> wrote: > Thanks for transparently setting a rough timeline Steffen. I think this > will go a long way in helping the community plan their work, even if the > details change somewhat on the road to the release. > > Regarding the major release: I would propose we unify TensorRT with the > subgraph operator work. > > Regarding the patch release: There were a few minor stack/buffer overflows > exposed by ASAN that have been addressed. It's probably a good idea to > include them in a patch release, as they at best result in > non-deterministic behaviour. > > -Kellen > > > On Sat, Sep 29, 2018 at 1:39 AM Steffen Rochel > wrote: > > > I updated > > > > > https://cwiki.apache.org/confluence/display/MXNET/Project+Proposals+for+next+MXNet+Release > > , > > removed the completed items from 1.3 release and would like to kick off > > discussion about the next release. Please suggest what you would like to > > see included in the next release together with link to design proposal > > (appropriately for the size and complexity of the proposal) or suggest > > changes. > > I suggest to target the next release for December 2018 to frame the > > discussion. > > Lets include review of > > https://cwiki.apache.org/confluence/display/MXNET/MXNet+Roadmap - time > to > > update and discuss changes. > > > > From the 1.3 release we had discussion regarding > > https://github.com/apache/incubator-mxnet/issues/11849 and resolution in > > https://github.com/apache/incubator-mxnet/pull/12412 . > > Are you aware of critical issues and feedback from user which we should > > consider for a potential 1.3.1 patch release. Should we include PR 12412 > in > > a potential patch release? > > > > Regards, > > Steffen > > >
Podling Report Reminder - October 2018
Dear podling, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for Wed, 17 October 2018, 10:30 am PDT. The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted 2 weeks before the board meeting, to allow sufficient time for review and submission (Wed, October 03). Please submit your report with sufficient time to allow the Incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is 2 weeks prior to the board meeting. Candidate names should not be made public before people are actually elected, so please do not include the names of potential committers or PPMC members in your report. Thanks, The Apache Incubator PMC Submitting your Report -- Your report should contain the following: * Your project name * A brief description of your project, which assumes no knowledge of the project or necessarily of its field * A list of the three most important issues to address in the move towards graduation. * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * How has the community developed since the last report * How has the project developed since the last report. * How does the podling rate their own maturity. This should be appended to the Incubator Wiki page at: https://wiki.apache.org/incubator/October2018 Note: This is manually populated. You may need to wait a little before this page is created from a template. Mentors --- Mentors should review reports for their project(s) and sign them off on the Incubator wiki page. Signing off reports shows that you are following the project - projects that are not signed may raise alarms for the Incubator PMC. Incubator PMC
Re: Feedback request for new Java API
+1 to this suggestion. Voting should be seen as a last resort to resolve differences in the community. Perhaps a small POC of both approaches (or maybe others as well) might help the community discuss options in a more concrete way. Sometimes is very difficult to "see" the differences between approaches in an email thread compared to 2 branches of code. - Bob On 9/30/2018 6:17 AM, Marco de Abreu wrote: > Maybe we can take a step back and rather look at how we would like our > users and mxnet developers to use the API. Imagine like a mock or pseudo > code where we write a few examples with the "perfect" Java API. After that, > we think about the technical implementation details and how it can be done > (I know that we already had a lot of technical discussion, it's just a > method to get a second perspective). > > Our current discussion is around the technical limitations and possible > overhead a Java API might cause, but I think it's most important that a > user is actually able to use it. I think we have all been at the point > where we tried to use a package and the API was so strange that we just > picked an alternative. > > We should think a bit long term here. Java is a HUGE market with a big user > base, especially in the Enterprise segment. So, theoretically speaking, > even if we duplicate everything and decouple it from scala entirely, we > might have a good chance that - given a good design - other people will > step up and help maintaining and extending the API. If the process to > change anything in that API is super cryptic, we might block future efforts > because the entry barrier is too high. > > I think our python API is the best example. We are finally at a state where > it's super easy to extend, the usability is good (especially around gluon) > and it fits into the languages' idioms. Let's try to take that experience > and apply it to the Java API. This might be more work initially and create > redundancy, but we have seen that a good API (external as well as internal) > design increases contributions and attracts more users. > > I won't take any side here because I'm unfamiliar with the scala side of > mxnet, just wanted to add an external viewpoint. > > -Marco > > YiZhi Liu schrieb am So., 30. Sep. 2018, 05:15: > >> Yes agreement and disagreement stay at technical level only:) >> >> Back to the problem, they are unnecessary but good in terms of, >> 1. Still not good for java users to write 3 nulls in a function call with 5 >> or 4 args >> 2. Every function call with a “tail” null for arg “out”. I would say, makes >> it seems not a serious api design to our users >> 3. Users have uniformed experience, nothing surprising. >> >> Given the reasons I listed before, I don’t see things bad for this. >> >> I agree we can vote. I suggest to have two votes, one for builder, one for >> separating java and scala objects. >> >> On Sat, Sep 29, 2018 at 7:43 PM Naveen Swamy wrote: >> >>> Ah! we agree on something :) lets get more opinions, I am happy to go >> with >>> it. >>> >>> On Sat, Sep 29, 2018 at 10:40 PM YiZhi Liu wrote: >>> Also sometimes people may not be at the same page when talking about >>> option #2. What I insist is the builder classes for each operator. Otherwise I actually more support Naveen’s approach - not to totally separate java >>> and scala objects. On Sat, Sep 29, 2018 at 7:35 PM YiZhi Liu wrote: > No you haven't answered my question "Since you agree to have 30+ > operators have Builder, what prevents from > having all of them have Builder?" > On Sat, Sep 29, 2018 at 7:30 PM Naveen Swamy >>> wrote: >> I think we have had enough of an debate between the two of us and I have >> already listed my reasons, I will stop here and see what others say > given >> my reasoning. >> >> -1 to #2) >> >> Also, by lecture I meant to say "I don't want to list all the >>> problems >> with unnecessary complications and talk about how to design >> software" >> On Sat, Sep 29, 2018 at 10:15 PM YiZhi Liu wrote: >>> And if we find incorrect declaration, we fix it, not simply >>> assuming >>> many of them also has problem and we cannot rely on them - >>> otherwise >>> the type-safe APIs in Scala also does not make sense. >>> On Sat, Sep 29, 2018 at 7:10 PM YiZhi Liu wrote: It also makes sense to me if we have it under namespace >> NDArray, not creating new JavaNDArray. But again, uniform experience is important. What I responded is your comment "keep scala macros minimum", I don't think "scala macro" equals "cryptic code". Even though it does, what we need to do is to find an alternative way to do code >>> generation, > not making code generation minimum. Since you agree to have 30+ operators have Builder, what >> prevents > from having all of them have
Re: [DISCUSS] Use modernized C++11 range loops uniformly throughout the project
unless you don’t think that’s reasonable...
On Sun, Sep 30, 2018 at 7:59 AM Chris Olivier wrote:
> If you get three +1’s from the top 6 contributors of C++ code (by volume),
> I’ll switch to -0, since the ones committing the most C++ code will be the
> most impacted and probably it should be their decision, imho.
>
> On Sun, Sep 30, 2018 at 12:28 AM kellen sunderland <
> kellen.sunderl...@gmail.com> wrote:
>
>> About 60 but they're all addressed In the ref PR.
>>
>> On Sun, Sep 30, 2018, 6:12 AM Chris Olivier
>> wrote:
>>
>> > How many errors exist in the code base right now if it were to be
>> enabled?
>> >
>> > On Sat, Sep 29, 2018 at 7:03 PM Naveen Swamy
>> wrote:
>> >
>> > > Thanks Kellen & Anton, for your detailed explanation and links to
>> > > advantages, appreciate it.
>> > > changing my vote to *-0*, I suggest to show as warnings.
>> > >
>> > > On Sat, Sep 29, 2018 at 8:06 PM Anton Chernov
>> > wrote:
>> > >
>> > > > And if you want a more authoritative opinion on that check out what
>> the
>> > > C++
>> > > > core guidelines are saying [1]:
>> > > >
>> > > > > ES.71: Prefer a range-for-statement to a for-statement when there
>> is
>> > a
>> > > > choice
>> > > > > Reason
>> > > > > Readability. Error prevention. Efficiency.
>> > > >
>> > > > Best regards
>> > > > Anton
>> > > >
>> > > > [1]
>> > > >
>> > > >
>> > >
>> >
>> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Res-for-range
>> > > >
>> > > >
>> > > > сб, 29 сент. 2018 г. в 16:13, Anton Chernov :
>> > > >
>> > > > > +1
>> > > > >
>> > > > > Maybe it's not necessary to enforce usage of range-based for, but
>> I
>> > > would
>> > > > > highly encourage to to it due to already named advantages. If code
>> > > would
>> > > > be
>> > > > > introduced using the old-style there could be a comment suggesting
>> > the
>> > > > new
>> > > > > way. But why do the manual work and not leave that to the
>> automated
>> > > tool?
>> > > > >
>> > > > > And since it's already automated - wouldn't it be better to keep a
>> > > > unified
>> > > > > modern style?
>> > > > >
>> > > > > Just to make this a trend - C++ evolves quickly and this will not
>> be
>> > > only
>> > > > > upgrade that would needed to be made. And the easier such upgrades
>> > get
>> > > > > accepted the easier in general is to upgrade the codebase.
>> > > > >
>> > > > > Soon the standard will get ranges and concepts and this will
>> change
>> > the
>> > > > > way C++ applications get written significantly. It is a good
>> habit to
>> > > be
>> > > > > open for changes and keep up with the trends. By using the new
>> > > > > possibilities the language can offer you prepare yourself for
>> further
>> > > > > changes and are more likely to accept them, evolving your
>> programming
>> > > > style.
>> > > > >
>> > > > > Take a look at a new examples on modern usages (taken from [1]):
>> > > > >
>> > > > > // since C++17
>> > > > > for (auto&& [first,second] : mymap) {
>> > > > > // use first and second
>> > > > > }
>> > > > >
>> > > > > // since C++20
>> > > > > for (auto& x : foo().items()) { /* .. */ } // undefined behavior
>> if
>> > > foo()
>> > > > > returns by value
>> > > > > for (T thing = foo(); auto& x : thing.items()) { /* ... */ } // OK
>> > > > >
>> > > > > // since C++11
>> > > > > struct cow_string { /* ... */ };
>> > > > > // a copy-on-write string cow_string str = /* ... */;
>> > > > > // for(auto x : str) { /* ... */ } // may cause deep copy
>> > > > > for(auto x : std::as_const(str)) { /* ... */ }
>> > > > >
>> > > > > Regarding performance: it's really easy to prove that generated
>> > > assembly
>> > > > > is not changing at all. There is a really handy tool for that [2].
>> > You
>> > > > can
>> > > > > check online the assembly for different language constructs and
>> > > different
>> > > > > compilers.
>> > > > >
>> > > > > Best regards,
>> > > > > Anton
>> > > > >
>> > > > > [1] https://en.cppreference.com/w/cpp/language/range-for
>> > > > > [2] https://gcc.godbolt.org
>> > > > >
>> > > > > сб, 29 сент. 2018 г. в 13:15, kellen sunderland <
>> > > > > kellen.sunderl...@gmail.com>:
>> > > > >
>> > > > >> It's more readable because it's concise and it's consistent for
>> many
>> > > > types
>> > > > >> you're looping over (i.e. primitive arrays, stl iterators, etc
>> all
>> > > work
>> > > > >> the
>> > > > >> same way). It's also useful because it's consistent with other
>> > > > >> programming
>> > > > >> languages, making C++ codebases much easier to read for novice
>> and
>> > > > >> intermediate developers. IMO it also leads to better naming in
>> loop
>> > > > >> bodies
>> > > > >> as the concise style means you're less likely to have important 1
>> > > letter
>> > > > >> variable names describing loop elements (e.g. no int i =0 or it
>> > ...).
>> > > > >> More
>> > > > >> motivation can be found in the cpp standards proposals for C++11
>> > > > >>
>> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1868.html
>>
Re: [DISCUSS] Use modernized C++11 range loops uniformly throughout the project
If you get three +1’s from the top 6 contributors of C++ code (by volume),
I’ll switch to -0, since the ones committing the most C++ code will be the
most impacted and probably it should be their decision, imho.
On Sun, Sep 30, 2018 at 12:28 AM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:
> About 60 but they're all addressed In the ref PR.
>
> On Sun, Sep 30, 2018, 6:12 AM Chris Olivier wrote:
>
> > How many errors exist in the code base right now if it were to be
> enabled?
> >
> > On Sat, Sep 29, 2018 at 7:03 PM Naveen Swamy wrote:
> >
> > > Thanks Kellen & Anton, for your detailed explanation and links to
> > > advantages, appreciate it.
> > > changing my vote to *-0*, I suggest to show as warnings.
> > >
> > > On Sat, Sep 29, 2018 at 8:06 PM Anton Chernov
> > wrote:
> > >
> > > > And if you want a more authoritative opinion on that check out what
> the
> > > C++
> > > > core guidelines are saying [1]:
> > > >
> > > > > ES.71: Prefer a range-for-statement to a for-statement when there
> is
> > a
> > > > choice
> > > > > Reason
> > > > > Readability. Error prevention. Efficiency.
> > > >
> > > > Best regards
> > > > Anton
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Res-for-range
> > > >
> > > >
> > > > сб, 29 сент. 2018 г. в 16:13, Anton Chernov :
> > > >
> > > > > +1
> > > > >
> > > > > Maybe it's not necessary to enforce usage of range-based for, but I
> > > would
> > > > > highly encourage to to it due to already named advantages. If code
> > > would
> > > > be
> > > > > introduced using the old-style there could be a comment suggesting
> > the
> > > > new
> > > > > way. But why do the manual work and not leave that to the automated
> > > tool?
> > > > >
> > > > > And since it's already automated - wouldn't it be better to keep a
> > > > unified
> > > > > modern style?
> > > > >
> > > > > Just to make this a trend - C++ evolves quickly and this will not
> be
> > > only
> > > > > upgrade that would needed to be made. And the easier such upgrades
> > get
> > > > > accepted the easier in general is to upgrade the codebase.
> > > > >
> > > > > Soon the standard will get ranges and concepts and this will change
> > the
> > > > > way C++ applications get written significantly. It is a good habit
> to
> > > be
> > > > > open for changes and keep up with the trends. By using the new
> > > > > possibilities the language can offer you prepare yourself for
> further
> > > > > changes and are more likely to accept them, evolving your
> programming
> > > > style.
> > > > >
> > > > > Take a look at a new examples on modern usages (taken from [1]):
> > > > >
> > > > > // since C++17
> > > > > for (auto&& [first,second] : mymap) {
> > > > > // use first and second
> > > > > }
> > > > >
> > > > > // since C++20
> > > > > for (auto& x : foo().items()) { /* .. */ } // undefined behavior if
> > > foo()
> > > > > returns by value
> > > > > for (T thing = foo(); auto& x : thing.items()) { /* ... */ } // OK
> > > > >
> > > > > // since C++11
> > > > > struct cow_string { /* ... */ };
> > > > > // a copy-on-write string cow_string str = /* ... */;
> > > > > // for(auto x : str) { /* ... */ } // may cause deep copy
> > > > > for(auto x : std::as_const(str)) { /* ... */ }
> > > > >
> > > > > Regarding performance: it's really easy to prove that generated
> > > assembly
> > > > > is not changing at all. There is a really handy tool for that [2].
> > You
> > > > can
> > > > > check online the assembly for different language constructs and
> > > different
> > > > > compilers.
> > > > >
> > > > > Best regards,
> > > > > Anton
> > > > >
> > > > > [1] https://en.cppreference.com/w/cpp/language/range-for
> > > > > [2] https://gcc.godbolt.org
> > > > >
> > > > > сб, 29 сент. 2018 г. в 13:15, kellen sunderland <
> > > > > kellen.sunderl...@gmail.com>:
> > > > >
> > > > >> It's more readable because it's concise and it's consistent for
> many
> > > > types
> > > > >> you're looping over (i.e. primitive arrays, stl iterators, etc all
> > > work
> > > > >> the
> > > > >> same way). It's also useful because it's consistent with other
> > > > >> programming
> > > > >> languages, making C++ codebases much easier to read for novice and
> > > > >> intermediate developers. IMO it also leads to better naming in
> loop
> > > > >> bodies
> > > > >> as the concise style means you're less likely to have important 1
> > > letter
> > > > >> variable names describing loop elements (e.g. no int i =0 or it
> > ...).
> > > > >> More
> > > > >> motivation can be found in the cpp standards proposals for C++11
> > > > >>
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1868.html
> > > and
> > > > >> http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm.
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Sat, Sep 29, 2018 at 6:38 PM Naveen Swamy
> > > > wrote:
> > > > >>
> > > > >> > Kellen,
> > > > >> >
> > > > >> > Could you please explain
Re: Feedback request for new Java API
Maybe we can take a step back and rather look at how we would like our users and mxnet developers to use the API. Imagine like a mock or pseudo code where we write a few examples with the "perfect" Java API. After that, we think about the technical implementation details and how it can be done (I know that we already had a lot of technical discussion, it's just a method to get a second perspective). Our current discussion is around the technical limitations and possible overhead a Java API might cause, but I think it's most important that a user is actually able to use it. I think we have all been at the point where we tried to use a package and the API was so strange that we just picked an alternative. We should think a bit long term here. Java is a HUGE market with a big user base, especially in the Enterprise segment. So, theoretically speaking, even if we duplicate everything and decouple it from scala entirely, we might have a good chance that - given a good design - other people will step up and help maintaining and extending the API. If the process to change anything in that API is super cryptic, we might block future efforts because the entry barrier is too high. I think our python API is the best example. We are finally at a state where it's super easy to extend, the usability is good (especially around gluon) and it fits into the languages' idioms. Let's try to take that experience and apply it to the Java API. This might be more work initially and create redundancy, but we have seen that a good API (external as well as internal) design increases contributions and attracts more users. I won't take any side here because I'm unfamiliar with the scala side of mxnet, just wanted to add an external viewpoint. -Marco YiZhi Liu schrieb am So., 30. Sep. 2018, 05:15: > Yes agreement and disagreement stay at technical level only:) > > Back to the problem, they are unnecessary but good in terms of, > 1. Still not good for java users to write 3 nulls in a function call with 5 > or 4 args > 2. Every function call with a “tail” null for arg “out”. I would say, makes > it seems not a serious api design to our users > 3. Users have uniformed experience, nothing surprising. > > Given the reasons I listed before, I don’t see things bad for this. > > I agree we can vote. I suggest to have two votes, one for builder, one for > separating java and scala objects. > > On Sat, Sep 29, 2018 at 7:43 PM Naveen Swamy wrote: > > > Ah! we agree on something :) lets get more opinions, I am happy to go > with > > it. > > > > On Sat, Sep 29, 2018 at 10:40 PM YiZhi Liu wrote: > > > > > Also sometimes people may not be at the same page when talking about > > option > > > #2. What I insist is the builder classes for each operator. Otherwise I > > > actually more support Naveen’s approach - not to totally separate java > > and > > > scala objects. > > > > > > On Sat, Sep 29, 2018 at 7:35 PM YiZhi Liu wrote: > > > > > > > No you haven't answered my question "Since you agree to have 30+ > > > > operators have Builder, what prevents from > > > > having all of them have Builder?" > > > > On Sat, Sep 29, 2018 at 7:30 PM Naveen Swamy > > wrote: > > > > > > > > > > I think we have had enough of an debate between the two of us and I > > > have > > > > > already listed my reasons, I will stop here and see what others say > > > > given > > > > > my reasoning. > > > > > > > > > > -1 to #2) > > > > > > > > > > Also, by lecture I meant to say "I don't want to list all the > > problems > > > > > with unnecessary complications and talk about how to design > software" > > > > > > > > > > On Sat, Sep 29, 2018 at 10:15 PM YiZhi Liu > > > wrote: > > > > > > > > > > > And if we find incorrect declaration, we fix it, not simply > > assuming > > > > > > many of them also has problem and we cannot rely on them - > > otherwise > > > > > > the type-safe APIs in Scala also does not make sense. > > > > > > On Sat, Sep 29, 2018 at 7:10 PM YiZhi Liu > > > wrote: > > > > > > > > > > > > > > It also makes sense to me if we have it under namespace > NDArray, > > > not > > > > > > > creating new JavaNDArray. But again, uniform experience is > > > important. > > > > > > > > > > > > > > What I responded is your comment "keep scala macros minimum", I > > > don't > > > > > > > think "scala macro" equals "cryptic code". Even though it does, > > > what > > > > > > > we need to do is to find an alternative way to do code > > generation, > > > > not > > > > > > > making code generation minimum. > > > > > > > > > > > > > > Since you agree to have 30+ operators have Builder, what > prevents > > > > from > > > > > > > having all of them have Builder? > > > > > > > - They're auto-generated, the auto-generation "cryptic" code is > > > > anyway > > > > > > > there. And "two different paths of code" (though I don't > totally > > > > > > > agree) is anyway there. > > > > > > > - What else? 200+ classes is a very tiny increasing in file > size > > > > > > > (~3MB)
Re: [DISCUSS] Use modernized C++11 range loops uniformly throughout the project
About 60 but they're all addressed In the ref PR.
On Sun, Sep 30, 2018, 6:12 AM Chris Olivier wrote:
> How many errors exist in the code base right now if it were to be enabled?
>
> On Sat, Sep 29, 2018 at 7:03 PM Naveen Swamy wrote:
>
> > Thanks Kellen & Anton, for your detailed explanation and links to
> > advantages, appreciate it.
> > changing my vote to *-0*, I suggest to show as warnings.
> >
> > On Sat, Sep 29, 2018 at 8:06 PM Anton Chernov
> wrote:
> >
> > > And if you want a more authoritative opinion on that check out what the
> > C++
> > > core guidelines are saying [1]:
> > >
> > > > ES.71: Prefer a range-for-statement to a for-statement when there is
> a
> > > choice
> > > > Reason
> > > > Readability. Error prevention. Efficiency.
> > >
> > > Best regards
> > > Anton
> > >
> > > [1]
> > >
> > >
> >
> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Res-for-range
> > >
> > >
> > > сб, 29 сент. 2018 г. в 16:13, Anton Chernov :
> > >
> > > > +1
> > > >
> > > > Maybe it's not necessary to enforce usage of range-based for, but I
> > would
> > > > highly encourage to to it due to already named advantages. If code
> > would
> > > be
> > > > introduced using the old-style there could be a comment suggesting
> the
> > > new
> > > > way. But why do the manual work and not leave that to the automated
> > tool?
> > > >
> > > > And since it's already automated - wouldn't it be better to keep a
> > > unified
> > > > modern style?
> > > >
> > > > Just to make this a trend - C++ evolves quickly and this will not be
> > only
> > > > upgrade that would needed to be made. And the easier such upgrades
> get
> > > > accepted the easier in general is to upgrade the codebase.
> > > >
> > > > Soon the standard will get ranges and concepts and this will change
> the
> > > > way C++ applications get written significantly. It is a good habit to
> > be
> > > > open for changes and keep up with the trends. By using the new
> > > > possibilities the language can offer you prepare yourself for further
> > > > changes and are more likely to accept them, evolving your programming
> > > style.
> > > >
> > > > Take a look at a new examples on modern usages (taken from [1]):
> > > >
> > > > // since C++17
> > > > for (auto&& [first,second] : mymap) {
> > > > // use first and second
> > > > }
> > > >
> > > > // since C++20
> > > > for (auto& x : foo().items()) { /* .. */ } // undefined behavior if
> > foo()
> > > > returns by value
> > > > for (T thing = foo(); auto& x : thing.items()) { /* ... */ } // OK
> > > >
> > > > // since C++11
> > > > struct cow_string { /* ... */ };
> > > > // a copy-on-write string cow_string str = /* ... */;
> > > > // for(auto x : str) { /* ... */ } // may cause deep copy
> > > > for(auto x : std::as_const(str)) { /* ... */ }
> > > >
> > > > Regarding performance: it's really easy to prove that generated
> > assembly
> > > > is not changing at all. There is a really handy tool for that [2].
> You
> > > can
> > > > check online the assembly for different language constructs and
> > different
> > > > compilers.
> > > >
> > > > Best regards,
> > > > Anton
> > > >
> > > > [1] https://en.cppreference.com/w/cpp/language/range-for
> > > > [2] https://gcc.godbolt.org
> > > >
> > > > сб, 29 сент. 2018 г. в 13:15, kellen sunderland <
> > > > kellen.sunderl...@gmail.com>:
> > > >
> > > >> It's more readable because it's concise and it's consistent for many
> > > types
> > > >> you're looping over (i.e. primitive arrays, stl iterators, etc all
> > work
> > > >> the
> > > >> same way). It's also useful because it's consistent with other
> > > >> programming
> > > >> languages, making C++ codebases much easier to read for novice and
> > > >> intermediate developers. IMO it also leads to better naming in loop
> > > >> bodies
> > > >> as the concise style means you're less likely to have important 1
> > letter
> > > >> variable names describing loop elements (e.g. no int i =0 or it
> ...).
> > > >> More
> > > >> motivation can be found in the cpp standards proposals for C++11
> > > >> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1868.html
> > and
> > > >> http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm.
> > > >>
> > > >>
> > > >>
> > > >> On Sat, Sep 29, 2018 at 6:38 PM Naveen Swamy
> > > wrote:
> > > >>
> > > >> > Kellen,
> > > >> >
> > > >> > Could you please explain why you think range loops are better and
> > how
> > > it
> > > >> > improves readability? this is a relatively new feature, many of
> > them
> > > >> are
> > > >> > used to the old syntax, shouldn't we leave it for the developers
> to
> > > >> choose
> > > >> > the one that best suits the need and their familiarity.
> > > >> > In general I support the notion of standardizing where necessary,
> > > >> enforcing
> > > >> > rules on loops seems little bit like micro-managing how you should
> > > write
> > > >> > C++ code for MXNet.
> > > >> >
> > > >> > -1(open to change based on new
