wavepacket-ng-devel — List for development topics (C++-version)

Re: [Wavepacket-ng-devel] Tracking system

[Burkhard S. <Bur...@fu...>]

Hi everybody,

even without knowing the alternatives from my own experience, I would 
nevertheless favor the SourceForge internal tracker (ticket system). 
Even though it may not be the most flexible system, it will always have 
the advantage of being embedded in the Allura interface and thus being 
able to link most directly to the other Allura tools such as the Wiki, 
the code (svn, git,hg) tools etc ... Why making things more complicated 
than necessary?

Best regards from Berlin
Burkhard

On 16.12.2012 22:18, Ulf Lorenz wrote:
> Hi again,
>
> to continue the discussion with the tracking system, I have now had
> an, albeit brief, look at the Sourceforge tracking system, and Jira.
> Feel free to contradict or generally discuss.
>
> First Jira. I see two problems here:
>
> 1. It is too complex. You can administrate several projects, link
>     everything together with release history and whatnot; basically,
>     perfect for a complex company. However, when I look at some publicly
>     available setups, I get the feeling you need to read a manual first.
>     In other words, a bit too heavy for the <= half a dozen developers.
> 2. While it is free for open source projects, as far as I understand,
>     the idea is that you install a trial version and somehow apply for
>     the full version. If possible, I would like to avoid having to
>     care for another piece of software, but rather use a Cloud service
>     here.
>
>
> Regarding the sourceforge internal tracker, it looks like your standard
> tracker setup. You have milestones which consists of single tasks,
> which each have a couple of customizable fields, some text, and a
> discussion. What I dislike here is that if you have a couple of tasks
> around (10 unclosed tasks might not be uncommon), it might be a bit
> annoying to get a quick one-second glance about the status. Otherwise,
> it might be possible to tweak it to our use.
>
>
> Mantis is probably in the same vein as the sourceforge tracker. Unless
> there is some free hosting, I would suggest against it, again to avoid
> having to care for additional software.
>
>
> For the kanban board, I have attached two screen shots for how we use
> it in freelords. Basically, we create a new swimlane (/row) for each
> design task (silver), in which we put and move around smaller coding
> tasks (green/brown).
>
>
> In summary, I would suggest either to try out the internal tracker
> (because it is internal and something new for me), or the kanban board
> (works fine with this style of project development).
>
>
> Comments?
>
>
> Ulf
>
>
> ------------------------------------------------------------------------------
> 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


-- 
*---------------------------+----------------------------------------*
| PD Dr. Burkhard Schmidt   | Mailto:bur...@fu...   |
| Freie Universitaet Berlin | HTTP://page.mi.fu-berlin.de/bsch63     |
| Institute for Mathematics | Phone : (+49) 30 / 838 - 75 369        |
| Arnimallee 6              |         (+49) 30 / 838 - 75 367 (secr) |
| D-14195 Berlin-Dahlem     | Fax   : (+49) 30 / 838 - 75 412        |
*---------------------------+----------------------------------------*

Re: [Wavepacket-ng-devel] Tentative Roadmap

[Ulf L. <ul...@wa...>]

On Sun, 16 Dec 2012 22:35:16 +0100
Ulf Lorenz <ul...@wa...> wrote:

> Hi,
> 
> just a quick update on the roadmap; if you disagree, feel free to
> comment.
> 
> 0.0.1: Free-particle propagation
> 
> - Goal: Propagate a free particle
> - will require implementations of the basic interfaces (grid,
> operator, wavefunction, propagators (?) math interfaces)

As an additional thought, I still would like to abstract the
mathematical details away in a separate library. However, I would like
to defer this to a later stage; this would allow to parallelize the
development (you do not need to wait for the library to be finished),
and we would collect typical use-cases _before_ we start to abstract
things.


Ulf

[Wavepacket-ng-devel] Libraries

[Ulf L. <ul...@wa...>]

Hi,

to keep you a bit more busy while the remaining items are finished,
maybe we should start looking around for convenient libraries. I do not
mind outsourcing this work to you, so feel free to apply for it. :)


