Re: Oct-file version of the cquad integrator

[Pedro Gonnet]

Hi Jarolslav,

Thanks for the comments! Here are the fixes:

        1. Damn, these are standard in C and unfortunately, I'm not much
        of a C++ programmer. I've replaced them with the local macros.
        
        2. You actually uncovered a quite different bug... The number of
        sings (and thus initial intervals) is actually limited by the
        size of the heap, so I just declared a constant array and added
        a check for overflow.
        
        3. I have absolutely no idea what you're talking about... Feel
        free to change it however you feel is best!
        
Cheers,
Pedro


On Tue, 2010-04-27 at 15:29 +0200, Jaroslav Hajek wrote:
> On Tue, Apr 27, 2010 at 2:01 PM, Pedro Gonnet <address@hidden> wrote:
> >
> > Small bug in the handling of string arguments fixed, e.g. it doesn't
> > handle functions passed as strings, just handles the error correctly
> > now.
> >
> > Cheers, Pedro.
> >
> 
> 
> Nice job. I'm on vacation now, but I had a quick look anyway. I have
> several suggestions:
> 
> 1. don't use std::isnan, std::isinf, std::isfinite. These are not
> standard C++, so we shouldn't rely on them being available. Instead,
> Octave provides xisnan, xisinf, xfinite. These will map onto the std::
> functions if they are available, so they incur no performance penalty,
> otherwise they will be emulated. When Octave switches to C++0x
> standard, we'll probably replace the x-versions.
> 
> 2. *don't* use alloca, it's non-standard and often buggy. Use
> OCTAVE_LOCAL_BUFFER instead.
> 
> 3. Extracting function pointer through function_value works, but it
> has the drawback that overloads for a named handle are ignored. An
> alternative is to call directly the octave_value::do_multi_index_op
> method.
> 
> I'll probably address these points later unless you do it first. In
> any case, thanks for this contribution.
> 
> regards
>

cquad.C
Description: Text Data