I'm trying to port some scripts from a modern version of Intersystems Cache back to 1980s Datatree MUMPS. It was written in the context where $ZUTIL(18,2) was set. That is, undefined variables resolve to an empty string, rather than throwing an "undefined variable" error.
Rather than refactor it all to check $DATA, does anyone know whether DTM supports a similar feature to automatically resolve undefined variables per process, or globally?
*Update: running "zzswitch +2" did the trick.
That was tricky one.
Have a look at this document:
ftp://ftp.intersystems.com/pub/cache/DTMtoCache.doc95
It says that equivalent of $ZU(18) in DTM was zzswitch +2 / -2
I obviously can't run DTM now so just try to issue zzswitch +2 and then zzswitch -2 and see how does it affect the way your undefined vars are treated.
PS: I would understand efforts of migrating from DTM to Cache, but going back? Mate it's not even necromancy, it's archeology now.
Related
raw_df.loc[:,'full_size'] = raw_df.loc[:,:].apply( full_size,axis="columns",).copy()
is throwing the warning:
See the caveats in the documentation: https://pandas.pydata.org/pandas-docs/stable/user_guide/indexing.html#returning-a-view-versus-a-copy
I thought/recalled that normally I can fix this by making sure everything is .loc'd properly, or making the the right hand side a copy(). But this line has been stubbornly throwing the warning regardless. Maybe I'm misunderstanding the warning, but I cannot see what I'm doing here that is potentially-dodgy.
The warning is legit since you're calling pandas.Series.copy on a series where in the same line you assign this one to another series.
I can't tell what's your needs but you can try this approach instead:
raw_df['full_size']= raw_df.apply(full_size, axis='columns')
ser_fullsize= raw_df.loc[:,'full_size'].copy() # or raw_df['full_size'].copy()
Getting warning from Script Checker : "OMEGA13 was used but was never set (will evaluate as its name)"
I've set
start using Omega13
-- some codes here --
stop using Omega13
Anyone has any idea on why the warning sign is there?
Eggplant documentation - Advance scripting: Error Recovery with Omega13
What's probably happened is somewhere you've mistyped some variant of omega13.
Sensetalk treats uninitialized variables as strings. This results in lots of hard to debug errors.
name = "my name"
put naame
This will print naame which is probably not what you wanted.
It looks like the correct form to invoke is omega13 not Omega13, or OMEGA13. I'd check the documentation and make sure that you haven't mistyped it anywhere.
You may also want to look into the strictVariables global which if true will treat using an uninitialized variable as an error.
I'm using TF-Agents library for reinforcement learning,
and I would like to take into account that, for a given state,
some actions are invalid.
How can this be implemented?
Should I define a "observation_and_action_constraint_splitter" function when
creating the DqnAgent?
If yes: do you know any tutorial on this?
Yes you need to define the function, pass it to the agent and also appropriately change the environment output so that the function can work with it. I am not aware on any tutorials on this, however you can look at this repo I have been working on.
Note that it is very messy and a lot of the files in there actually are not being used and the docstrings are terrible and often wrong (I forked this and didn't bother to sort everything out). However it is definetly working correctly. The parts that are relevant to your question are:
rl_env.py in the HanabiEnv.__init__ where the _observation_spec is defined as a dictionary of ArraySpecs (here). You can ignore game_obs, hand_obs and knowledge_obs which are used to run the environment verbosely, they are not fed to the agent.
rl_env.py in the HanabiEnv._reset at line 110 gives an idea of how the timestep observations are constructed and returned from the environment. legal_moves are passed through a np.logical_not since my specific environment marks legal_moves with 0 and illegal ones with -inf; whilst TF-Agents expects a 1/True for a legal move. My vector when cast to bool would therefore result in the exact opposite of what it should be for TF-agents.
These observations will then be fed to the observation_and_action_constraint_splitter in utility.py (here) where a tuple containing the observations and the action constraints is returned. Note that game_obs, hand_obs and knowledge_obs are implicitly thrown away (and not fed to the agent as previosuly mentioned.
Finally this observation_and_action_constraint_splitter is fed to the agent in utility.py in the create_agent function at line 198 for example.
I've recently encountered these two variables in some Velocity code:
$!variable1
!$variable2
I was surprised by the similarity of these so I became suspicious about the correctness of the code and become interested in finding the difference between two.
Is it possible that velocity allows any order of these two symbols or do they have different purpose? Do you know the answer?
#Jr. Here is the guide I followed when doing VM R&D: http://velocity.apache.org/engine/1.7/user-guide.html
Velocity uses the !$ and $! annotations for different things. If you use !$ it will basically be the same as a normal "!" operator, but the $! is used as a basic check to see if the variable is blank and if so it prints it out as an empty string. If your variable is empty or null and you don't use the $! annotation it will print the actual variable name as a string.
I googled and stackoverflowed a lot before I finally found the answer at people.apache.org.
According to that:
It is very easy to confuse the quiet reference notation with the
boolean not-Operator. Using the not-Operator, you use !${foo}, while
the quiet reference notation is $!{foo}. And yes, you will end up
sometimes with !$!{foo}...
Easy after all, shame it didn't struck me immediately. Hope this helps someone.
I'm working with legacy code and ran across something that I haven't been able to explain after several days of looking up tutorials and handbooks for GW Basic: a variable (P9%) is used in a comparison on line 530 (IF P9% <> 0) before the code would reach its definition on line 860. It's not a complex piece of code, only ~1200 lines total, so I am confident that I haven't missed any goto or gosub or anything that would reach 860 earlier than this comparison.
I am curious as to how this has been effecting the program as it runs. Most of my experience is with c++ where this sort of thing wouldn't compile, and if it did an unassigned variable could potentially contain anything that would fit, but I have no idea what kind of default assignment is given to a variable in Basic.
It has been many years since I wrote much in gwbasic!
If I remember correctly the variable is assigned a zero value in that case. Gwbasic (and Qbasic I think) assigns a default value to all variables when first referenced, this is usually zero or the empty string for a string variable.
Interestingly when creating an array using the DIM statement, all the items in the array are also initialised this way.
Even with this mechanism it is usually better to initialise a variable, just to be clear what is happening.
Many programmers of the era writing for gwbasic omitted as much as they could to minimise the amount of memory used by the program instructions so they had more for other stuff. So that may be why it's not initialised.