1. We need tools for the tests. Specifically, we need
   - a library/tool to easily do automated tests, somewhat similar to
     JUnit (check for doings something, throwing of exceptions, anything
     else?)
   - preferably, a library for mocking classes, similar to JMock

   As a goal, here, you might just create a "Hello, world", unit test.


2. We need libraries for the basic maths
   - A library that can represent multidimensional matrices, and do
     certain manipulations (something like a matrix multiplication
     along a certain degree of freedom, vector products / summation
     along a certain degree of freedom, for later also basic things
     like eigenvalue calculation)
   - A library for doing an FFT, which is compatible with the matrix
     library

   As a goal here, you could create a simple program that does these
   manipulations.


Comments/Questions?


Ulf

Re: [Wavepacket-ng-devel] Build system

[Ulf L. <ul...@wa...>]

Since the build system can be migrated rather easily, does anyone mind
if we start with simple makefiles?


Ulf


On Wed, 5 Dec 2012 23:25:23 +0100
Ulf Lorenz <ul...@wa...> wrote:

> Hi,
> 
> what we further need to decide on is a build system. I have some
> limited knowledge, maybe someone of you can contribute here.
> 
> The program will consist of different libraries, each being a more
> or less separate project with different dependencies. It would make
> sense, for example, to put the mathematical stuff in a separate
> library, so that we can have, e.g., a simple mathematics library with
> few dependencies and, say, another library that uses Cuda for more
> speed, but with exotic dependencies.
> 
> So what we make is first basic make tool, and second a mechanism for
> dependency recognition.
> 
> What I know of make tools is
> * make (ugly in some parts, but pretty standard on Unix)
> * ant (Java-based and thus portable)
> * maven (only heard of it; sounds nice, but no knowledge)
> Do you have deeper knowledge or know other build toold, and/or what
> would you suggest to use?
> 
> For the dependency recognition, what I know here is:
> * Do everything as variables. The user then has to edit the "Makefile"
>   and compile
> * autoconf/automake. Pretty standard, but really ugly as far as I
>   recall.
> * CMake. I know it exists, but have never used it.
> * others?
> What ideas, suggestions do you have here?
> 
> Ulf
> 
> ------------------------------------------------------------------------------
> 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

[Wavepacket-ng-devel] Tentative Roadmap

[Ulf L. <ul...@wa...>]

Hi,

just a quick update on the roadmap; if you disagree, feel free to
comment.

0.0.1: Free-particle propagation

- Goal: Propagate a free particle
- will require implementations of the basic interfaces (grid, operator,
  wavefunction, propagators (?) math interfaces)


0.0.2 Harmonic oscillator

- Goal: Propagate a harmonic oscillator in a simple way
- requires assembling operators to produce more complex operators
- also could include a propagator interface, unless it is implemented
  before.


Ulf

Re: [Wavepacket-ng-devel] Tracking system

[Ulf L. <ul...@wa...>]

Hi again,

to continue the discussion with the tracking system, I have now had
an, albeit brief, look at the Sourceforge tracking system, and Jira.
Feel free to contradict or generally discuss.

First Jira. I see two problems here:

1. It is too complex. You can administrate several projects, link
   everything together with release history and whatnot; basically,
   perfect for a complex company. However, when I look at some publicly
   available setups, I get the feeling you need to read a manual first.
   In other words, a bit too heavy for the <= half a dozen developers.
2. While it is free for open source projects, as far as I understand,
   the idea is that you install a trial version and somehow apply for
   the full version. If possible, I would like to avoid having to
   care for another piece of software, but rather use a Cloud service
   here.


Regarding the sourceforge internal tracker, it looks like your standard
tracker setup. You have milestones which consists of single tasks,
which each have a couple of customizable fields, some text, and a
discussion. What I dislike here is that if you have a couple of tasks
around (10 unclosed tasks might not be uncommon), it might be a bit
annoying to get a quick one-second glance about the status. Otherwise,
it might be possible to tweak it to our use.


Mantis is probably in the same vein as the sourceforge tracker. Unless
there is some free hosting, I would suggest against it, again to avoid
having to care for additional software.


For the kanban board, I have attached two screen shots for how we use
it in freelords. Basically, we create a new swimlane (/row) for each
design task (silver), in which we put and move around smaller coding
tasks (green/brown).


In summary, I would suggest either to try out the internal tracker
(because it is internal and something new for me), or the kanban board
(works fine with this style of project development).


Comments?


Ulf

Re: [Wavepacket-ng-devel] Project name

[Ulf L. <ul...@wa...>]

Ok, since noone objected, this is now set. I noticed that Burkhard was
faster than me, so the subproject is already found under
http://sourceforge.net/p/wavepacket/cpp


Ulf


On Tue, 4 Dec 2012 17:34:41 +0100
Ulf Lorenz <ul...@wa...> wrote:

> On Sun, 2 Dec 2012 23:43:23 +0100
> Ulf Lorenz <ul...@wa...> wrote:
> 
> > First thing to decide on: How do we want to name the project?
> > 
> > There are two names: The public name (what labels appear and so on),
> > and an internal name that serves as the link on the sourceforge
> > pages.
> 
> Since the subproject is now gone, and we need not take care of it any
> longer, I would build on Burkhard's idea, and suggest:
> 
> internal name: cpp (appears in the web server path)
> outside name: WavePacket, C++ version (just "C++ version" on the
>               project page)
> 
> and use version numbers "cpp-x.y.z" for this project, so that one can
> refer to it simply as "WavePacket cpp-1.0" etc.
> 
> 
> Ulf
> 
> ------------------------------------------------------------------------------
> 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

Re: [Wavepacket-ng-devel] Tracking system

[Piotr B. <dms...@gm...>]

Hi,

I'm currently working with Mantis bugtracker. Works quite well.

Piotr

2012/12/5 Ulf Lorenz <ul...@wa...>

> Hi,
>
> we further need something to keep track of all tasks and who is doing
> what. What we would need is to create tasks with text and such and
> change their status (working on it, up for review, done). The rest are
> convenience features, but might still be a killer argument. Things like
> grouping tasks together into some distinct project, task dependencies,
> blocking tasks when they are stuck somehow, ... you name it.
>
> The options so far (please extend if you know more):
>
> * The sourceforge tracker. You should all have permissions up to admin
>   to test out a tracker at https://sourceforge.net/p/wavepacket/tickets.
>
>   The advantage is that it is directly integrated in sourceforge.
>   However, I have not tried it out yet, so please play around and tell
>   if it would be usable.
>
> * A kanban board: http://kanbanize.com is free and we use it with
>   freelords quite successfully.
>
> * Andrea mentioned Jira. I have no experience with it at all, so please
>   add your arguments, knowledge etc.
>
> * ...?
>
>
> Ulf
>
>
> ------------------------------------------------------------------------------
> 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
>

[Wavepacket-ng-devel] Tracking system

[Ulf L. <ul...@wa...>]

Hi,

we further need something to keep track of all tasks and who is doing
what. What we would need is to create tasks with text and such and
change their status (working on it, up for review, done). The rest are
convenience features, but might still be a killer argument. Things like
grouping tasks together into some distinct project, task dependencies,
blocking tasks when they are stuck somehow, ... you name it.

The options so far (please extend if you know more):

* The sourceforge tracker. You should all have permissions up to admin
  to test out a tracker at https://sourceforge.net/p/wavepacket/tickets.

  The advantage is that it is directly integrated in sourceforge.
  However, I have not tried it out yet, so please play around and tell
  if it would be usable.

* A kanban board: http://kanbanize.com is free and we use it with
  freelords quite successfully.

* Andrea mentioned Jira. I have no experience with it at all, so please
  add your arguments, knowledge etc.

* ...?


Ulf

Re: [Wavepacket-ng-devel] Version control system

