Menu
▾
▴
wavepacket-ng-devel
|
From: Ulf L. <ul...@wa...> - 2012-12-02 23:09:31
|
Another thing that came to my mind between the project help request and now is that there is another option for the programming language. Basically, there are two ways (there are more, but they will not be more attractive...). We can use C++, especially C++-11, as suggested in the help request. There is little to say here. However, an alternative that I came across would be to use Java. The advantages, which brought up the whole idea: + It has much better integration in IDE's and with testing toolkits (JUnit, JMock etc.) + It is an easier language for the end user; garbage collection does not need to be kind of added, and there are less horrible language features than for C++. + Deployment is way easier. If we could implement the basic algorithms in Java only or find a library, one could have a stand-alone Java program in the end. Imagine a course on some quantum mechanics, and the students could just download a jar file and write their programs without having to compile or care about operating systems and such (of course, with a considerable performance penalty, but that might not be a big issue for small demo systems and today's computers). + Possibly easier scripting language support. I know that at least Matlab supports directly importing and working with java objects from scratch. Possibly something like this might hold for other scripting languages as well. However, some disadvantages: - there is some performance penalty associated with the use of Java. I once did a search and only found a factor of >= 2 in runtime for raw numerics; I have no idea how much the overhead would be for the rest of the code. - I did not find good Java-only numerical libraries. Also, for performance reasons, we would have to interface the low-level numerical details (matrix handling, FFT and such) with platform-dependent code. I have no idea how well this works, what quirks there are and so on. Also, the project would then probably contain different programming languages, build systems etc., which is kind of ... unaesthetic. - It might be that for some (large?) setups, setting up a Java Runtime environment is not trivial (e.g., parallel computing), so it might be that we effectively block this kind of usage. On the other hand, for large setups, people will usually write their own wavepacket code that is not portable to other problems, but well adapted to the targeted problem, which we will have a hard time beating anyway, or use a big monster like MCTDH, which is difficult to handle, but can handle large problems with additional approximations. I am not really decided either way, and as written, I have no feeling for several of the points, so I would put this to discussion and joint decision. Feel free to discuss and give a verdict. It might also be that we agree on testing something out, that would also be fine. Ulf |
|
From: Ulf L. <ul...@wa...> - 2012-12-04 12:13:52
|
On Mon, 3 Dec 2012 22:49:30 +0100 Piotr Bienkiewicz <dms...@gm...> wrote: > Hi, @Piotr: I assume this mail was intended for the mailing list; if so, you probably have to configure your mail client to use the reply-to header. > "It has much better integration in IDE's and with testing toolkits > (JUnit, JMock etc.)" > > Apparently there is no free IDE that supports code coverage for > c++. Netbeans for example provides free plugins to investigate code > coverage of java code. I should maybe always google first before claiming something. There seem to be unit testing, mock, and code coverage tools available for C++ as well. Altough I have no idea how well they work, and how easy they are to use. > "Possibly easier scripting language support. I know that at least > Matlab supports directly importing and working with java objects > from scratch" > > MATLAB has a really good language support. You can even embed C++, > Fortran or Ada code in an S-function and use it directly in SIMULINK. Ok, granted. I guess for embedding of C++ (never did this before), you only need some boilerplate code to announce the classes/functions/whatever? > I took a close look at the new Java 7 features a couple weeks ago. > Especially the new Join/Fork framework offers a great > support for compute intensive calculation on multiprocessor > systems. Nevertheless, my gut feeling tells me that C + + is still > more efficient. My gut feeling tells the same; the question is just how much the difference is. If it is, say 50%, this would not be a showstopper, if you can compensate with ease of use. However, I have no quantitative feeling here at all. As I said, you are free to vote down this idea. It was just an idea that was ripening over some time, and which needs to be decided for or against. Ulf |
|
From: Ulf L. <ul...@wa...> - 2012-12-04 12:36:40
|
On Mon, 3 Dec 2012 00:09:23 +0100 Ulf Lorenz <ul...@wa...> wrote: > + Possibly easier scripting language support. I know that at least > Matlab supports directly importing and working with java objects > from scratch. Possibly something like this might hold for other > scripting languages as well. Just noted: Since in practical cases, the low-level Math components will need to be written in something native anyway, the conection might actually not be quite that simple. Ulf |
|
From: Andrea at d. <me...@an...> - 2012-12-04 12:48:17
|
Hi there, I think C++ is still best choice to process large amount of data faster. But, one of the most important thing we need to consider is who will use this library and what kind of languages / environment they use. In my opinion we should use C++ so we'll be able to compile this library in all environment (Linux / MacOS / Windows). I didn't try but there is also this http://www.eclipse.org/cdt/ for C++ development. Andrea On Mon, Dec 3, 2012 at 12:09 AM, Ulf Lorenz <ul...@wa...> wrote: > Another thing that came to my mind between the project help request and > now is that there is another option for the programming language. > > Basically, there are two ways (there are more, but they will not be > more attractive...). > > We can use C++, especially C++-11, as suggested in the help request. > There is little to say here. However, an alternative that I came across > would be to use Java. > > The advantages, which brought up the whole idea: > > + It has much better integration in IDE's and with testing toolkits > (JUnit, JMock etc.) > > + It is an easier language for the end user; garbage collection does > not need to be kind of added, and there are less horrible language > features than for C++. > > + Deployment is way easier. If we could implement the basic algorithms > in Java only or find a library, one could have a stand-alone Java > program in the end. Imagine a course on some quantum mechanics, and > the students could just download a jar file and write their programs > without having to compile or care about operating systems and such > (of course, with a considerable performance penalty, but that might > not be a big issue for small demo systems and today's computers). > > + Possibly easier scripting language support. I know that at least > Matlab supports directly importing and working with java objects from > scratch. Possibly something like this might hold for other scripting > languages as well. > > > However, some disadvantages: > > - there is some performance penalty associated with the use of Java. I > once did a search and only found a factor of >= 2 in runtime for raw > numerics; I have no idea how much the overhead would be for the rest > of the code. > > - I did not find good Java-only numerical libraries. Also, for > performance reasons, we would have to interface the low-level > numerical details (matrix handling, FFT and such) with > platform-dependent code. I have no idea how well this works, what > quirks there are and so on. Also, the project would then > probably contain different programming languages, build systems etc., > which is kind of ... unaesthetic. > > - It might be that for some (large?) setups, setting up a Java Runtime > environment is not trivial (e.g., parallel computing), so it might be > that we effectively block this kind of usage. On the other hand, for > large setups, people will usually write their own wavepacket code > that is not portable to other problems, but well adapted to the > targeted problem, which we will have a hard time beating anyway, or > use a big monster like MCTDH, which is difficult to handle, but can > handle large problems with additional approximations. > > > I am not really decided either way, and as written, I have no feeling > for several of the points, so I would put this to discussion and joint > decision. Feel free to discuss and give a verdict. It might also be > that we agree on testing something out, that would also be fine. > > > Ulf > > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > DESIGN Expert tips on starting your parallel project right. > http://goparallel.sourceforge.net/ > _______________________________________________ > Wavepacket-ng-devel mailing list > Wav...@li... > https://lists.sourceforge.net/lists/listinfo/wavepacket-ng-devel > -- "Experience is what you get when you don't get what you want", Dan Stanford Andrea Girardi blog: http://www.andreagirardi.it linkedin: http://www.linkedin.com/in/andreagirardiverona web http://www.agdev.net |
|
From: Sakthi <sak...@gm...> - 2012-12-04 12:57:26
|
Hi all,
1)I have tried eclipse for C and C++ (for test programs only) and it
works fine. So there is a free IDE.
2) For unit test , there is a framework called Cpp Test and we need
to explore that . Check out
(cpp*test*.sourceforge.net/)
I am personally more excited to program in C++ , because I have been Java
programmer for last 6 years and didn't do much of a work in C++.
Thanks.
-Sakthivel Sundaresan *
*
*Whatever you do, work at it wholeheartedly as though you were doing it for
the Lord and not merely for people.
Col 3.23 (ISV)
*
On Tue, Dec 4, 2012 at 6:17 PM, Andrea at dotIT <me...@an...> wrote:
> Hi there,
>
> I think C++ is still best choice to process large amount of data faster.
> But, one of the most important thing we need to consider is who will use
> this library and what kind of languages / environment they use. In my
> opinion we should use C++ so we'll be able to compile this library in all
> environment (Linux / MacOS / Windows).
>
> I didn't try but there is also this http://www.eclipse.org/cdt/ for C++
> development.
>
> Andrea
>
>
> On Mon, Dec 3, 2012 at 12:09 AM, Ulf Lorenz <ul...@wa...> wrote:
>
>> Another thing that came to my mind between the project help request and
>> now is that there is another option for the programming language.
>>
>> Basically, there are two ways (there are more, but they will not be
>> more attractive...).
>>
>> We can use C++, especially C++-11, as suggested in the help request.
>> There is little to say here. However, an alternative that I came across
>> would be to use Java.
>>
>> The advantages, which brought up the whole idea:
>>
>> + It has much better integration in IDE's and with testing toolkits
>> (JUnit, JMock etc.)
>>
>> + It is an easier language for the end user; garbage collection does
>> not need to be kind of added, and there are less horrible language
>> features than for C++.
>>
>> + Deployment is way easier. If we could implement the basic algorithms
>> in Java only or find a library, one could have a stand-alone Java
>> program in the end. Imagine a course on some quantum mechanics, and
>> the students could just download a jar file and write their programs
>> without having to compile or care about operating systems and such
>> (of course, with a considerable performance penalty, but that might
>> not be a big issue for small demo systems and today's computers).
>>
>> + Possibly easier scripting language support. I know that at least
>> Matlab supports directly importing and working with java objects from
>> scratch. Possibly something like this might hold for other scripting
>> languages as well.
>>
>>
>> However, some disadvantages:
>>
>> - there is some performance penalty associated with the use of Java. I
>> once did a search and only found a factor of >= 2 in runtime for raw
>> numerics; I have no idea how much the overhead would be for the rest
>> of the code.
>>
>> - I did not find good Java-only numerical libraries. Also, for
>> performance reasons, we would have to interface the low-level
>> numerical details (matrix handling, FFT and such) with
>> platform-dependent code. I have no idea how well this works, what
>> quirks there are and so on. Also, the project would then
>> probably contain different programming languages, build systems etc.,
>> which is kind of ... unaesthetic.
>>
>> - It might be that for some (large?) setups, setting up a Java Runtime
>> environment is not trivial (e.g., parallel computing), so it might be
>> that we effectively block this kind of usage. On the other hand, for
>> large setups, people will usually write their own wavepacket code
>> that is not portable to other problems, but well adapted to the
>> targeted problem, which we will have a hard time beating anyway, or
>> use a big monster like MCTDH, which is difficult to handle, but can
>> handle large problems with additional approximations.
>>
>>
>> I am not really decided either way, and as written, I have no feeling
>> for several of the points, so I would put this to discussion and joint
>> decision. Feel free to discuss and give a verdict. It might also be
>> that we agree on testing something out, that would also be fine.
>>
>>
>> Ulf
>>
>>
>> ------------------------------------------------------------------------------
>> Keep yourself connected to Go Parallel:
>> DESIGN Expert tips on starting your parallel project right.
>> http://goparallel.sourceforge.net/
>> _______________________________________________
>> Wavepacket-ng-devel mailing list
>> Wav...@li...
>> https://lists.sourceforge.net/lists/listinfo/wavepacket-ng-devel
>>
>
>
>
> --
> "Experience is what you get when you don't get what you want", Dan Stanford
>
> Andrea Girardi
> blog: http://www.andreagirardi.it
> linkedin: http://www.linkedin.com/in/andreagirardiverona
> web http://www.agdev.net
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Wavepacket-ng-devel mailing list
> Wav...@li...
> https://lists.sourceforge.net/lists/listinfo/wavepacket-ng-devel
>
>
|
|
From: Ulf L. <ul...@wa...> - 2012-12-04 13:06:16
|
On Tue, 4 Dec 2012 18:26:59 +0530 Sakthi <sak...@gm...> wrote: > Hi all, > 1)I have tried eclipse for C and C++ (for test programs only) > and it works fine. So there is a free IDE. > 2) For unit test , there is a framework called Cpp Test and we > need to explore that . Check out > (cpp*test*.sourceforge.net/) > > I am personally more excited to program in C++ , because I have been > Java programmer for last 6 years and didn't do much of a work in C++. Ok, then I would suggest to drop the Java idea. Next: A name for the project. :) Ulf |
|
From: Ulf L. <ul...@wa...> - 2012-12-04 13:09:52
|
On Tue, 4 Dec 2012 13:47:25 +0100 Andrea at dotIT <me...@an...> wrote: > Hi there, > > I think C++ is still best choice to process large amount of data > faster. But, one of the most important thing we need to consider is > who will use this library and what kind of languages / environment > they use. The typical, average user will be an autodidact in coding, and mostly know Fortran (the coding style, not necessarily the language ;)). I guess the main operating systems will be Windows and Linux. In any case, we will need an easy-to-install package, preferably with everything precompiled, but I would defer this to a later stage when we have a bit to show. Then we could try out the usability with some test users. |
|
From: Andrea at d. <me...@an...> - 2012-12-04 13:40:07
|
Java should be easier to deploy a library (or a framework): we publish a JAR file and, who needs to use it, he has just to import into his project. Basically we need to do the same thing for C++, I suggest to take a look to this: http://stackoverflow.com/questions/1932883/how-to-design-a-c-c-library-to-be-usable-in-many-client-languages On Tue, Dec 4, 2012 at 2:09 PM, Ulf Lorenz <ul...@wa...> wrote: > On Tue, 4 Dec 2012 13:47:25 +0100 > Andrea at dotIT <me...@an...> wrote: > > > Hi there, > > > > I think C++ is still best choice to process large amount of data > > faster. But, one of the most important thing we need to consider is > > who will use this library and what kind of languages / environment > > they use. > > The typical, average user will be an autodidact in coding, and mostly > know Fortran (the coding style, not necessarily the language ;)). I > guess the main operating systems will be Windows and Linux. > > In any case, we will need an easy-to-install package, preferably with > everything precompiled, but I would defer this to a later stage when we > have a bit to show. Then we could try out the usability with some test > users. > > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > Wavepacket-ng-devel mailing list > Wav...@li... > https://lists.sourceforge.net/lists/listinfo/wavepacket-ng-devel > -- "Experience is what you get when you don't get what you want", Dan Stanford Andrea Girardi blog: http://www.andreagirardi.it linkedin: http://www.linkedin.com/in/andreagirardiverona web http://www.agdev.net |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X