[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Converting (more or less) arbitrary strings to valid variable names

From: Bård Skaflestad
Subject: RE: Converting (more or less) arbitrary strings to valid variable names
Date: Tue, 20 Nov 2012 13:22:46 +0000


I'm afraid I don't fully understand your joke.  Maybe you wish to point out 
that imposing needless restrictions on your own (working) environment leads to 
greef that is better avoided altogether.  I think that's an astute observation 
and I won't argue the point.

Like I said, the 'genvarname' function is at best a partial solution.  It has 
the advantage of being built into Octave but, as you say, there is no direct 
support for recovering the original string from the 'genvarname' output.  If 
reversibility is important then I suppose uu{en,de}code might be a better 

On the other hand, you *could* create som sort of "translation table" to 
preserve reversibility when dynamically forming structure field names through 
'genvarname'.  For instance, you could do something like this (pseudo code, 
glossing over a lot of detail, for instance what to do with repeated strings):

    symtab = {};
    S = struct([]);
    while (get data)
         str = some string that uniquely identifies 'data';
         vname = getvarname(str, symtab(:,1));

         S.(vname) = data;
         symtab = [ symtab ; { vname, str } ];

Then, whenever you require the identification string of a field name, say, 
'_foo', you can extract it from 'symtab' using a statement such as

     str = symtab{strcmp(symtab(:,1), '_foo'), 2}

It is certainly not pretty, but it is a general approach that can be adopted to 
many interesting situations.

Bård Skaflestad
SINTEF ICT, Applied Mathematics

From: Sergei Steshenko address@hidden
Sent: 20 November 2012 03:23
To: Bård Skaflestad; address@hidden
Subject: Re: Converting (more or less) arbitrary strings to valid variable names

----- Original Message -----
> From: Bård Skaflestad <address@hidden>
> To: "address@hidden" <address@hidden>
> Cc:
> Sent: Monday, November 19, 2012 11:47 PM
> Subject: Converting (more or less) arbitrary strings to valid variable names
> All,
> In the long-running thread on "C-equivalent" structure (array)
> initialisation, someone asked of a way of converting an arbitrary string into 
> a
> valid variable name.  Unfortunately, I deleted the e-mail too early so I 
> cannot
> give proper attribution here.
> Still, I may be able to provide at least a partial answer to the inquiry.  The
> built-in function 'genvarname', present since at least Octave 3.2.3,
> does solve some of this problem.  Here's an example
>     > genvarname ("0  _f00  ba'r")
>     ans = _0___f00__ba_r
> Obviously, the normal restrictions on variable names apply (string restricted 
> to
> "namelengthmax" characters being the most severe).
> I hope this helps a little bit.
> Sincerely,
> --
> Bård Skaflestad
> SINTEF ICT, Applied Mathematics
> _______________________________________________
> Help-octave mailing list
> address@hidden

There is an old Jewish joke.

The joke is a story about a poor Jew who had quite a hard life.

So he, as the tradition prescribes, decided to consult the local rabbi.

The rabbi said: "Buy a goat".

The poor Jew didn't quite understand the essence of the advice, but followed it.


Several months later the poor Jew visited the rabbi again, this time simply 
lamenting and crying about how unbearable his life had become.

The rabbi said: "Sell the goat !".

The poor Jew next day after selling the goat couldn't find enough words of 
gratitude to thank the rabbi. The Jew couldn't belief the relief he found after 
selling the goat.


The problem with your function is that there may already be underscores in 
otherwise illegal name, e.g. 'foo_ _bar'. So, there will be no easy way to get 
back the original name.

A much better way has already been suggested: uuencode -> uudecode - like 
solutions. I.e. reversibility is guaranteed.

But why do we need the "goat" in the first place ?

I went carefully through 
and did _not_ find there "struct arrays". So, this Matlab artifact should be 
implemented in the least obtrusive for end user manner - only to make sure 
Matlab code runs in Octave.

A _consistent_ hash table implementation is fair enough.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]