I come with the background in languages like Java or Python where modular programming is enabled by packaging system and import directive (aka namespace aliasing). Historically MATLAB's approach to resolve problems like naming conflicts boils down to setting/playing with MATLABPATH, renaming/extending identifiers with prefixes, etc. So far I have been successfully playing with native MATLAB packaging by prepending plus sign "+" before the folder name (MATLAB notation for package also see here). Obviously they are very long to type ;-) Basically I am back to the similar problem as discussed here with no solution. So let me paraphrased for my particular angle:
Assume I have folder +mypackage defined containing file myfun.m with the function code of the same name.
How to achieve aliasing for MATLAB function inside the user (non-java) package as illustrated by the following python code:
from mypackage import myfun
?
[EDIT] Please note that AFAIK import keyword works only for java classes (with jvm attached to MATLAB process). No, import is working perfectly fine for both functions and aliases for objects and function of both Java and MATLAB origin.
Possibly related but not the same.
[EDIT2]
python's
from mypackage import myfun as anotherfun
is equivalent to MATLAB's
anotherfun = #mypackage.myfun
Doesn't
import mypackage.myfun
work?
link to documentation
Related
I have a script in Matlab, which accesses a DLL and allows me to utilize the methods to import and analyse data programmatically. However, I would like to convert it to python. I have looked at using pythonnet, but I cannot get it to work. Can anyone suggest a way of replicating this behaviour in python?
Ths example is specific to Delsys and their EMGWorks software.
%locate HPF DLL within EMGworks install folder
path = ['C:\Program Files (x86)\pathtoDLL\HPF.dll'];
%make HPF assembly visible to MATLAB
NET.addAssembly(path);
%locate target HPF file
curFile = 'C:\TestFiles\MyTestFile.hpf';
%construct HPF reader
myHPFreader = HPF.HPFReader(curFile);
%invoke “GetAllSampleRates” method on HPF reader object “myHPFreader”
mySampleRates = myHPFreader.GetAllSampleRates;
Thanks Tim!
I made one small change to the great example you provided!
channel_names = emg_file.GetAllChannelNames()
The emg_file change matched the variable.
The key it seems is knowing the structure of the dll so you can instantiate the class. I looked at the Matlab docs to work this out.
1. Install Python.net
pip install pythonnet
2. Import package and make package available to Python
import clr
clr.AddReference('C:\Program Files (x86)\Delsys, Inc\EMGworks\Matlab Conversion Library \HPF.dll')
3. Instantiate class object
This was initially confusing for me. But it seems that the name of the DLL will be the name of the package. In my case the .dll is HPF.dll so my package name is HPF.
from HPF import HPFReader
emg_file = HPFReader(<filename>)
4. Utilise methods from table in matlab docs to get file info and print it out
channel_names = data.GetAllChannelNames()
for channel in channel_names:
print(channel)
I could declare a package or import a package in Modelica models, but I am not sure if there is any difference between them, I tried the following code, both of them work fine.
My question is :
Is there anything I should pay attention to when using these two methods?
partial model A
package SI1=Modelica.SIunits;
import SI2=Modelica.SIunits;
SI1.Voltage u1;
SI2.Voltage u2;
end A;
You are doing two fundamentally different things here, which both work for this case:
package SI1=Modelica.SIunits; is called a short class definition.
You create a new package named SI1, which inherits everything from Modelica.SIunits.
Short class definitions are basically the same as writing
package SI1
extends Modelica.SIunits;
end SI1;
See chapter 4.5.1 Short Class Definitions in the Modelica spec for details.
import SI2=Modelica.SIunits on the other hand simply influences where the Modelica tool looks for class definitions - so no new class is defined here. The chapter 13.2.1.1 Lookup of Imported Names explains that in the Modelica spec.
If you just want to use the package, import it. That's what import was designed for. Declaring a new package only makes sense if you want to add functionality or change anything (which is very limited though, if you are using the short class definition).
Only the import clause seems to trigger the lookup on a package that is not already loaded. Using for example the Modelica_LinearSystems2 library:
import: it checks, and Modelica_LinearSystems2 is loaded
partial model A
import ls2=Modelica_LinearSystems2;
end A;
package: it checks, but Modelica_LinearSystems2 is not loaded
partial model B
package ls=Modelica_LinearSystems2;
end B;
I guess that can break your models if not all of their dependencies are loaded when trying to simulate.
It is nevertheless interesting to see how Dymola (or even Modelica, since pedantic check doesn't throw any error) does not seem to care much about the use of package instead of import, when it comes to packages already loaded. I wasn't expecting the following model to work:
model C
package SI1=Modelica.SIunits;
SI1.Voltage u1;
parameter SI1.Current R=1;
equation
u1=2*R;
end C;
It turns out that even auto-completion (Ctrl+Space) works:
I'm using the assistant proof COQ, my first question would be about the Induction.v file, why do we use Require Export Basics, instead of Require Import basics? Also why does it work when we make Export basics.v, even if I changed the name of basics to Mybasics.v?
What does Require Export Basics. do? Does it import or export?
I tried to execute lists.v after compiling the induction.v but it doesn't work, it says
Unable to locate library Induction.
How can I fix that?
Are you working on software foundation? You need to add the folder to COQPATH. since proof general has handled that, i bet you are using coqide, aren't you?
The rest of your question can all be resolved by consulting the coq ref manual: https://coq.inria.fr/refman/toc.html .
The difference between Require Import and Require Export can be found here: https://coq.inria.fr/refman/vernacular.html#hevea_command115
Providing more information about compilation (e.g. whether you were using command line or code editor, Coq version, textbook version etc.) could be useful for resolving your issue.
I came out to scala programmin from Java so it's not clear to me how we should use relative imports in Scala and what is the exact name lookup rules? Suppose I have the following:
pack.age
|
|----MyClass.scala
com.age
|
|---AnotherClass.scala
I need to import MyClass.scala into AnotherClass.scala. Since Scala supports only relative imports I wrote the following:
import _root_.pack.age.MyClass
and it worked fine. But when I tried to delete _root_ from there, there was no compile time error either.
import pack.age.MyClass
works fine as well.
So, what is the package name lookup rules in Scala?
I believe there is an order of operations here. If you had package.age.MyClass within com.age (ie. com.age.package.age.MyClass), as well as package.age.MyClass, the former would be picked up. If you wanted the latter, you would need to use the root syntax.
As there is only one place this class can be picked up from (in root), that is the package picked up.
All imports are relative, so sometimes collisions can appear. For example, if you have package com.org.project.scala then next import scala._ looks up for system package too. _root_ is implicit top package that can be utilised for simulation of absolute path.
I'm in the midst of trying to create my own radon transform function, for which I need to rotate the simple image I've created. According to the documentation, the function is in scipy.misc.
However,
from scipy.misc import imrotate
gives me "could not import name imrotate"
and
import scipy.misc
scipy.misc.imrotate(myImage,theta)
says that scipy.misc does not have a module named 'imrotate' when I try to call the function.
I've tried removing the '--pylab inline' arguments from my launch, and I've made sure the PIL/Image libraries aren't imported, because I've heard that there were problems with that in other threads, but nothing seems to make it work.
I've gotten around it for now by using a different suite, the scikit-image library, but I'd prefer to use the scipy version if I can, because it's more commonly used.
scipy.misc.imrotate requires the library PIL and I guess that is your problem. Ether it is not installed at all or not installed correctly.
You can use scipy.ndimage.interpolation.rotate instead.