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

[Jaroslav Hajek]

On Fri, Nov 6, 2009 at 11:28 AM, Guido Walter Pettinari
<address@hidden> 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
>> <address@hidden> 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
> address@hidden
> 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