[Ulf L. <ul...@wa...>]

On Wed, 5 Dec 2012 23:19:15 +0100
Andrea at dotIT <me...@an...> wrote:

> What's about the tracking issue / bug system? I seen Jira is free for
> open source project.

I wanted to look at the sourceforge internal tracker before putting
this to discussion. And this depended on the name of the subproject.
However, I will just override this and put a tracker in the main
project for testing. Give me 10 minutes...


Ulf

[Wavepacket-ng-devel] Build system

[Ulf L. <ul...@wa...>]

Hi,

what we further need to decide on is a build system. I have some
limited knowledge, maybe someone of you can contribute here.

The program will consist of different libraries, each being a more
or less separate project with different dependencies. It would make
sense, for example, to put the mathematical stuff in a separate
library, so that we can have, e.g., a simple mathematics library with
few dependencies and, say, another library that uses Cuda for more
speed, but with exotic dependencies.

So what we make is first basic make tool, and second a mechanism for
dependency recognition.

What I know of make tools is
* make (ugly in some parts, but pretty standard on Unix)
* ant (Java-based and thus portable)
* maven (only heard of it; sounds nice, but no knowledge)
Do you have deeper knowledge or know other build toold, and/or what
would you suggest to use?

For the dependency recognition, what I know here is:
* Do everything as variables. The user then has to edit the "Makefile"
  and compile
* autoconf/automake. Pretty standard, but really ugly as far as I
  recall.
* CMake. I know it exists, but have never used it.
* others?
What ideas, suggestions do you have here?

Ulf

Re: [Wavepacket-ng-devel] Version control system

[Andrea at d. <me...@an...>]

Hi there,

I used CVS only so, for me, it's not a big deal. I seen that git is
supported by Eclipse without plugin but there is a free plugin for
Mercurial.

What's about the tracking issue / bug system? I seen Jira is free for open
source project.

Andrea




On Wed, Dec 5, 2012 at 9:15 PM, Ulf Lorenz <ul...@wa...> wrote:

> On Mon, 3 Dec 2012 09:13:31 +0530
> Sakthi <sak...@gm...> wrote:
>
> > Hello Ulf and all,
> >       I have the working  experience of working with mercurial. It is
> > quite easy to get started .If you have any specific questions, please
> > shoot and we can discuss on those.
>
> That would be 1:0 for Mercurial, then. Anyone has ideas or arguments
> for git?
>
> Otherwise, I have also had a look at the Mercurial tutorial, and it
> seems ok.
>
>
> Ulf
>
>
> ------------------------------------------------------------------------------
> 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

Re: [Wavepacket-ng-devel] Version control system

[Ulf L. <ul...@wa...>]

On Mon, 3 Dec 2012 09:13:31 +0530
Sakthi <sak...@gm...> wrote:

> Hello Ulf and all,
>       I have the working  experience of working with mercurial. It is
> quite easy to get started .If you have any specific questions, please
> shoot and we can discuss on those.

That would be 1:0 for Mercurial, then. Anyone has ideas or arguments
for git?

Otherwise, I have also had a look at the Mercurial tutorial, and it
seems ok.


Ulf

[Wavepacket-ng-devel] Fw: Project name

[Ulf L. <ul...@wa...>]

I just noticed that the mailing list does not set Reply-To by default;
I have added this option, so the replies will now by default all go to
the mailing list.

Begin forwarded message:

Date: Tue, 04 Dec 2012 19:01:21 +0100
From: Burkhard Schmidt <bur...@fu...>
To: Ulf Lorenz <ul...@wa...>
Subject: Re: [Wavepacket-ng-devel] Project name



> Since the subproject is now gone, and we need not take care of it any
> longer, I would build on Burkhard's idea, and suggest:
>
> internal name: cpp (appears in the web server path)
> outside name: WavePacket, C++ version (just "C++ version" on the
>                project page)
>
> and use version numbers "cpp-x.y.z" for this project, so that one can
> refer to it simply as "WavePacket cpp-1.0" etc.
>
Yes, ok, I like it ...


