slow 'eval' function - maybe pointers would do?

View: New views
13 Messages — Rating Filter:   Alert me  

slow 'eval' function - maybe pointers would do?

by coccoinomane :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi everybody!

I need to assign values to a series of variables with numbered names,  
such as

ks_1 = ... ;
ks_2 = ... ;
...
ks_N = ... ;

where N is big and is determined at runtime. I do not want to use a  
vector named 'ks' such that ks(i) = ks_i and so on. Therefore, I used  
the 'eval' function in this way:

for i=1:N
    eval ( [ 'k', int2str(i), ' = ... ;' ] );
endfor

However, using 'eval' the execution time of my loop increases ~6 fold.  
To test this behaviour, please try to run the following script:

tic();
for i=1:100000   sin(2);   endfor
toc()

tic();
for i=1:100000   eval ( 'sin(2);' );   endfor
toc()

On my machine, the output is:

Elapsed time is 0.8 seconds.
Elapsed time is 5 seconds.

Could you please suggest a more performance-friendly workaround?  
Actually, my numbered variables are fields of a structure (es.  
struct.k_1, struct.k_2 ... ); I thought that one could solve the  
problem by using pointers to access them, but I could not find support  
for pointers in Octave.

Thank you,

Guido
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

Re: slow 'eval' function - maybe pointers would do?

by Judd Storrs :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Thu, Oct 29, 2009 at 1:52 PM, Guido Walter Pettinari
<coccoinomane@...> wrote:
> where N is big and is determined at runtime. I do not want to use a
> vector named 'ks' such that ks(i) = ks_i and so on.

Are you aware of cell arrays? Are you opposed to them also?

> I thought that one could solve the
> problem by using pointers to access them, but I could not find support
> for pointers in Octave.

I don't think pointers exist in octave/matlab. The closest thing that
exists here are cell arrays. Octave/Matlab don't have pointers as far
as I know, but in most cases cell arrays get close enough to be usable
as a substitute. You can store mixed data types into cell arrays and
then use an index like a pointer.

> However, using 'eval' the execution time of my loop increases ~6 fold.

This is a well known challenge that plagues most (if not all)
interpreted languages and I don't think there is a solution. The
problem is that there is no way reasonable way to know what the
contents of the string will be before eval'd is called. As a
consequence, using eval requires the interpreter to decode the string
before it can process it. eval is pretty much the biggest enemy of
performance in octave and Matlab (and python and IDL ...).


--judd
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

Re: slow 'eval' function - maybe pointers would do?

by Carlo de Falco-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On 29 Oct 2009, at 18:52, Guido Walter Pettinari wrote:

> Hi everybody!
>
> I need to assign values to a series of variables with numbered names,
> such as
>
> ks_1 = ... ;
> ks_2 = ... ;
> ...
> ks_N = ... ;
>
> where N is big and is determined at runtime. I do not want to use a
> vector named 'ks' such that ks(i) = ks_i and so on. Therefore, I used
> the 'eval' function in this way:
>
> for i=1:N
>    eval ( [ 'k', int2str(i), ' = ... ;' ] );
> endfor
>
> However, using 'eval' the execution time of my loop increases ~6 fold.
> To test this behaviour, please try to run the following script:
>
> tic();
> for i=1:100000   sin(2);   endfor
> toc()
>
> tic();
> for i=1:100000   eval ( 'sin(2);' );   endfor
> toc()
>
> On my machine, the output is:
>
> Elapsed time is 0.8 seconds.
> Elapsed time is 5 seconds.
>
> Could you please suggest a more performance-friendly workaround?
> Actually, my numbered variables are fields of a structure (es.
> struct.k_1, struct.k_2 ... ); I thought that one could solve the
> problem by using pointers to access them, but I could not find support
> for pointers in Octave.
>
> Thank you,
>
> Guido


You can do what you ask by:

for ii = 1:N
names{ii}  = sprintf("ks_%d", ii);
values{ii} = somehow_compute_value (ii);
endfor

S = cell2struct (values, names, 2)

but what is the reason why you don't want to just use

