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. Second, if one follows MPITB
syntax, then the documentation that is already written will be valid. 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. However, I'm a user, not a
developer, so I'll start being more quiet about it :-)
M.
------------------------------------------------------------------------------
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
