Is there any way to force GT.M not to treat a string with a canonical number as a number? I.e. if I do SET x("380")="",x("3791")="", instead of this order:
x(380)="" x(3791)=""
I would like to get this one:
x("3791")="" x("380")=""
I know the most obvious solution — prepend these key values with some non-numeric character, but it will certainly cause some logical complication for setting/reading/indexing. Is there any better solution?
> Is there any way to force GT.M not to treat a string with a canonical > number as a number? I.e. if I do SET x("380")="",x("3791")="", instead > of this order:
> x(380)="" > x(3791)=""
> I would like to get this one:
> x("3791")="" > x("380")=""
> I know the most obvious solution prepend these key values with some > non-numeric character, but it will certainly cause some logical > complication for setting/reading/indexing. Is there any better > solution?
Just curious but *why* would you want to do this? -- JJ
> Is there any way to force GT.M not to treat a string with a canonical > number as a number? I.e. if I do SET x("380")="",x("3791")="", instead > of this order:
> x(380)="" > x(3791)=""
> I would like to get this one:
> x("3791")="" > x("380")=""
> I know the most obvious solution — prepend these key values with some > non-numeric character, but it will certainly cause some logical > complication for setting/reading/indexing. Is there any better > solution?
On Jul 22, 5:47 pm, JJ <jeffersonjj.nos...@hotmail.com> wrote:
> > x("380")=""
> > I know the most obvious solution prepend these key values with some > > non-numeric character, but it will certainly cause some logical > > complication for setting/reading/indexing. Is there any better > > solution?
> Just curious but *why* would you want to do this?
Phone prefixes. They aren't numbers, they are essentially strings that happen to consist of numbers, therefore 3791 goes before 380.
Yeah, I know about this (didn't try it yet, though), but isn't it a region-wide setting? I just need this kind of "string enforcement" only for some very few subscripts.
The only problem with it is that even though it seems to work perfectly well for storage & retrieval (you just have to prepend subscript with $c(255)), any explicit or implicit ordering (say, $o) has no idea about that and will effectively disrupt proper workflow, UNLESS the key used in it is prepended with $c(255) itself so the value becomes a "forced string" as well. Otherwise it will consider provided key a number and next key will be the very first string key, which is clearly not what what you want to get in this scenario. In my case, I can workaround this by always prepending keys with that $c(255) as I always have that information on whether this particular subset of the global is a forced string or not. Also, as a side effect, ZWR will hang on globals with forced strings.
So, I have mixed feelings about this solution. On one hand, it works, on the other hand it causes some inconvenience (or, what's worse, potentially hanging GT.M when the key is not prepended with that prefix).
>>> x("380")="" >>> I know the most obvious solution prepend these key values with some >>> non-numeric character, but it will certainly cause some logical >>> complication for setting/reading/indexing. Is there any better >>> solution? >> Just curious but *why* would you want to do this?
> Phone prefixes. They aren't numbers, they are essentially strings that > happen to consist of numbers, therefore 3791 goes before 380.
if you really want this order (3791 followed by 380) then just append zeros or blanks to a fixed length.
Assuming, the longest prefix is 8 character long:
Variante a) ----------- Kill ^Prefix Set nul="00000000" For pref=3791,380 Set ^Prefix($e(pref_nul,1,8)_$l(pref))=""
Set pref="" For Set pref=$O(^Prefix(pref)) Quit:pref="" Write $e(pref,1,pref#10),!
^Prefix(379100004)="" ^Prefix(380000003)=""
Variante b) ----------- Kill ^Prefix Set spc=" " For pref=3791,380 Set ^Prefix($e(pref_spc,1,8))=""
Set pref="" For Set pref=$o(^Prefix(pref)) Quit:pref="" Write $p(pref," "),!
^Prefix("3791 ")="" ^Prefix("380 ")=""
Just for the curiosity, long time ago, I worked on a MUMPS system where numbers with leading zeros were sorted by their length and not by their value:
0,1,2,..8,9,00,01,02,..08,09,10,11,12,...98,99,000,001,002,..008, 009,010,011,012,...098,099,100,101,102 and so on.
It was perfect for article- or itemnumbers, bank accounts etc.
"Julius Kavay" <ka...@gmx.net.valid.address.changed.to.invalid> wrote in message news:8ath4eFo6nU1@mid.individual.net... > Yurii Rashkovskii wrote: >> On Jul 22, 5:47 pm, JJ <jeffersonjj.nos...@hotmail.com> wrote:
>>>> x("380")="" >>>> I know the most obvious solution prepend these key values with some >>>> non-numeric character, but it will certainly cause some logical >>>> complication for setting/reading/indexing. Is there any better >>>> solution? >>> Just curious but *why* would you want to do this?
>> Phone prefixes. They aren't numbers, they are essentially strings that >> happen to consist of numbers, therefore 3791 goes before 380.
> if you really want this order (3791 followed by 380) then > just append zeros or blanks to a fixed length.
> Assuming, the longest prefix is 8 character long:
> Variante a) > ----------- > Kill ^Prefix > Set nul="00000000" > For pref=3791,380 Set ^Prefix($e(pref_nul,1,8)_$l(pref))=""
> Set pref="" > For Set pref=$O(^Prefix(pref)) Quit:pref="" Write $e(pref,1,pref#10),!
> ^Prefix(379100004)="" > ^Prefix(380000003)=""
> Variante b) > ----------- > Kill ^Prefix > Set spc=" " > For pref=3791,380 Set ^Prefix($e(pref_spc,1,8))=""
> Set pref="" > For Set pref=$o(^Prefix(pref)) Quit:pref="" Write $p(pref," "),!
> ^Prefix("3791 ")="" > ^Prefix("380 ")=""
> Just for the curiosity, long time ago, I worked on a MUMPS system > where numbers with leading zeros were sorted by their length and > not by their value:
> 0,1,2,..8,9,00,01,02,..08,09,10,11,12,...98,99,000,001,002,..008, > 009,010,011,012,...098,099,100,101,102 and so on.
> It was perfect for article- or itemnumbers, bank accounts etc.
> Regards and > have a nice day > Julius
A single space on the end will work and often is just what you want for output - if not, it's easy to remove.
