|
View:
New views
13 Messages
—
Rating Filter:
Alert me
|
|
|
slow 'eval' function - maybe pointers would do?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?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?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?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?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?>-----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?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?> 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?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?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?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?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?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 |
| Free embeddable forum powered by Nabble | Forum Help |