function space

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

function space

vicnorton
In the manual or help there seems to be a preference to write
   'sin (X)' rather than 'sin(X)'
or
   'sprintf ("%d", i)' rather than 'sprintf("%d", i)'.
However, in at least one case, the space between the function name and its argument list results in a "parse error".

For example
   i = 5;
   x = [ "min", sprintf("%d", i) ];
results in
   x = "min5".
However
   i = 5;
   x = [ "min", sprintf ("%d", i) ];
results in
   parse error:
   
     syntax error

   >>> x = [ "min", sprintf ("%d", i) ];


Is this a bug? Or should one just avoid putting a space after a function name?

In what other situations does a space after a function name result in a syntax error?

Regards,

Vic
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: function space

bpabbott
Administrator

On Feb 21, 2012, at 2:24 PM, Vic Norton wrote:

> In the manual or help there seems to be a preference to write
>   'sin (X)' rather than 'sin(X)'
> or
>   'sprintf ("%d", i)' rather than 'sprintf("%d", i)'.
> However, in at least one case, the space between the function name and its argument list results in a "parse error".
>
> For example
>   i = 5;
>   x = [ "min", sprintf("%d", i) ];
> results in
>   x = "min5".
> However
>   i = 5;
>   x = [ "min", sprintf ("%d", i) ];
> results in
>   parse error:
>
>     syntax error
>
>>>> x = [ "min", sprintf ("%d", i) ];
>
>
> Is this a bug? Or should one just avoid putting a space after a function name?
>
> In what other situations does a space after a function name result in a syntax error?
>
> Regards,
>
> Vic

Its not a bug. Spaces and comma's are delimiters in a comma-separated-list (cs-list).

[1 2 3]
ans =

   1   2   3

[1, 2, 3]
ans =

   1   2   3

[1, 23]
ans =

    1   23

Ben



_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: function space

Jordi Gutiérrez Hermoso-2
In reply to this post by vicnorton
On 21 February 2012 14:24, Vic Norton <[hidden email]> wrote:
> In the manual or help there seems to be a preference to write

>   'sin (X)' rather than 'sin(X)'

> or

>   'sprintf ("%d", i)' rather than 'sprintf("%d", i)'.

> However, in at least one case, the space between the function name
> and its argument list results in a "parse error".

Yes, this is the preferred style because it consistently documents if
a(x) is a function call or an indexing. Function calls get the space,
indexing doesn't. It's part of the general GNU style, which has a bit
of a lisp flavour:

    http://www.gnu.org/prep/standards/standards.html#Formatting

However, for the case when you want this inside a [], you have to do
instead

    [(a (x)), b]

It's also acceptable to omit that space in such cases, and we
sometimes do that too in the Octave sources.

- Jordi G. H.
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: function space

Sergei Steshenko
In reply to this post by bpabbott


--- On Tue, 2/21/12, Ben Abbott <[hidden email]> wrote:

> From: Ben Abbott <[hidden email]>
> Subject: Re: function space
> To: "Vic Norton" <[hidden email]>
> Cc: "Octave Help" <[hidden email]>
> Date: Tuesday, February 21, 2012, 11:29 AM
>
> On Feb 21, 2012, at 2:24 PM, Vic Norton wrote:
>
> > In the manual or help there seems to be a preference to
> write
> >   'sin (X)' rather than 'sin(X)'
> > or
> >   'sprintf ("%d", i)' rather than
> 'sprintf("%d", i)'.
> > However, in at least one case, the space between the
> function name and its argument list results in a "parse
> error".
> >
> > For example
> >   i = 5;
> >   x = [ "min", sprintf("%d", i) ];
> > results in
> >   x = "min5".
> > However
> >   i = 5;
> >   x = [ "min", sprintf ("%d", i) ];
> > results in
> >   parse error:
> >
> >     syntax error
> >
> >>>> x = [ "min", sprintf ("%d", i) ];
> >
> >
> > Is this a bug? Or should one just avoid putting a space
> after a function name?
> >
> > In what other situations does a space after a function
> name result in a syntax error?
> >
> > Regards,
> >
> > Vic
>
> Its not a bug. Spaces and comma's are delimiters in a
> comma-separated-list (cs-list).
>
> [1 2 3]
> ans =
>
>    1   2   3
>
> [1, 2, 3]
> ans =
>
>    1   2   3
>
> [1, 23]
> ans =
>
>     1   23
>
> Ben
>
>

I think it's a bug.

This is because cs_list as its element may have a function call, and a function call consists of function name, optionally followed by whitespaces, optionally followed by list of arguments.

The question, however, is: is Octave smart enough to tell simple variable from function ? I.e. to relate the arguments list to the preceding name.

Regards,
  Sergei.

P.S. It's first of all a bug in what you guys call here "m-language" - a definitional flaw.


_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: function space

CdeMills
In reply to this post by vicnorton
The choice was made, in the design of scripts, to have
a (x)

mean both 'call the function "a" with argument "x"' and 'take the component at index "x" of vector "a".
The choice is made depending on the existing of a function called "a" or a variable called "a". This is the opposite of the C language, where the array access operator, "[", is different from function call "(".

So the additionnal space in the docs is there to emphasise the fact that parens are used in the context of function call. Now the "[" make the interpreter enter a specific mode, where space counts. So
a =[ sin (x) ]  

becomes incorrect, as the interpreter tries to call sin without arguments.

Regards

Pascal
Reply | Threaded
Open this post in threaded view
|

Re: function space

Sergei Steshenko


