The Yorick Programming Language
Linux leverages a vast amount of academic software, either easy ports of existing UNIX packages or, increasingly in recent years, software that is ready to run under Linux. One example is Yorick, and this article is an attempt to provide a brief overview of the nature and capabilities of this system.
Yorick is not just another calculator. Readable syntax, array notation and powerful I/O and graphics capabilities make Yorick a favorite tool for scientific numerical analysis. Machine-independent I/O, using the standard NetCDF file formats, simplifies moving applications between hardware architectures. Yorick is an interpreted language developed by David H. Munro at Livermore Labs. Implemented in C, it is freely distributed under a liberal copyright. Yorick runs on a vast range of machines, from 486SX Linux Laptops (in my case) to Cray YMP supercomputers.
Who uses Yorick? The majority of users are physicists, many with access to the most powerful computers in the world. Specific applications include Astrophysics, Astronomy, Neurosciences, Medical Image Processing and Fusion Research.
In this article I will discuss the basics of running Yorick, describe the key array operations, and briefly discuss array operations, programming and graphics. I hope that this quick look is enough to get the more mathematically inclined readers to give Yorick a try.
When invoked without arguments, Yorick presents a typical command-line interface. Expressions are evaluated immediately, and the result is displayed. Primitive types include integers, floating-point values and strings. All the built-in functions and constants you would expect to be present are present. Variable names are unadorned, with no leading $ character and need not be pre-declared. C-style comments are supported.
One might not expect an interpreted language to be suitable for numerical analysis, and indeed, this would be the case if arrays were not built into the language. Arrays are first-class objects that can be operated on with a single operation. Since the virtual machine understands arrays, it can apply optimized compiled subroutines to array operations, eliminating the speed penalty of the interpreter.
Arrays can be created explicitly:
> a1 = [1.1, 1.2, 1.3, 1.4, 1.5]
Elements can be accessed singly or as a subset, with 1 being the origin. Parentheses indicate the indexing operation, and a single index or a range of indices can be specified.
> a1 [1.1,1.2,1.3,1.4,1.5] > a1(2) 1.2 > a1(1:3) [1.1,1.2,1.3]Since array operations are built into the language, functions applied to the array are automatically applied to all elements at once.
> sqrt(a1) [1.04881,1.09545,1.14018,1.18322,1,2.23607]Arrays are not limited in dimension. The rank (number of indices) of an array is not limited to one (a vector) or two (a matrix), but can be as large as desired. Arrays of rank 3 can be used to represent the distribution of a parameter across a volume, and an array of rank 4 could model this over time.
Yorick also provides a simple but effective help system. Executing the help command describes the help system. Executing it with a command name as an argument provides information on that command.
Yorick provides a complete programming language that closely matches C in terms of control flow, expressions and variable usage. For example, the statement:
> for(i=1; i<10; i++) { print,1<<i; }
will print the powers of two just as you would expect. Function declarations, introduced with func, also work as expected:
> func csc(x) {
> return 1/sin(x);
> }
There are differences—variables need not be declared, and arrays
are much more powerful than in C. The major difference is in
function invocation. Passing arguments to a function in parentheses
causes an evaluation and printing of the result; however, passing
arguments separated by commas simply executes the function and does
not return the result. Since in most cases intermediate results are
not required, many scripts contain function calls of the form f,x,y
rather than the more familiar f(x,y).
Having a programming language close to C allows easy migration between Yorick for prototyping and C for final implementation. However, as several Yorick users have indicated, moving to C is often unnecessary—the Yorick program proved to be fast enough to get the job done with a minimum of programming effort.
If C extensions are required, a straightforward framework allows extending the Yorick command language with whatever new operations are necessary.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.
Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.
Sponsored by ActiveState
| Non-Linux FOSS: libnotify, OS X Style | Jun 18, 2013 |
| Containers—Not Virtual Machines—Are the Future Cloud | Jun 17, 2013 |
| Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer | Jun 12, 2013 |
| Weechat, Irssi's Little Brother | Jun 11, 2013 |
| One Tail Just Isn't Enough | Jun 07, 2013 |
| Introduction to MapReduce with Hadoop on Linux | Jun 05, 2013 |
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- RSS Feeds
- Introduction to MapReduce with Hadoop on Linux
- Validate an E-Mail Address with PHP, the Right Way
- New Products
- Weechat, Irssi's Little Brother
- Tech Tip: Really Simple HTTP Server with Python
Featured Jobs
| Linux Systems Administrator | Houston and Austin, Texas | Host Gator |
| Senior Perl Developer | Austin, Texas | Host Gator |
| Technical Support Rep | Houston and Austin, Texas | Host Gator |
| UX Designer | Austin, Texas | Host Gator |
| Web & UI Developer (JavaScript & j Query) | Austin, Texas | Host Gator |
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




26 min 45 sec ago
27 min 45 sec ago
1 hour 12 min ago
2 hours 1 min ago
2 hours 25 min ago
4 hours 2 min ago
4 hours 3 min ago
5 hours 56 min ago
8 hours 46 min ago
13 hours 59 min ago