for ii = 1:N
ks{ii}  = somehow_compute_value (ii);
endfor

?

c.

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

Re: slow 'eval' function - maybe pointers would do?

by coccoinomane :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi!

Thank you for the answers, Judd & Carlo!

> You can do what you ask by:
>
> for ii = 1:N
> names{ii}  = sprintf("ks_%d", ii);
> values{ii} = somehow_compute_value (ii);
> endfor
>
> S = cell2struct (values, names, 2)


You are right, but the point is that in my code each 'ks_i' is a  
vector of M elements. I am filling all the 'ks_i' vectors inside a  
'for i=1:M; for i=1:N' nested loop. If I were to call 'cell2struct' in  
each sub-loop, I will obtain many structs, while my idea is to store  
the data in a single struct. I want to obtain a struct 's' such that  
each field 's.ks_i' contains a Mx1 vector (where M is big).

By the way, I solved the issue by memorizing the 'ks_i' into a MxN  
vector called 'ks' inside the loop. Once outside the loop, I filled  
the struct in this way:

for j=1:N
   eval(  [ 's.k', int2str(j), ' = ks ( :, j );' ]     );
endfor

In this way I use more memory but the execution is faster.

Thank you,

Guido

P.S. Carlo, is there any reason whereby in your example you used  
sprintf instead of the string concatenation operator [ 'ks_', ii ] ?  
Is the former faster?


On Oct 29, 2009, at 19:37 , Carlo de Falco wrote:

>
> On 29 Oct 2009, at 18:52, Guido Walter Pettinari wrote:
>
>> Hi everybody!
>>
>> I need to assign values to a series of variables with numbered names,
>> such as
>>
>> ks_1 = ... ;
>> ks_2 = ... ;
>> ...
>> ks_N = ... ;
>>
>> where N is big and is determined at runtime. I do not want to use a
>> vector named 'ks' such that ks(i) = ks_i and so on. Therefore, I used
>> the 'eval' function in this way:
>>
>> for i=1:N
>> eval ( [ 'k', int2str(i), ' = ... ;' ] );
>> endfor
>>
>> However, using 'eval' the execution time of my loop increases ~6  
>> fold.
>> To test this behaviour, please try to run the following script:
>>
>> tic();
>> for i=1:100000   sin(2);   endfor
>> toc()
>>
>> tic();
>> for i=1:100000   eval ( 'sin(2);' );   endfor
>> toc()
>>
>> On my machine, the output is:
>>
>> Elapsed time is 0.8 seconds.
>> Elapsed time is 5 seconds.
>>
>> Could you please suggest a more performance-friendly workaround?
>> Actually, my numbered variables are fields of a structure (es.
>> struct.k_1, struct.k_2 ... ); I thought that one could solve the
>> problem by using pointers to access them, but I could not find  
>> support
>> for pointers in Octave.
>>
>> Thank you,
>>
>> Guido
>
>
> You can do what you ask by:
>
> for ii = 1:N
> names{ii}  = sprintf("ks_%d", ii);
> values{ii} = somehow_compute_value (ii);
> endfor
>
> S = cell2struct (values, names, 2)
>
> but what is the reason why you don't want to just use
>
> for ii = 1:N
> ks{ii}  = somehow_compute_value (ii);
> endfor
>
> ?
>
> c.
>

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

Re: slow 'eval' function - maybe pointers would do?

by Carlo de Falco-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On 30 Oct 2009, at 13:27, Guido Walter Pettinari wrote:

> Hi!
>
> Thank you for the answers, Judd & Carlo!
>
>> You can do what you ask by:
>>
>> for ii = 1:N
>> names{ii}  = sprintf("ks_%d", ii);
>> values{ii} = somehow_compute_value (ii);
>> endfor
>>
>> S = cell2struct (values, names, 2)
>
>
> You are right, but the point is that in my code each 'ks_i' is a
> vector of M elements. I am filling all the 'ks_i' vectors inside a
> 'for i=1:M; for i=1:N' nested loop. If I were to call 'cell2struct' in
> each sub-loop, I will obtain many structs, while my idea is to store
> the data in a single struct. I want to obtain a struct 's' such that
> each field 's.ks_i' contains a Mx1 vector (where M is big).

