Dear Octave supporters,
my dream is that this package is better synced with current Octave development,
and that is very easy to understand from absolute beginners like me, so it
could be easily upgraded and enhanced from all over the world.
Bests
Riccardo
--- Ven 20/11/09, Jaroslav Hajek <high...@gmail.com> ha scritto:
Da: Jaroslav Hajek <high...@gmail.com>
Oggetto: Re: [OctDev] Contribution to Octave-forge with a simple
Open-MPIPackage
A: "Michael Creel" <michael.cr...@uab.es>
Cc: "Riccardo Corradini" <riccardocorrad...@yahoo.it>, "Søren Hauberg"
<so...@hauberg.org>, octave-dev@lists.sourceforge.net
Data: Venerdì 20 novembre 2009, 15:45
On Fri, Nov 20, 2009 at 3:31 PM, Michael Creel <michael.cr...@uab.es> wrote:
On Fri, Nov 20, 2009 at 3:20 PM, Jaroslav Hajek <high...@gmail.com> wrote:
On Fri, Nov 20, 2009 at 2:57 PM, Michael Creel <michael.cr...@uab.es> wrote:
On Fri, Nov 20, 2009 at 1:57 PM, Jaroslav Hajek <high...@gmail.com> wrote:
>
>
> On Fri, Nov 20, 2009 at 1:44 PM, Michael Creel <michael.cr...@uab.es> wrote:
>>
>> Hi all,
>>
>> In another message, Jaroslav made the comment
>>
>>> 1. info is the first output argument in all functions. I think it should
>>> be the second one, so that it can be easily ignored if wanted.
>>> In particular, the check in examples
>>>
>>> if not(MPI_Initialized)
>>> info = MPI_Init();
>>> end
>>>
>>> makes no sense (unless I'm missing something) because it's the info
>>> output from MPI_Initialized that is tested and that is always zero.
>>
>> This follows the MPI standard, which says:
>>>
>>> All MPI routines (except MPI_Wtime and MPI_Wtick) return an error value;
>>> C routines as the value of the function and Fortran routines in the last
>>> argument. Before the value is returned, the current MPI error handler is
>>> called. By default, this error handler aborts the MPI job. The error handler
>>> may be changed with MPI_Errhandler_set; the predefined error handler
>>> MPI_ERRORS_RETURN may be used to cause error values to be returned. Note
>>> that MPI does not guarentee that an MPI program can continue past an error.
>>>
>>> MPI_SUCCESS No error; MPI routine completed successfully.
>>
>> Following the standard is a big plus, in my opinion. That way, knowledge
>> about MPI previously gained from C or Fortran will be useful when using MPI
>> with Octave.
>
> Yes, my approach still follows the standard, it's just more convenient to
> use. The standard says nothing about how external bindings should behave.
>
Right, but MPI functions for C or Fortran don't return anything but things like
info, flag, status. The contents of messages passed back and forth are not
obtained from return values of functions. It's certainly possible to place a
received message into the output of a MPI_Recv binding, and there may be a some
logic to the idea, but it is a step away from the C and Fortran way of doing
things. Most people will learn about MPI though C and Fortan tutorials, so
following that syntax is not a bad idea. What would you propose to use as
outputs of functions?
M.
I think you didn't understand, Michael. What I'm proposing is just to switch
the order to a more convenient one.
Take the simplest example: MPI_Initialized.
This is now called like
[info, flag] = MPI_Initialized ();
where info is always zero (MPI_SUCCESS) and flag is the actual result. What I'm
proposing is to use instead
[flag, info] = MPI_Initialized ();
because then the call
flag = MPI_Initialized (); # ignore info
is possible, and it is also possible to do
if (MPI_Initialized)
something
endif
In C, the corresponding call is
info = MPI_Initialized (&flag);
but there is *no* way you can preserve this structure in Octave. In Octave,
every output argument must be a return value; there is no other way (unless you
pass names and manipulate the caller scope directly).
--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
OK, I see what you mean. I think that new bindings should try to emulate MPITB
as closely as possible. For one thing, MPITB is clearly the most widely used
way of using MPI with Octave, so most existing code uses its syntax. At the
moment it is much more complete.
But MPITB is already free software (isn't it?), so why develop a clone? MPITB
users can still run their code using MPITB.
But this is a chance to do things better than MPITB.
Second, if one follows MPITB syntax, then the documentation that is already
written will be valid.
Documentation? What documentation?
I also hope that it might be possible for the projects to merge or at least
benefit from one another, so getting too far apart from the outset for little
benefit might not be a good idea.
I wouldn't call it a little benefit. I'm not sure if any merge is possible; in
any case I don't think there's a public repository for MPITB (vital for shared
development). I was also hoping I could help keep this package better synced
with current Octave development.
Ultimately it's up to Riccardo to decide whether the development should be
constrained by MPITB. If so, I'll probably fork my own version.
--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev
