See: Description
| Class | Description |
|---|---|
| Client |
This class represents the connection with the core and handles the
xml-rpc calls.
|
| OneResponse |
This class encapsulates OpenNebula's XML-RPC responses.
|
| Pool |
Represents a generic OpenNebula Pool in XML format
and provides the basic functionality to handle the Pool elements.
|
| PoolElement |
Represents a generic element of a Pool in
XML format.
|
| Exception | Description |
|---|---|
| ClientConfigurationException |
This exception is thrown when a a new Client is constructed with wrong
authorization options.
|
| OneException |
The
OneException class is a generic OpenNebula exception. |
Provides the Java bindings for the OpenNebula Cloud API (OCA).
The included classes can be used as simple wrappers for the XML-RPC calls supported by the OpenNebula core, or as objects that store the information and provide useful helpers.
Apart from this jar file, you need to add to the project's build-path the Apache XML-RPC library.
You can download it from Apache's distribution directory. The jar files you need are xmlrpc-client-*.jar, ws-commons-util-*.jar and xmlrpc-common-*.jar.
Please visit the OpenNebula site for general information, and consult the documentation section to find up to date references, tutorials, and more.
You can learn about the OpenNebula XML-RPC API here.
Visit OpenNebula.org
Copyright 2002-2012 ©
OpenNebula Project Leads (OpenNebula.org).


Table Name: tabC-Form
| Sr | Fieldname | Type | Label | Options |
|---|---|---|---|---|
| 1 | naming_series |
Select | Series |
C-FORM- |
| 2 | c_form_no |
Data | C-Form No | |
| 3 | received_date |
Date | Received Date | |
| 4 | customer |
Link | Customer | Customer |
| 5 | column_break1 |
Column Break | ||
| 6 | company |
Link | Company | Company |
| 7 | quarter |
Select | Quarter |
I II III IV |
| 8 | total_amount |
Currency | Total Amount |
Company:company:default_currency |
| 9 | state |
Data | State | |
| 10 | section_break0 |
Section Break | ||
| 11 | invoices |
Table | Invoices | C-Form Invoice Detail |
| 12 | total_invoiced_amount |
Currency | Total Invoiced Amount |
Company:company:default_currency |
| 13 | amended_from |
Link | Amended From | C-Form |
Inherits from dataent.model.document.Document


Congratulations! You have reached the landing page. Here you can learn more about this application, create an account, and even login.


--- title: "[Understanding Analysis by Stephen Abbott] - [Chapter 1 The Real Numbers] - [1.5 Cardinality]" published: true tags: RealAnalysis ---
The term cardinality is used in mathematics to refer to the size of a set.
Definition 1.5.1 A function \(f : A \to B\) is one-to-one \((1-1\)) if \(a_1 \neq a_2\) in \(A\) implies that \(f(a_1) \neq f(a_2)\) in \(B\). The function is onto if, given any \(b in B\), it is possible to find an element \(a \in A\) for which \(f(a) = b\)
A function \(f : A \to B\) that is both \((1-1)\) and onto provides us with exactly what we mean by a \((1-1)\) correspondence between two sets. The property of being \((1-1)\) means that no two elements of \(A\) correspond to the same element of \(B\), and the property of being onto ensures that every element of \(B\) corresponds to something in \(A\)
Definition 1.5.2 The set \(A\) has the same cardinality as \(B\) if there exists \(f : A \to B\) that is \(1-1\) and onto. In this case, we write \(A \sim B\)
Definition 1.5.5 A set \(A\) is countable if \(N \sim A\). An infinite set that is not countable is called an uncountable set.
Theorem 1.5.6
Proof.
The crucial observation is that each \(A_n\) is finite and every rational number appears in exactly on of these sets. Our \(1-1\) correspondence with \(N\) is then achieved by consecutively listing the elements in each \(A_n\)
The fact that this line of reasoning applies to any rational number \(p/q\) is our proof that the set \(A_n\) were constructed to be disjoint so that no rational number appears twice.
Let \(I_1\) be a closed interval that does not contain \(x_1\). Next let \(I_2\) be a closed interval, contained in \(I_1\), which does not contain \(x_2\). The existence of such an \(I_2\) is easy to verify. Certainly \(I_1\) contains two smaller disjoint closed intervals, and \(x_2\) can only be in one of these. In general, given an interval \(I_n\), construct \(I_{n+1}\) to satisfy
We now consider the intersection \(\bigcap_{n=1}^\infty I_n\). If \(x_{n_0}\) is some real number from the list \(\eqref{1}\), then we have \(x_0 \notin I_{n_0}\), and it follows that $$ x_{n_0} \notin \bigcap_{n=1}^\infty I_n $$
Now, we are assuming that the list in \(\eqref{1}\) contains every real number, and this leads to the conclusion that $$ \bigcap_{n=1}^\infty I_n = \emptyset $$
However, the Nested Interval Property (NIP) asserts that \(\bigcap_{n=1}^\infty I_n \neq \emptyset \). By NIP, there is at least one \(x \in \bigcap_{n=1}^\infty I_n\) that, consequently cannot be on the list in \eqref{1}. This contradiction means that such an enumeration of \(R\) is impossible, and we conclude that \(R\) is an uncountable set.
What exactly should be make of this discovery? It is an important exercise to show that any subset of a countable set must be either countable or finite. If a set can be arranged into a single list, then deleting some elements from this list results in another (shorter, and potentially terminating) list. This means that countable sets are smaller type of infinite set. Anything smaller is either still countable or finite.
The cardinality of \(R\) is, informally speaking, a larger type of infinity. The real numbers so outnumber the natural numbers that there is no way to map \(N\) onto \(R\). The set \(Q\), on the other hand, is countable. By imitating the demonstration that \(N ~ Z\), we can prove that the union of two countable sets must be countable. Because \(R = Q \cup \I\), it follows that \(I\) cannot be countable otherwise \(R\) would be. The inescapable conclusion is that, despite the fact that we have encountered so few of them, the irrational numbers form a far greater subset of \(R\) than \(Q\).
Theorem 1.5.7 If \(A \subseteq B\) and \(B\) is countable, then \(A\) is either countable or finite.
Theorem 1.5.8


Correspondence
University of Chester Academies Trust (UCAT): inspection outcome letter
This letter includes findings from a review of the Trust’s overall performance and recommendations to improve student achievement.
Details
This letter follows focused inspections of 3 of the academies in the Trust during November 2016.
Inspectors also held telephone discussions with the principals of the 4 other academies in the Trust and spoke to a range of external partners who were commissioned by UCAT to help drive improvement.


Welcome
Home
Contact
CodePen Fun
See the Pen
classic pong game
by Tarah Perry (
@tarahform
) on
CodePen
.


Cars
Create a new entry
Reg
Make
Model
Price
Update
Delete
191 Mo 123
Ford
Modeo
25000
Update
Delete
12 G 123
Fiat
Punto
12
Update
Delete
05 D 123
Nissan
Almera
500
Update
Delete
Create a
Update
car entry
Reg
Make
Ford
Fiat
Nissan
Model
Price
Create
Update


Monk: "If I have nothing in my mind, what shall I do?"
Joshu: "Throw it out."
Monk: "But if there is nothing, how can I throw it out?"
Joshu: "Well, then carry it out."
(Zen koan)
(c) Software Lab. Alexander Burger
Because other Lisps are not the way I'd like them to be. They concentrate on efficient compilation, and lost the one-to-one relationship of language and virtual machine of an interpreted system, gave up power and flexibility, and impose unnecessary limitations on the freedom of the programmer. Other reasons are the case-insensitivity and complexity of current Lisp systems.
PicoLisp is for programmers who want to control their programming environment, at all levels, from the application domain down to the bare metal, who want to use a transparent and simple - yet universal - programming model, and who want to know exactly what is going on.
It does not pretend to be easy to learn. There are already plenty of languages that do so. It is not for people who don't care what's under the hood, who just want to get their application running. They are better served with some standard, "safe" black-box, which may be easier to learn, and which allegedly better protects them from their own mistakes.
PicoLisp is easy to understand and adapt. There is no compiler enforcing special rules, and the interpreter is simple and straightforward. There are only three data types: Numbers, symbols and lists ("LISP" means "List-, Integer- and Symbol Processing" after all ;-). The memory footprint is minimal, and the tarball size of the whole system is just a few hundred kilobytes.
Most other systems define the language, and leave it up to the implementation to follow the specifications. Therefore, language designers try to be as abstract and general as possible, leaving many questions and ambiguities to the users of the language.
PicoLisp does the opposite. Initially, only the single-cell data structure was defined, and then the structure of numbers, symbols and lists as they are composed of these cells. Everything else in the whole system follows from these axioms. This is documented in the chapter about The PicoLisp Machine in the reference manual.
There is only one symbolic data type, no distinction (confusion) between symbols, strings, variables, special variables and identifiers.
Most data-manipulation functions operate on the values of symbols as well as the CARs of cons pairs:
: (let (N 7 L (7 7 7)) (inc 'N) (inc (cdr L)) (cons N L))
-> (8 7 8 7)
There is only a single functional type, no "special forms". As there is no compiler, functions can be used instead of macros. No special "syntax" constructs are needed. This allows a completely orthogonal use of functions. For example, most other Lisps do not allow calls like
: (mapcar if '(T NIL T NIL) (1 2 3 4) (5 6 7 8))
-> (1 6 3 8)
PicoLisp has no such restrictions. It favors the principle of "Least Astonishment".
The OOP system is very powerful, because it is fully dynamic, yet extremely simple:
super
and extra
.
PicoLisp has many practical features not found in other Lisp dialects. Among them are:
'(1 2
3)
you can just write (1 2 3)
. This is possible because a
number never makes sense as a function name, and has to be checked at runtime
anyway.
quote
function returns all
unevaluated arguments, instead of just the first one. This is both faster
(quote
does not have to take the CAR of its argument list) and
smaller (a single cell instead of two). For example, 'A
expands to
(quote . A)
and '(A B C)
expands to (quote A B
C)
.
@
is automatically
maintained as a local variable, and set implicitly in certain flow- and
logic-functions. This makes it often unnecessary to allocate and assign local
variables.
var
locations (i.e. values of symbols and
CARs of cons pairs).
This
in combination with the access functions
=:
, :
and ::
.
link
, yoke
, chain
and made
functions in the make
environment.
(let ((A 1) (B 2) C 3) ..)
you write (let (A 1 B 2 C 3)
..)
, or just (let A 1 ..)
if there is only a single
variable.
#
) as a comment character is more appropriate
today, and allows a clean hash-bang (#!
) syntax for stand-alone
scripts.
select
can be used in database
queries.
Database objects ("external" symbols) are a primary data type in PicoLisp.
They look like normal symbols to the programmer, but are managed in the database
(fetched from, and stored to) automatically by the system. Symbol manipulation
functions like set
, put
or get
, the
garbage collector, and other parts of the interpreter know about them.
It is a stand-alone system (it does not depend on external programs like Apache or MySQL) and it provides a "live" user interface on the client side, with an application server session for each connected client. The GUI layout and behavior are described with S-expressions, generated dynamically at runtime, and interact directly with the database structures.
Internal exclusive and full use of UTF-8 encoding, and self-translating transient symbols (strings), make it easy to write country- and language-independent applications.
Despite the fact that PicoLisp is an interpreted-only system, the performance is quite good. Typical Lisp programs operating on list data structures are executed in (interpreted) PicoLisp at about the same speed as in (compiled) CMUCL, and about two or three times faster than in CLisp or Scheme48. Programs with lots of numeric calculations, however, may be slower on a 32-bit system, due to PicoLisp's somewhat inefficient implementation of numbers. The 64-bit version improved on that.
But in practice, speed was never a problem, even with the first versions of
PicoLisp in 1988 on a Mac II with a 12 MHz CPU. And certain things are cleaner
and easier to do in plain C
or asm
anyway. It is very
easy to write C
functions in PicoLisp, either in the kernel, as
shared object libraries, or even inline in the Lisp code.
PicoLisp is very space-effective. Other Lisp systems reserve heap space twice as much as needed, or use rather large internal structures to store cells and symbols. Each cell or minimal symbol in PicoLisp consists of only two pointers. No additional tags are stored, because they are implied in the pointer encodings. No gaps remain in the heap during allocation, as there are only objects of a single size. As a result, consing and garbage collection are very fast, and overall performance benefits from a better cache efficiency. Heap and stack grow automatically, and are limited only by hardware and operating system constraints.
It means to directly execute Lisp data as program code. No transformation to another representation of the code (e.g. compilation), and no structural modifications of these data, takes place.
Lisp data are the "real" things, like numbers, symbols and lists, which can
be directly handled by the system. They are not the textual
representation of these structures (which is outside the Lisp realm and taken
care of by the read
ing and print
ing interfaces).
The following example builds a function and immediately calls it with two arguments:
: ((list (list 'X 'Y) (list '* 'X 'Y)) 3 4)
-> 12
Note that no time is wasted to build up a lexical environment. Variable bindings take place dynamically during interpretation.
A PicoLisp function is able to inspect or modify itself while it is running (though this is rarely done in application programming). The following function modifies itself by incrementing the '0' in its body:
(de incMe ()
(do 8
(printsp 0)
(inc (cdadr (cdadr incMe))) ) )
: (incMe)
0 1 2 3 4 5 6 7 -> 8
: (incMe)
8 9 10 11 12 13 14 15 -> 16
Only an interpreted Lisp can fully support such "Equivalence of Code and Data". If executable pieces of data are used frequently, like in PicoLisp's dynamically generated GUI, a fast interpreter is preferable over any compiler.
No. That would contradict the idea of PicoLisp's simple virtual machine structure. A compiler transforms it to another (physical) machine, with the result that many assumptions about the machine's behavior won't hold any more. Besides that, PicoLisp primitive functions evaluate their arguments independently and are not suited for being called from compiled code. Finally, the gain in execution speed would probably not be worth the effort. Typical PicoLisp applications often use single-pass code which is loaded, executed and thrown away; a process that would be considerably slowed down by compilation.
Yes and No. Though we wrote and tested PicoLisp originally only on Linux, it now also runs on many other POSIX systems. The first versions were even fully portable between DOS, SCO-Unix and Macintosh systems. But today we have Linux. Linux itself is very portable, and you can get access to a Linux system almost everywhere. So why bother?
The GUI is completely platform independent (Browser), and in the age of the Internet an application server does not really need to be portable.
Not really, but it evolved a great deal into that direction.
Historically it was the other way round: We had a plain X11 GUI for our applications, and needed something platform independent. The solution was obvious: Browsers are installed virtually everywhere. So we developed a protocol which persuades a browser to function as a GUI front-end to our applications. This is much simpler than to develop a full-blown web server.
Because it isn't there. The reason is that it is redundant; it is equivalent
to the quote
function in any aspect, because there's no distinction
between code and data in PicoLisp, and quote
returns the whole
(unevaluated) argument list. If you insist on it, you can define your own
lambda
:
: (def 'lambda quote)
-> lambda
: ((lambda (X Y) (+ X Y)) 3 4)
-> 7
: (mapcar (lambda (X) (+ 1 X)) (1 2 3 4 5))
-> (2 3 4 5 6)
Dynamic binding is very powerful, because there is only one single, dynamically changing environment active all the time. This makes it possible (e.g. for program snippets, interspersed with application data and/or passed over the network) to access the whole application context, freely, yet in a dynamically controlled manner. And (shallow) dynamic binding is the fastest method for a Lisp interpreter.
Lexical binding is more limited by definition, because each environment is
deliberately restricted to the visible (textual) static scope within its
establishing form. Therefore, most Lisps with lexical binding introduce "special
variables" to support dynamic binding as well, and constructs like
labels
to extend the scope of variables beyond a single function.
In PicoLisp, function definitions are normal symbol values. They can be dynamically rebound like other variables. As a useful real-world example, take this little gem:
(de recur recurse
(run (cdr recurse)) )
It implements anonymous recursion, by defining recur
statically
and recurse
dynamically. Usually it is very cumbersome to think up
a name for a function (like the following one) which is used only in a single
place. But with recur
and recurse
you can simply
write:
: (mapcar
'((N)
(recur (N)
(if (=0 N)
1
(* N (recurse (- N 1))) ) ) )
(1 2 3 4 5 6 7 8) )
-> (1 2 6 24<PHONE_NUMBER> 40320)
Needless to say, the call to recurse
does not have to reside in
the same function as the corresponding recur
. Can you implement
anonymous recursion so elegantly with lexical binding?
You mean the funarg problem, or problems that arise when a variable might be bound to itself? For that reason we have a convention in PicoLisp to use transient symbols (instead of internal symbols)
This is a form of lexical scoping - though we still have dynamic
binding - of symbols, similar to the static
keyword in
C
.
In fact, these problems are a real threat, and may lead to mysterious bugs (other Lisps have similar problems, e.g. with symbol capture in macros). They can be avoided, however, when the above conventions are observed. As an example, consider a function which doubles the value in a variable:
(de double (Var)
(set Var (* 2 (val Var))) )
This works fine, as long as we call it as (double 'X)
, but will
break if we call it as (double 'Var)
. Therefore, the correct
implementation of double
should be:
(de double ("Var")
(set "Var" (* 2 (val "Var"))) )
If double
is defined that way in a separate source file, and/or
isolated via the ====
function, then
the symbol Var
is locked into a private lexical context
and cannot conflict with other symbols.
Admittedly, there are two disadvantages with this solution:
This is not true. Closures are a matter of scope, not of binding.
For a closure it is necessary to build and maintain a separate environment. In a system with lexical bindings, this has to be done at each function call, and for compiled code it is the most efficient strategy anyway, because it is done once by the compiler, and can then be accessed as stack frames at runtime.
For an interpreter, however, this is quite an overhead. So it should not be done automatically at each and every function invocation, but only if needed.
You have several options in PicoLisp. For simple cases, you can take
advantage of the static scope of transient
symbols. For the general case, PicoLisp has built-in functions like bind
or job
, which dynamically manage statically scoped
environments.
Environments are first-class objects in PicoLisp, more flexible than hard-coded closures, because they can be created and manipulated independently from the code.
As an example, consider a currying function:
(de curry Args
(list (car Args)
(list 'list
(lit (cadr Args))
(list 'cons ''job
(list 'cons
(list 'lit (list 'env (lit (car Args))))
(lit (cddr Args)) ) ) ) ) )
When called, it returns a function-building function which may be applied to some argument:
: ((curry (X) (N) (* X N)) 3)
-> ((N) (job '((X . 3)) (* X N)))
or used as:
: (((curry (X) (N) (* X N)) 3) 4)
-> 12
In other cases, you are free to choose a shorter and faster solution. If (as in the example above) the curried argument is known to be immutable:
(de curry Args
(list
(cadr Args)
(list 'fill
(lit (cons (car Args) (cddr Args)))
(lit (cadr Args)) ) ) )
Then the function built above will just be:
: ((curry (X) (N) (* X N)) 3)
-> ((X) (* X 3))
In that case, the "environment build-up" is reduced by a simple (lexical) constant substitution with zero runtime overhead.
Note that the actual curry
function is simpler and more pragmatic. It combines both strategies (to use
job
, or to substitute), deciding at runtime what kind of function
to build.
Yes, there is a macro mechanism in PicoLisp, to build and immediately execute a list of expressions. But it is seldom used. Macros are a kludge. Most things where you need macros in other Lisps are directly expressible as functions in PicoLisp, which (as opposed to macros) can be applied, passed around, and debugged.
For example, Common Lisp's DO*
macro, written as a function:
(de do* "Args"
(bind (mapcar car (car "Args"))
(for "A" (car "Args")
(set (car "A") (eval (cadr "A"))) )
(until (eval (caadr "Args"))
(run (cddr "Args"))
(for "A" (car "Args")
(and (cddr "A") (set (car "A") (run @))) ) )
(run (cdadr "Args")) ) )
This is not possible. Threads share memory and other resources (as opposed to processes, which are better isolated from each other). Each thread has its own stack for private data, but PicoLisp uses dynamic binding, where the stack holds the saved values instead of the current values of symbols. As a result, each running thread would overwrite the symbol bindings of other threads.
Instead, PicoLisp uses separate processes - and interprocess communication - for parallel execution, or coroutines as a kind of cooperative threads running a controlled way and doing all necessary housekeeping.
Another advantage of separate processes over threads: They can be distributed across multiple machines, and therefore scale better.
Because PicoLisp has something better: Transient symbols. They look and behave like strings in any respect, but are nevertheless true symbols, with a value and a property list.
This leads to interesting opportunities. The value, for example, can point to other data that represent the string's translation. This is used extensively for localization. When a program calls
(prinl "Good morning!")
then changing the value of the symbol "Good morning!"
to its
translation will change the program's output at runtime.
Transient symbols are also quite memory-conservative. As they are stored in normal heap cells, no additional overhead for memory management is induced. The cell holds the symbol's value in its CDR, and the tail in its CAR. If the string is not longer than 7 bytes, it fits (on the 64-bit version) completely into the tail, and a single cell suffices. Up to 15 bytes take up two cells, 23 bytes three etc., so that long strings are not very efficient (needing twice the memory on the average), but this disadvantage is made up by simplicity and uniformity. And lots of extremely long strings are not the common case, as they are split up anyway during processing, and stored as plain byte sequences in external files and databases.
Because transient symbols are temporarily interned (while load
ing the current source file), they are
shared within the same source and occupy that space only once, even if they
occur multiple times within the same file.
PicoLisp has no array or vector data type. Instead, lists must be used for any type of sequentially arranged data.
We believe that arrays are usually overrated. Textbook wisdom tells that they have a constant access time O(1) when the index is known. Many other operations like splits or insertions are rather expensive. Access with a known (numeric) index is not really typical for Lisp, and even then the advantage of an array is significant only if it is relatively long. Holding lots of data in long arrays, however, smells quite like a program design error, and we suspect that often more structured representations like trees or interconnected objects would be better.
In practice, most arrays are rather short, or the program can be designed in such a way that long arrays (or at least an indexed access) are avoided.
Using lists, on the other hand, has advantages. We have so many concerted functions that uniformly operate on lists. There is no separate data type that has to be handled by the interpreter, garbage collector, I/O, database and so on. Lists can be made circular. And lists don't cause memory fragmentation.
PicoLisp does not support real floating point numbers. You can do all kinds
of floating point calculations by calling existing library functions via
native
, inline-C code, and/or by
loading the<EMAIL_ADDRESS>library.
But PicoLisp has something even (arguably) better: Scaled fixpoint numbers, with unlimited precision.
The reasons for this design decision are manifold. Floating point numbers smack of imperfection, they don't give "exact" results, have limited precision and range, and require an extra data type. It is hard to understand what really goes on (How many digits of precision do we have today? Are perhaps 10-byte floats used for intermediate results? How does rounding behave?).
For fixpoint support, the system must handle just integer arithmetic, I/O and string conversions. The rest is under programmer's control and responsibility (the essence of PicoLisp).
Carefully scaled fixpoint calculations can do anything floating point can do.
That's not a good idea. The next time that function gets executed within the dynamic context the system may crash. Therefore we have a convention to use an upper case first letter for locally bound symbols:
(de findCar (Car List)
(when (member Car (cdr List))
(list Car (car List)) ) )
;-)
At least it should be interesting. It would be a machine executing list (tree) structures instead of linear instruction sequences. "Instruction prefetch" would look down the CAR- and CDR-chains, and perhaps need only a single cache for both data and instructions.
Primitive functions like set
, val
, if
and while
, which are written in C
or assembly language
now, would be implemented in microcode. Plus a few I/O functions for hardware
access. EVAL
itself would be a microcode subroutine.
Only a single heap and a single stack is needed.  Heap compaction is trivial due to the single cell size.
There would be no assembly-language. The lowest level (above the hardware and microcode levels) are s-expressions: The machine language is Lisp.
It is easy to produce a segfault in PicoLisp. Just set a symbol to a value which is not a function, and call it:
: (setq foo 1)
-> 1
: (foo)
Segmentation fault
There is another example in the Evaluation section of the reference manual.
PicoLisp is a pragmatic language. It doesn't check at runtime for all possible error conditions which won't occur during normal usage. Such errors are usually detected quickly at the first test run, and checking for them after that would just produce runtime overhead.
Catching the segmentation violation and bus fault signals is also not a good idea, because the Lisp heap is most probably be damaged afterwards, possibly creating further havoc if execution continues.
It is recommended to inspect the code periodically with lint
. It will detect many potential errors.
And, most of these errors are avoided by following the PicoLisp naming conventions.
The best place is the PicoLisp Mailing List (see also The Mail Archive and Gmane.org), or the IRC #picolisp channel on FreeNode.net.


I am Shashanka Shekhar Nayak. I am a Full Stack web Developer with MEAN stack based in Bangalore, India. I am graduate completed B.Tech. in Computer Sceince Engineering at Veer Surendra Sai University of Technology, Burla, Odisha and perceived Corporate Full Stack Web Developer training at WebStack Academy,Bangalore. Also enhancing knowledge and building designing & developement capabilities through day-to-day project experiences.
My passion in development with great ability of revolve ideas into design which communicates in a creative way. Each design created inspires & helps to achieve my goals as well as customer needs..
Web development is the coding or programming that enables website functionality, per the owner's requirements. It mainly deals with the non-design aspect of building websites. Web development ranges from creating plain text pages to complex web-based applications, social network applications and electronic business applications.
Web design encompasses many different skills and disciplines in the production and maintenance of websites. The different areas of web design include web graphic design; interface design; authoring, including standardised code and proprietary software; user experience design; and search engine optimization.
Photography is the art, application and practice of creating durable images by recording light or other electromagnetic radiation, either electronically by means of an image sensor, or chemically by means of a light-sensitive material such as photographic film.
Digital marketing is the use of the internet, mobile devices, social media, search engines, display advertising and other channels to reach consumers. As a subset of traditional marketing, digital marketing goes beyond the internet to include Short Message Service (SMS), search engine optimization (SEO), electronic or interactive billboards and other online ads (such as banner ads) to promote products and services.
Our portfolio is the best way to show our work, you can see here a big range of our work. Check them all and you will find what you are looking for.
If you wanna get in touch, talk to me about a project collaboration or just say hi, fill up the awesome form below or send an email to<EMAIL_ADDRESS>and let's talk.


Here in the Northwest, seafood dishes are so popluar and well known for its varieties. At last, Pat had brought those delicious salmon into our daily brekfast in a tasty cookies. Yes, you may have doubts about eating salmon for breakfast, but until you try these you are missing out.


--- layout: article title: Blog features date: 2015-04-09 19:13:03.000000000 -05:00 categories: [] tags: - A curious crossbreed status: publish type: post published: true meta: _publicize_pending: '1' _rest_api_published: '1' _rest_api_client_id: "-1" excerpt: ---
If you notice, the menu bar has expanded and grown a bit today. I decided to develop this blog a little more and fashion a space that would do more than simply record blog posts. I wanted to create a space where I could showcase my work and gather educational resources I find informative. The new pages include:
About - A little about myself
Web Projects - I didn't have time to get to this today, but will include quick summaries of the various web applications I design along with links to their GitHub repositories
Miscellaneous Projects - Summaries and links to projects outside the realm of web development I have designed
Resources - A compilation of tutorials, podcasts and articles I find informative during this learning period


Intelligent Control of Robot Manipulators
Introduction
Designing high-performance and low-cost robot manipulators is one of the ultimate challenges for engineers today. Key performance criteria for these robots are: 1) speed, 2) accuracy and repeatability, 3) vibration suppression, and 4) cost. In striving to meet these increasingly stringent performance goals, a mechatronic approach, which combines aspects< from both mechanical hardware and servo soware, is required. This research focuseson learning control, vision sensing dynamics compensation, kinematic visual servoing, and automatic sensor frame identication. The project utilizes an integrated analytical, simulation, and experimental eort to aain the objectives.
Experimental Setup
|
FANUC M-16iB robot system |
Single joint indirect drive robot setup |
Research Topics
Iterative Learning Control
Vision Sensing Dynamics Compensation (VSDC)
Kinematic Visual Servoing
Automatic Sensor Frame Identication
Additional Accomplishments to Date
1. Sensor Development and Sensor Fusion
To better measure and/or estimate the desired robot states in the mismatched robotic systems, a fast and precise position measurement device called PSD camera was developed in [4], and several dynamic and/or kinematic model based sensor fusion methods were developed in [1-6] to integrate the multiple sensor signals from both the motor side and the load side.
2. Automatic Gain Tuning
In order to expedite the gain tuning/validation process, automatic gain tuning methods based on extremum seeking control algorithm [7] or iterative feedback tuning scheme [8] were investigated.
3. Optimal Trajectory Planning
Without proper compensation, highly accelerating/decelerating motions may induce undesirable vibrations. Thus, a time optimal approach was proposed in [9, 10] to plan the robot trajectory such that it achieves accurate positioning while suppressing residual vibrations.
4. Vibration Suppression and Friction Compensation
Other more specic control objectives such as vibration suppression and friction compensation were also studied for the robotic systems with indirect drive mechanisms in [11-13].
Recent Key Publications
- W. Chen, and M. Tomizuka, "Direct Joint Space State Estimation in Robots with Multiple Elastic Joints," IEEE Transactions on Mechatronics, 2013, DOI: 10.1109/TMECH.2013.2255308
- W. Chen, and M. Tomizuka, "Comparative Study on State Estimation in Elastic Joints," Asian Journal of Control, Vol. 16, No. 3, pp. 1-12, May 2014
- W. Chen, and M. Tomizuka, "Load Side State Estimation in Robot with Joint Elasticity," in Proceedings of the 2012 IEEE/ASME International Conference on Advanced Intelligent Mechatronics (AIM), pp. 598-603, July 11-14, 2012
- C. Wang, W. Chen, and M. Tomizuka, "Robot End-eector Sensing with Position Sensitive Detector and Inertial Sensors," in Proceedings of the 2012 IEEE International Conference on Robotics and Automation (ICRA), pp. 5252-5257, 2012
- W. Chen, and M. Tomizuka, "Estimation of Load Side Position in Indirect Drive Robots by Sensor Fusion and Kalman Filtering," in Proceedings of the 2010 American Control Conference (ACC), pp. 6852-6857, June 30-July 2, 2010
- S. Jeon, M. Tomizuka, and T. Katou, "Kinematic Kalman Filter (KKF) for Robot End-Eector Sensing," ASME Journal of Dynamic Systems, Measurement and Control, Vol. 131, Iss. 2, February 2009 (2010 Rudolf Kalman Best Paper Award)
- M. Chan, K. Kong, and M. Tomizuka, "Automatic Controller Gain Tuning of a Multiple Joint Robot Based on Modied Extremum Seeking Control," in Proceedings of the 18th IFAC World Congress, pp. 4131-4136, 2011
- C-C. Wang and M. Tomizuka, "Sensor-based controller tuning of indirect drive trains," in Proceedings of the10th IEEE International Workshop on Advanced Motion Control, pp.188-193, 26-28 March 2008
- P. Reynoso-Mora, W. Chen, and M. Tomizuka, "On the Time-optimal Trajectory Planning and Control of Robotic Manipulators Along Predened Paths," in Proceedings of the 2013 American Control Conference (ACC), Washington, DC, June 17-19, 2013
- P. Reynoso-Mora, and M. Tomizuka, "LQ-Based Trajectory Tracking of Robotic Manipulators With "Near" Dynamically Feasible Time-Optimal Trajectory," in Proceedings of the 2012 ASME International Symposium on Flexible Automation (ISFA), paper No. ISFA2012-7271, 2012 (Best Theory Paper Award)
- W. Chen, K. Kong, and M. Tomizuka, "Hybrid Adaptive Friction Compensation of Indirect Drive Trains," in Proceedings of the 2009 ASME Dynamic Systems and Control Conference (DSCC), pp. 313-320, October 12-14, 2009
- C-H. Han, C-C. Wang, and M. Tomizuka, "Suppression of vibration due to transmission error of harmonic drives using peak filter with acceleration feedback," in Proceedings of the 10th IEEE International Workshop on Advanced Motion Control, pp.182-187, 26-28 March 2008
- S. Jeon and M. Tomizuka, "Stability of Controlled Mechanical Systems with Ideal Coulomb Friction," ASME Journal of Dynamic Systems, Measurement, and Control, vol. 130, no. 1, January, 2008
Researchers
| Wenjie Chen | Postdoctoral researcher | Homepage | |
| Pedro Reynoso-Mora | Graduate student | ||
| Michael Chan | Graduate student | ||
| Cong Wang | Graduate student | ||
| Chung-Yen Lin | Graduate student | ||
| Ernesto Solanes | Visiting scholar | ||
| Recent graduates: | |||
| Chenghuei Han | GE Research, Germany | ||
| Chun-Chih Wang | Formfactor | ||
| Soo Jeon | University of Waterloo, Canada |