You can still get rid of the eval doing something like the following:

for ii =1:N
names{ii}  = sprintf("ks_%d", ii);
endfor

for jj=1:M
   for ii = 1:N
     KS{ii}(jj) = somehow_compute_value (ii,jj);
   endfor
endfor

S = cell2struct (KS, names, 2)

but still I don't understand why you want to call your vectors S.ks_ii,
I'm really curious: what's the problem with calling them KS{ii}?

> By the way, I solved the issue by memorizing the 'ks_i' into a MxN
> vector called 'ks' inside the loop. Once outside the loop, I filled
> the struct in this way:
>
> for j=1:N
>   eval(  [ 's.k', int2str(j), ' = ks ( :, j );' ]     );
> endfor
>
> In this way I use more memory but the execution is faster.

I expect the option I suggest above to be faster, especially if N is  
big.

> Thank you,
> Guido
>
> P.S. Carlo, is there any reason whereby in your example you used
> sprintf instead of the string concatenation operator [ 'ks_', ii ] ?
> Is the former faster?

I don't know about performance, I just find my syntax more elegant.

c.

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

RE: slow 'eval' function - maybe pointers would do?

by HALL, BENJAMIN PW :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


>-----Original Message-----
>From: Guido Walter Pettinari [mailto:coccoinomane@...]
>Sent: Friday, October 30, 2009 8:27 AM
>To: Octave Help Mailing List
>Subject: Re: slow 'eval' function - maybe pointers would do?
>
>


>By the way, I solved the issue by memorizing the 'ks_i' into a MxN  
>vector called 'ks' inside the loop. Once outside the loop, I filled  
>the struct in this way:
>
>for j=1:N
>   eval(  [ 's.k', int2str(j), ' = ks ( :, j );' ]     );
>endfor
>
>In this way I use more memory but the execution is faster.
>


You might try something along the lines of what follows to at least
eliminate the eval() call.  I'm not sure if use of fieldnames below is
documented in the octave manual (yet), but I'm sure there are examples
documented on the m*lab web help

flds = {};
for jj = 1:N
   flds{jj} = sprintf("k%d",jj);  ## I use sprintf() because prefer the
control
end

s.( flds{jj} ) = ks(:,jj);


_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

Re: slow 'eval' function - maybe pointers would do?

by John W. Eaton-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 30-Oct-2009, Guido Walter Pettinari wrote:

| Thank you for the answers, Judd & Carlo!
|
| > You can do what you ask by:
| >
| > for ii = 1:N
| > names{ii}  = sprintf("ks_%d", ii);
| > values{ii} = somehow_compute_value (ii);
| > endfor
| >
| > S = cell2struct (values, names, 2)
|
|
| You are right, but the point is that in my code each 'ks_i' is a  
| vector of M elements. I am filling all the 'ks_i' vectors inside a  
| 'for i=1:M; for i=1:N' nested loop. If I were to call 'cell2struct' in  
| each sub-loop, I will obtain many structs, while my idea is to store  
| the data in a single struct.

I think that's what the above code does.  It doesn't create many
structures.

Here's a complete working example:

  for ii = 1:4
    names{ii}  = sprintf ("ks_%d", ii);
    values{ii} = rand (3, 1);
  endfor

  S = cell2struct (values, names, 2)

Does that help?  You don't need eval to do this job.

| P.S. Carlo, is there any reason whereby in your example you used  
| sprintf instead of the string concatenation operator [ 'ks_', ii ] ?  
| Is the former faster?

The variable ii is not a string, so [ 'ks_', ii ] doesn't work.  You
have to convert the number to a string.  It looks better to me to
write it as sprintf ('ks_%d', ii) instead of ['ks_', num2str(ii)].

jwe
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

Re: slow 'eval' function - maybe pointers would do?

by Judd Storrs :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> for j=1:N
>   eval(  [ 's.k', int2str(j), ' = ks ( :, j );' ]     );
> endfor

If you want to make people shake their heads in disgust and pretend
they don't know you in public (probably also in private) while they
mutter under their breath about the coming of the end times and your
personal role as /the cause/ of hadal cooling, you can try (on linux
at least--I don't know how portable /dev/shm is to other unixen):

fid = fopen('/dev/shm/look_ma_no_eval.m','w') ;
fprintf(fid, "s.k%d = ks ( :, %d );\n" , 1:N, 1:N);
fclose(fid) ;
source /dev/shm/look_ma_no_eval.m ;
unlink /dev/shm/look_ma_no_eval.m ;

;)


--judd


P.S. Don't do this.

P.P.S. I have done this. /o\
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

Re: slow 'eval' function - maybe pointers would do?

by coccoinomane :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello everybody!

Sorry for this late reply but I had much work to do in these days.

Thank you for all the answers. It was very instructive to learn all  
the methods to handle with field names; I find particularly useful  
what Benjamin pointed out, that is the possibility to create/access a  
field via strings by using the parentheses:

for i = 1:N
field = sprintf ( 'something_%d', i );
S.(field) = whatever(i);
endfor

In this way the structures become really flexible!

@Carlo
> but still I don't understand why you want to call your vectors  
> S.ks_ii,
> I'm really curious: what's the problem with calling them KS{ii}?

I want to call the vectors in that way because I want a struct where  
the fields are just column vectors. I like to access everything in the  
structure S by just typing S.k1 or S.k2 rather than S.KS{i}. This is  
just a personal preference, probably because I mainly program in C++  
and I do not feel comfortable with cell arrays yet :)

Cheers,

Guido

P.S. Judd, I confere on you the prize for the most twisted solution :)))

On Oct 30, 2009, at 15:40 , Judd Storrs wrote:

>> for j=1:N
>>  eval(  [ 's.k', int2str(j), ' = ks ( :, j );' ]     );
>> endfor
>
> If you want to make people shake their heads in disgust and pretend
> they don't know you in public (probably also in private) while they
> mutter under their breath about the coming of the end times and your
> personal role as /the cause/ of hadal cooling, you can try (on linux
> at least--I don't know how portable /dev/shm is to other unixen):
>
> fid = fopen('/dev/shm/look_ma_no_eval.m','w') ;
> fprintf(fid, "s.k%d = ks ( :, %d );\n" , 1:N, 1:N);
> fclose(fid) ;
> source /dev/shm/look_ma_no_eval.m ;
> unlink /dev/shm/look_ma_no_eval.m ;
>
> ;)
>
>
> --judd
>
>
> P.S. Don't do this.
>
> P.P.S. I have done this. /o\

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

Re: slow 'eval' function - maybe pointers would do?

by Jaroslav Hajek-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Thu, Nov 5, 2009 at 11:00 PM, Guido Walter Pettinari
<coccoinomane@...> wrote:

> Hello everybody!
>
> Sorry for this late reply but I had much work to do in these days.
>
> Thank you for all the answers. It was very instructive to learn all
> the methods to handle with field names; I find particularly useful
> what Benjamin pointed out, that is the possibility to create/access a
> field via strings by using the parentheses:
>
> for i = 1:N
> field = sprintf ( 'something_%d', i );
> S.(field) = whatever(i);
> endfor
>
> In this way the structures become really flexible!
>
> @Carlo
>> but still I don't understand why you want to call your vectors
>> S.ks_ii,
>> I'm really curious: what's the problem with calling them KS{ii}?
>
> I want to call the vectors in that way because I want a struct where
> the fields are just column vectors. I like to access everything in the
> structure S by just typing S.k1 or S.k2 rather than S.KS{i}. This is
> just a personal preference, probably because I mainly program in C++
> and I do not feel comfortable with cell arrays yet :)
>
> Cheers,
>
> Guido
>

While it probably won't matter until number get really big, you should
also realize that the syntax
S.ks{i} is not only more natural (requires no string manipulation
whatsoever), it is also more efficient.
When you give S a thousand fields ks1...ks1000, then s.ks200 requires
a binary search in 1000 strings, while
s.ks{i} doesn't. Your approach is asymptotically inferior.
In other words, the arguments for using cell arrays are the same as
for using arrays of numbers rather than name-mangled scalars.

regards

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

Re: slow 'eval' function - maybe pointers would do?

by coccoinomane :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Dear Jaroslav,

I agree with you: I would never use my approach when the fields are  
more than, say, ~100. However, (i) I need only a few of S.ksi (ii)  
each of them is an array of numbers, not a scalar.

I often access, modify and plot structures' fields at Octave prompt. I  
just feel that addressing the variables with their name (e.g. S.k1)  
rather than with an index (e.g. S.k{1}) is quicker to type and less  
prone to errors. For example, the command:

plot ( S.k1, S.k2, '1x', S.k3, S.k4, '2x )

seems to me more easily typeable and readable than

plot ( S.k{1}, S.k{2}, '1x', S.k{3}, S.k{4}, '2x ).

Just a personal feeling :)

I would like to abuse of your kindness by asking two mailing-list  
questions:

1) When I reply to a mailing-list message, am I supposed to reply to  
the sender of the post as well? For example, should I include your  
personal email-address in the 'to' field?
2) Is it possible to attach text files or images when sending e-mails  
to the mailing list? Are there limits?

Thank you for your consideration.

Regards,

Guido

On Nov 6, 2009, at 9:51 , Jaroslav Hajek wrote:

> On Thu, Nov 5, 2009 at 11:00 PM, Guido Walter Pettinari
> <coccoinomane@...> wrote:
>> Hello everybody!
>>
>> Sorry for this late reply but I had much work to do in these days.
>>
>> Thank you for all the answers. It was very instructive to learn all
>> the methods to handle with field names; I find particularly useful
>> what Benjamin pointed out, that is the possibility to create/access a
>> field via strings by using the parentheses:
>>
>> for i = 1:N
>> field = sprintf ( 'something_%d', i );
>> S.(field) = whatever(i);
>> endfor
>>
>> In this way the structures become really flexible!
>>
>> @Carlo
>>> but still I don't understand why you want to call your vectors
>>> S.ks_ii,
>>> I'm really curious: what's the problem with calling them KS{ii}?
>>
>> I want to call the vectors in that way because I want a struct where
>> the fields are just column vectors. I like to access everything in  
>> the
>> structure S by just typing S.k1 or S.k2 rather than S.KS{i}. This is
>> just a personal preference, probably because I mainly program in C++
>> and I do not feel comfortable with cell arrays yet :)
>>
>> Cheers,
>>
>> Guido
>>
>
> While it probably won't matter until number get really big, you should
> also realize that the syntax
> S.ks{i} is not only more natural (requires no string manipulation
> whatsoever), it is also more efficient.
> When you give S a thousand fields ks1...ks1000, then s.ks200 requires
> a binary search in 1000 strings, while
> s.ks{i} doesn't. Your approach is asymptotically inferior.
> In other words, the arguments for using cell arrays are the same as
> for using arrays of numbers rather than name-mangled scalars.
>
> regards
>
> --
> RNDr. Jaroslav Hajek
> computing expert & GNU Octave developer
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

Re: slow 'eval' function - maybe pointers would do?

by Jaroslav Hajek-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Fri, Nov 6, 2009 at 11:28 AM, Guido Walter Pettinari
<coccoinomane@...> wrote:

> Dear Jaroslav,
>
> I agree with you: I would never use my approach when the fields are
> more than, say, ~100. However, (i) I need only a few of S.ksi (ii)
> each of them is an array of numbers, not a scalar.
>
> I often access, modify and plot structures' fields at Octave prompt. I
> just feel that addressing the variables with their name (e.g. S.k1)
> rather than with an index (e.g. S.k{1}) is quicker to type and less
> prone to errors. For example, the command:
>
> plot ( S.k1, S.k2, '1x', S.k3, S.k4, '2x )
>
> seems to me more easily typeable and readable than
>
> plot ( S.k{1}, S.k{2}, '1x', S.k{3}, S.k{4}, '2x ).
>
> Just a personal feeling :)
>

Easier to type, agreed. Easier to read, not. The former style conceals
the fact that the numbers are in fact indices (in terms of the logic
of your data). S.k_1 is already much better.


> I would like to abuse of your kindness by asking two mailing-list
> questions:
>
> 1) When I reply to a mailing-list message, am I supposed to reply to
> the sender of the post as well? For example, should I include your
> personal email-address in the 'to' field?

I use "Reply To All", which puts your address as "To:" and the mailing
list into "Cc". If you're responding to someone's else, message, it
makes sense to direct the message to him and Cc the list. But writing
just to the list is also possible.
Sometimes the former may enable the reader to take a special action
(for instance, I have a filter in Gmail that labels all messages from
Octave lists, and another filter that also stars those messages that
are directed to me, such as when someone replies to my comment).

> 2) Is it possible to attach text files or images when sending e-mails
> to the mailing list? Are there limits?

Yes. Yes. I think the limit is 100kB or something like that.

> Thank you for your consideration.
>
> Regards,
>
> Guido
>
> On Nov 6, 2009, at 9:51 , Jaroslav Hajek wrote:
>
>> On Thu, Nov 5, 2009 at 11:00 PM, Guido Walter Pettinari
>> <coccoinomane@...> wrote:
>>> Hello everybody!
>>>
>>> Sorry for this late reply but I had much work to do in these days.
>>>
>>> Thank you for all the answers. It was very instructive to learn all
>>> the methods to handle with field names; I find particularly useful
>>> what Benjamin pointed out, that is the possibility to create/access a
>>> field via strings by using the parentheses:
>>>
>>> for i = 1:N
>>> field = sprintf ( 'something_%d', i );
>>> S.(field) = whatever(i);
>>> endfor
>>>
>>> In this way the structures become really flexible!
>>>
>>> @Carlo
>>>> but still I don't understand why you want to call your vectors
>>>> S.ks_ii,
>>>> I'm really curious: what's the problem with calling them KS{ii}?
>>>
>>> I want to call the vectors in that way because I want a struct where
>>> the fields are just column vectors. I like to access everything in
>>> the
>>> structure S by just typing S.k1 or S.k2 rather than S.KS{i}. This is
>>> just a personal preference, probably because I mainly program in C++
>>> and I do not feel comfortable with cell arrays yet :)
>>>
>>> Cheers,
>>>
>>> Guido
>>>
>>
>> While it probably won't matter until number get really big, you should
>> also realize that the syntax
>> S.ks{i} is not only more natural (requires no string manipulation
>> whatsoever), it is also more efficient.
>> When you give S a thousand fields ks1...ks1000, then s.ks200 requires
>> a binary search in 1000 strings, while
>> s.ks{i} doesn't. Your approach is asymptotically inferior.
>> In other words, the arguments for using cell arrays are the same as
>> for using arrays of numbers rather than name-mangled scalars.
>>
>> regards
>>
>> --
>> RNDr. Jaroslav Hajek
>> computing expert & GNU Octave developer
>> Aeronautical Research and Test Institute (VZLU)
>> Prague, Czech Republic
>> url: www.highegg.matfyz.cz
>
> _______________________________________________
> Help-octave mailing list
> Help-octave@...
> https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
>



--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

Re: slow 'eval' function - maybe pointers would do?

by coccoinomane :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Thank you for the quick answer! I thought that using "Reply To All"  
would upset somebody, and I am happy to know that this is not the case.

Cheers,

Guido

On 6 Nov 2009, at 10:53, Jaroslav Hajek wrote:

