Re: octave_read_value<Complex>

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: octave_read_value<Complex>

Rik-4
On 10/06/2015 08:20 AM, [hidden email] wrote:
ubject:
Re: Extending parser to accept '_' in numbers
From:
LachlanA [hidden email]
Date:
10/06/2015 06:06 AM
To:
[hidden email]
List-Post:
[hidden email]
Content-Transfer-Encoding:
7bit
Precedence:
list
MIME-Version:
1.0
References:
<MTAwMDAxOC5ub21hZA.1444079819@quikprotect>
In-Reply-To:
<MTAwMDAxOC5ub21hZA.1444079819@quikprotect>
Message-ID:
[hidden email]
Content-Type:
text/plain; charset=us-ascii
Message:
3

Greetings Rik,

If you're extending the numeric formats, a great one would be to expand 
octave_read_value<Complex>  to accept non-real numbers.  I'm currently
working on a C++ implementation of  textscan  based on John's skeleton of a
couple of years ago.  It is mostly done, but it won't be able to replace the 
.m  version until it can read complex numbers.

More generally, there are a few features that seem to need lookahead:
1. Reading complex numbers (1+2.3e-09i  is complex, but  1+2.3e-09  is two
reals)
2. multi-character comments symbols (like //), multi-character delimiters
and multi-character TreatAsEmpty symbols.

The way the second group are handled will depend on how the complex numbers
are handled.  I was thinking of writing a streambuf that provides multiple
characters of 'putback', but wasn't sure if that is appropriate.  (For
textscan, the alternative is to read an entire line into memory at once, but
that could be huge, since it allows \n to be ignored.)  If you can think of
how to read complex numbers, I'll see if that approach applies to the others
too.

Lachlan,

What you say is probably true.  However, at the moment I'm focused on the parser--the routines that process what you type on the command line.  octave_read_value() seems to be a part of stream processing, and entirely different code base, and is invoked when you process a file through the 'load' command.

Cheers,
Rik