> *---------------------------+----------------------------------------*
> | PD Dr. Burkhard Schmidt   | Mailto:bur...@fu...   |
> | Freie Universitaet Berlin | HTTP://page.mi.fu-berlin.de/bsch63     |
> | Institute for Mathematics | Phone : (+49) 30 / 838 - 75 369        |
> | Arnimallee 6              |         (+49) 30 / 838 - 75 367 (secr) |
> | D-14195 Berlin-Dahlem     | Fax   : (+49) 30 / 838 - 75 412        |
> *---------------------------+----------------------------------------*

[Wavepacket-ng-devel] Reading list

[Ulf L. <ul...@wa...>]

Hi,

just for the time being, I thought I would also provide some pointers
to the Physics/Math background that would be good, just in case you
want to study a bit while the basic administrative things are going
along.

One pointer is a Wiki page:
https://sourceforge.net/apps/mediawiki/wavepacket/index.php?title=WavePacket.Numerics.DVR#Generalized_DVR

If you can follow the derivations of this page, you are definitely up to
any task. Although on reading again, this looks a bit prohibitive at
first, that is the basic maths why we would represent a wave function
on a grid.

Another pointer would be a book by David Tannor: "Introduction to
Quantum Mechanics: A time-dependent perspective". He is one of the big
fish when it comes to wavepacket dynamics and all that, and the book
pretty much focuses on what WavePacket would be about. Interesting
would be chapters 1-7 (introduction), 8 (formal theory), 11 (basically
the DVR method explained in the page above, but more elaborately), and
12 (basic molecular dynamics; especially Born-Oppenheimer
approximation).


Ulf

Re: [Wavepacket-ng-devel] Project name

[Ulf L. <ul...@wa...>]

On Sun, 2 Dec 2012 23:43:23 +0100
Ulf Lorenz <ul...@wa...> wrote:

> First thing to decide on: How do we want to name the project?
> 
> There are two names: The public name (what labels appear and so on),
> and an internal name that serves as the link on the sourceforge pages.

Since the subproject is now gone, and we need not take care of it any
longer, I would build on Burkhard's idea, and suggest:

internal name: cpp (appears in the web server path)
outside name: WavePacket, C++ version (just "C++ version" on the
              project page)

and use version numbers "cpp-x.y.z" for this project, so that one can
refer to it simply as "WavePacket cpp-1.0" etc.


Ulf

[Wavepacket-ng-devel] Fw: Programming language

[Ulf L. <ul...@wa...>]

Begin forwarded message:

Date: Tue, 04 Dec 2012 14:22:27 +0100
From: Burkhard Schmidt <Bur...@fu...>
To: Ulf Lorenz <ul...@wa...>
Subject: Re: [Wavepacket-ng-devel] Programming language


Because there might be problems with special characters (such as "+"

Why not simply "cpp" as a name?

Re: [Wavepacket-ng-devel] Programming language

[Andrea at d. <me...@an...>]

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

Re: [Wavepacket-ng-devel] Programming language

[Ulf L. <ul...@wa...>]

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.

Re: [Wavepacket-ng-devel] Programming language

[Ulf L. <ul...@wa...>]

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

Re: [Wavepacket-ng-devel] Programming language

[Sakthi <sak...@gm...>]

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
>
>

Re: [Wavepacket-ng-devel] Programming language

[Andrea at d. <me...@an...>]

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

Re: [Wavepacket-ng-devel] Programming language

[Ulf L. <ul...@wa...>]

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

Re: [Wavepacket-ng-devel] Programming language

[Ulf L. <ul...@wa...>]

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

Re: [Wavepacket-ng-devel] SourceForge user names

[Ulf L. <ul...@wa...>]

Ok, you have all been added to a special group, which will have write
permission as soon as there are writable tools in the subproject.

On another, Burkhard removed the subproject for some cleaning up. I
would recreate it when we have settled for a name; right now I do
not see an option to modify the name after creation. :\


Ulf