--- On Tue, 2/21/12, CdeMills <[hidden email]> wrote:

> From: CdeMills <[hidden email]>
> Subject: Re: function space
> To: [hidden email]
> Date: Tuesday, February 21, 2012, 12:49 PM
> The choice was made, in the design of
> scripts, to have
> a (x)
>
> mean both 'call the function "a" with argument "x"' and
> 'take the component
> at index "x" of vector "a".
> The choice is made depending on the existing of a function
> called "a" or a
> variable called "a". This is the opposite of the C language,
> where the array
> access operator, "[", is different from function call "(".
>
> So the additionnal space in the docs is there to emphasise
> the fact that
> parens are used in the context of function call. Now the "["
> make the
> interpreter enter a specific mode, where space counts. So
> a =[ sin (x) ] 
>
> becomes incorrect, as the interpreter tries to call sin
> without arguments.
>
> Regards
>
> Pascal
>
> --
> View this message in context: http://octave.1599824.n4.nabble.com/function-space-tp4408021p4408264.html
> Sent from the Octave - General mailing list archive at
> Nabble.com.
> _______________________________________________


To add to the confusion:

"
octave:1> foo = [1 2 3]
foo =

   1   2   3

octave:2> bar = [4 foo (2) 5]
bar =

   4   1   2   3   2   5

octave:3> bar = [4 foo(2) 5]
bar =

   4   2   5

octave:4> bar = [4 (foo (2)) 5]
bar =

   4   2   5

octave:5>
".

Looks like a definitional (of the "m-language") defect to me.

Regards,
  Sergei.

P.S. I hate both Python and 'make' languages for meaningful whitespaces.

_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: function space

CdeMills
Sergei Steshenko-2 wrote
To add to the confusion:

"
octave:1> foo = [1 2 3]
foo =

   1   2   3


".

Looks like a definitional (of the "m-language") defect to me.

Regards,
  Sergei.

P.S. I hate both Python and 'make' languages for meaningful whitespaces.
You have an interesting comparison of programming languages on Wikipedia, see in particular
http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(syntax)
http://en.wikipedia.org/wiki/Comparison_of_programming_languages_(array)

You could look from many point of view on it. Mine is quite simple: the perfect programming language does not yet exist.

For instance, I prefer R which makes a clear difference between function calls and array indexing. The price to pay is that the concatenation operator is not available, as it was "taken" for array indexing, and is replaced by the function "c", abbreviation of cat.

OTOH, I'm porting a Octave program to C in order to run it on an embedded platform. And I may assure you that the m-languages has some issues, but at least operators works on vector and matrices. A single line like
x = y(some condition on y) % x and y are vectors
is translated in many lines:
- malloc an array of size (y), and test if the result is OK
- loop on y, test the condition, fill the temporary array
- count the number of non-null elements in the temporary array
- free x memory
- allocate x memory with the count you've computed (and test it)
- loop on the temp vector, find the non-null elements, use their index to access y; concatenate the results in x
- do not forget to free the temp array

So yes there are a few flaws in the m-language, but you gain development speed, compactness, no need to declare variables, memory is managed for you, ...

Regards
Pascal
Reply | Threaded
Open this post in threaded view
|

maybe C++ and not "C" ? (was Re: function space)

Sergei Steshenko


--- On Tue, 2/21/12, CdeMills <[hidden email]> wrote:

> From: CdeMills <[hidden email]>
> Subject: Re: function space
> To: [hidden email]
> Date: Tuesday, February 21, 2012, 2:26 PM
>
[snip]

>
> For instance, I prefer R which makes a clear difference
> between function
> calls and array indexing. The price to pay is that the
> concatenation
> operator is not available, as it was "taken" for array
> indexing, and is
> replaced by the function "c", abbreviation of cat.
>
> OTOH, I'm porting a Octave program to C in order to run it
> on an embedded
> platform. And I may assure you that the m-languages has some
> issues, but at
> least operators works on vector and matrices. A single line
> like
> x = y(some condition on y) % x and y are vectors
> is translated in many lines:
> - malloc an array of size (y), and test if the result is OK
> - loop on y, test the condition, fill the temporary array
> - count the number of non-null elements in the temporary
> array
> - free x memory
> - allocate x memory with the count you've computed (and test
> it)
> - loop on the temp vector, find the non-null elements, use
> their index to
> access y; concatenate the results in x
> - do not forget to free the temp array
>
> So yes there are a few flaws in the m-language, but you gain
> development
> speed, compactness, no need to declare variables, memory is
> managed for you,
> ...
>
> Regards
> Pascal
>
> --
> View this message in context: http://octave.1599824.n4.nabble.com/function-space-tp4408021p4408551.html
> Sent from the Octave - General mailing list archive at
> Nabble.com.
>

Though I'm not a fan of C++, I must admit it does have some advantages over "C".

For what you are doing maybe the following:

http://arma.sourceforge.net/
http://eigen.tuxfamily.org/index.php?title=Main_Page

are useful. There are more similar projects, I remember just those two off the top of my head.

...

Does 'boost' library have matrix classes ?

Regards,
  Sergei.

_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: maybe C++ and not "C" ? (was Re: function space)

CdeMills
Sergei Steshenko-2 wrote

For what you are doing maybe the following:

http://arma.sourceforge.net/
http://eigen.tuxfamily.org/index.php?title=Main_Page

are useful. There are more similar projects, I remember just those two off the top of my head.

...

Does 'boost' library have matrix classes ?
I'm more accustomised to C; I use GSL (GNU Scientific Library) for vector and matrix operations.

Regards

Pascal