> On Fri, Nov 6, 2009 at 11:28 AM, Guido Walter Pettinari
> <coccoinomane@...> wrote:
>> Dear Jaroslav,
>>
>> I agree with you: I would never use my approach when the fields are
>> more than, say, ~100. However, (i) I need only a few of S.ksi (ii)
>> each of them is an array of numbers, not a scalar.
>>
>> I often access, modify and plot structures' fields at Octave  
>> prompt. I
>> just feel that addressing the variables with their name (e.g. S.k1)
>> rather than with an index (e.g. S.k{1}) is quicker to type and less
>> prone to errors. For example, the command:
>>
>> plot ( S.k1, S.k2, '1x', S.k3, S.k4, '2x )
>>
>> seems to me more easily typeable and readable than
>>
>> plot ( S.k{1}, S.k{2}, '1x', S.k{3}, S.k{4}, '2x ).
>>
>> Just a personal feeling :)
>>
>
> Easier to type, agreed. Easier to read, not. The former style conceals
> the fact that the numbers are in fact indices (in terms of the logic
> of your data). S.k_1 is already much better.
>
>
>> I would like to abuse of your kindness by asking two mailing-list
>> questions:
>>
>> 1) When I reply to a mailing-list message, am I supposed to reply to
>> the sender of the post as well? For example, should I include your
>> personal email-address in the 'to' field?
>
> I use "Reply To All", which puts your address as "To:" and the mailing
> list into "Cc". If you're responding to someone's else, message, it
> makes sense to direct the message to him and Cc the list. But writing
> just to the list is also possible.
> Sometimes the former may enable the reader to take a special action
> (for instance, I have a filter in Gmail that labels all messages from
> Octave lists, and another filter that also stars those messages that
> are directed to me, such as when someone replies to my comment).
>
>> 2) Is it possible to attach text files or images when sending e-mails
>> to the mailing list? Are there limits?
>
> Yes. Yes. I think the limit is 100kB or something like that.
>
>> Thank you for your consideration.
>>
>> Regards,
>>
>> Guido
>>
>> On Nov 6, 2009, at 9:51 , Jaroslav Hajek wrote:
>>
>>> On Thu, Nov 5, 2009 at 11:00 PM, Guido Walter Pettinari
>>> <coccoinomane@...> wrote:
>>>> Hello everybody!
>>>>
>>>> Sorry for this late reply but I had much work to do in these days.
>>>>
>>>> Thank you for all the answers. It was very instructive to learn all
>>>> the methods to handle with field names; I find particularly useful
>>>> what Benjamin pointed out, that is the possibility to create/
>>>> access a
>>>> field via strings by using the parentheses:
>>>>
>>>> for i = 1:N
>>>> field = sprintf ( 'something_%d', i );
>>>> S.(field) = whatever(i);
>>>> endfor
>>>>
>>>> In this way the structures become really flexible!
>>>>
>>>> @Carlo
>>>>> but still I don't understand why you want to call your vectors
>>>>> S.ks_ii,
>>>>> I'm really curious: what's the problem with calling them KS{ii}?
>>>>
>>>> I want to call the vectors in that way because I want a struct  
>>>> where
>>>> the fields are just column vectors. I like to access everything in
>>>> the
>>>> structure S by just typing S.k1 or S.k2 rather than S.KS{i}. This  
>>>> is
>>>> just a personal preference, probably because I mainly program in C
>>>> ++
>>>> and I do not feel comfortable with cell arrays yet :)
>>>>
>>>> Cheers,
>>>>
>>>> Guido
>>>>
>>>
>>> While it probably won't matter until number get really big, you  
>>> should
>>> also realize that the syntax
>>> S.ks{i} is not only more natural (requires no string manipulation
>>> whatsoever), it is also more efficient.
>>> When you give S a thousand fields ks1...ks1000, then s.ks200  
>>> requires
>>> a binary search in 1000 strings, while
>>> s.ks{i} doesn't. Your approach is asymptotically inferior.
>>> In other words, the arguments for using cell arrays are the same as
>>> for using arrays of numbers rather than name-mangled scalars.
>>>
>>> regards
>>>
>>> --
>>> RNDr. Jaroslav Hajek
>>> computing expert & GNU Octave developer
>>> Aeronautical Research and Test Institute (VZLU)
>>> Prague, Czech Republic
>>> url: www.highegg.matfyz.cz
>>
>> _______________________________________________
>> Help-octave mailing list
>> Help-octave@...
>> https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
>>
>
>
>
> --
> RNDr. Jaroslav Hajek
> computing expert & GNU Octave developer
> Aeronautical Research and Test Institute (VZLU)
> Prague, Czech Republic
> url: www.highegg.matfyz.cz

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave