Matrix Languages Head to Head

If you're new to the matrix language world, you may wonder why people in math, engineering and science flock to such languages. The concepts offered by matrix languages are discussed at Why Matrix Languages. Basically there is a desire to handle numbers on a computer easily, yet with speed. Easily tends to mean with a language that doesn't require you to do the old edit, compile, link, and run sequence. Interpretive languages avoid all that, so programming with them is much easier and code can be developed much faster. You just write code and execute.

The potential problem with interpretive languages is lack of speed. It takes much longer for an interpretive language to process large amounts of data, especially if a lot of looping is involved. The solution that matrix languages offer is speed. They accomplish that by having compiled routines that can process large matrices of data very quickly. In that way, the looping is down in the heart of compiled functions.

There are two trade-offs to matrix languages. One is that you must learn to vectorize your solutions so that you do little to no looping within your programs. That means you must learn to express your solutions as matrix equations. The other limitation is that in order to do this speed magic, matrix languages must potentially hold large amounts of data in memory. One nice thing is that modern computers tend to have huge amounts of memory, making matrix languages very useful and popular.

Here's a vectorize example. The first table shows a program to create one constant random vector and a large number of additional vectors to be dotted (dot product) to the constant vector. The program prints out the result on each 50000th cycle. The first language listing may look strange. It's a Forth like tool I wrote years ago before computers were big enough to run matrix languages effectively. The program is interpretive, working on a record of data at a time, and writing out the result as each record is processed. No big memory needed, and no compilation either. The catch with this utility? It uses a Reverse Polish Notation (rpn) language.

Non Vectorized Solution in Forth Like Language

Though the language is likely unfamiliar, the concept is clear. Create a constant vector, then in a loop, produce a new random vector and dot product the constant vector with the new one. On a specified count, print results to the screen. In this cryptic language, the . means print. Each command has to be re-interpreted on each loop. Even though the language does a pseudo-compile to speed things up, it still can't keep up with a compiled program. But it is very easy to code and run, and is about as fast as a modern spreadsheet.

Here's a vectorized solution for the Euler Toolbox program:

Euler Toolbox Vectorized Solution

Note that there are no explicit loops in the vectorized version. The number of random vectors needed are generated with a single statement. All dot products are produced with a single statement. The indices of the output values is generated in single statement. Just referencing the resulting vector (z) with the index variable and no trailing semi-colon lists every 50000th result.

Get the idea? To vectorize, you create matrices of results with matrix operators and matrix equations. There may be no loops in the program at all. The result is a program that runs very fast.

Decide on Your Criteria

I've worked with all of the languages compared in this article in the past, with the exception of the Euler Toolbox. I'd played with it before, but I thought I needed to take on a couple of bigger projects to get more familiar with it. One of the programs I wrote in the Euler Toolbox was a new look at an old Yorick program. The Yorick program is one I've used to process lunar and planetary images taken with some of my telescopes and my Celestron NexImage astro-camera. Some examples of processed images can be viewed at ETX Astro Photos.

The camera is a web cam modified for astro-photography use. It slides into the focuser of a telescope, replacing the eyepiece. It produces avi movie files of my selected targets. My goal is to align and correlate each successive frame with the first frame of a target movie, and ultimately average all the acceptable (chosen by correlation) frames together to produce an image free of web cam pixelization, and mostly free of atmospheric distortion. In matrix language programming, the result isn't a big program in lines of code, but a program that gives the languages lots of work to do, as correlating images takes a lot of mathematical processing.

I don't believe any of the matrix programs I use can read avi movie files directly. To solve that problem I used the Linux mplayer program to split out each frame of the movie to a pnm image file. The pnm family of file structures are very simple formats that some of the matrix languages could already read, and is easy to code in the languages that lack a pnm reader.

The old Yorick program is an early prototype, and as I experimented and tuned my solution, the code became pretty unreadable. But the concept that evolved is simple enough, so I wrote the Euler version from scratch, taking advantage of all that I'd learned in making the prototype. The result is a program of much cleaner code, and it produces images every bit as good as the ones produced by the old Yorick program.

Since the program isn't too big in the sense of lines of code, and does employ quite a bit of file i/o as well as math calculations, I thought it would make a good exercise for programming again in the other matrix languages I have available. In addition, it seemed that it would provide a pretty good benchmark for comparing the languages.

The exercise also proved that though each of these languages has some emphasis that makes it most suitable for certain problems, all of the languages are good for general purpose work. In two of the languages, Euler Toolbox and Octave, I did have to write routines to handle image files, but otherwise all languages had the features that could be packaged to do what I needed. Though I haven't looked, I suspect that I could have found image file i/o routines for Octave.

The Benchmark Program

The goal of the benchmark program is to improve a single image, say of the moon, like this:

You might think you could just use a photo manipulation program like Gimp to sharpen the raw image, but that doesn't work. Even just a small amount of sharpening on a single image will produce terrible pixel noise as shown below.

But if a few dozen images are aligned and averaged together, the graininess goes away, and sharpening produces images that reveal the detail nearly down to the resolution of the particular telescope.

The Benchmark Results

The much cleaner Euler Toolbox program was translated into the PDL language, the R language, the Yorick language, the Octave language. and the Scilab language. In the benchmark test, each program processed 154 images of Jupiter, taken with my NexStar 5SE and the Celestron NexImage camera. Each image (frame) was 640x480 pixels. Each image was aligned with the first image, and a correlation coefficient calculated as to correlation with the 1st image. Then each program used a correlation criteria to select images to combine into a final output. It's possible that I didn't use each language's optimal way of solving the problem, but I did solve it the same way in each. The table below shows the time required for each program to do the required operations.

The Yorick Ratio column shows the ratio of each language's time to the Yorick solution time, which was the fastest. So Octave, for example, took 2.4 times a long to solve this particular problem than did Yorick.

I've typically found this type of speed result to be true. Yorick often outperforms the other languages on the types of problems I work on, though just doing specific matrix tests sometimes doesn't reveal that. I was pleasantly surprised to find that the old GTK Linux version of the Euler Toolbox kept up well with the speed of the other languages. The difference in speed on this problem between the Euler Toolbox, R, and the PDL is quite insignificant.

Of course, this is just a single benchmark, but it includes file i/o, matrix math, and graphics. Certainly applying the languages to a different problem might yield different results. But if speed is something of a concern, this test might suggest the order in which you consider languages discussed here.

The bottom line is, for most problems there isn't a terribly significant speed difference between the languages tested. I suggest looking deeper to pick your language.

But whoa!. PDL variables are actually piddles or objects, and designated by a leading dollar sign. A leading ampersand (@) designates a variable as an array. See Review PDL for more information about the PDL's peculiar syntax

Matrix Multiply Two Matrices

Now things get interesting. Since most of the languages use a simple * as a scalar multiplier, how do they signify a matrix multiply? For Octave and Scilab, it's simple -- they just drop the leading dot. For Euler, dot is the multiply operator. And what's with Yorick and R? Here, the PDL actually does something simple, it uses x as the operator.

Scale Sub-matrix by Scaler

This operation doesn't vary so much, except for the PDL. You can see that some languages use parenthesis for matrix indices, and some use brackets. Some (Octave, Yorick, and PDL) have a *= operator which does both the multiply and the store. Scilab, Euler and R don't have that convenience.

But again, what's up with the PDL? This strange nomenclature is the result of the fact that PDL piddles aren't really matrices, but objects. So in some cases, simple math statements don't work. Even indexing into a piddle uses the interesting slice object function operator. In PDL there's also a dice operator. One speaks of slicing and dicing piddles, if that makes you interested. The odd nomenclature shown above for scaling a sub-matrix portion makes more sense if broken into two statements:

That looks a bit less confusing. First a handle into the sub-matrix is created, then that handle is scaled. The nomenclature in the previous comparison list shows how one can combined both PDL statements into a single statement. Also note that while all of the other languages index the 1st element of an array or matrix with value 1, PDL starts with 0. PDL also reverses the more common [row,col] indexing with [col,row], columns being the first index. Some people think of it as [x,y].

There are certainly more syntactical differences between the languages, but in general you'll find that Octave, Scilab, and Euler Toolbox nomenclature are similar to one another. They all declare functions similar to the Euler sample shown earlier. Yorick code looks very much like C code. R uses brackets like C, but the language constructs are different.

The most unique is the PDL. Since the matrix holding container is an object, not a matrix as in other languages, PDL leads to some quite strange operations. The strange syntax has some advantages, but isn't so easy to learn. Even with these simple examples, you can see that the PDL offers more than one way to manipulate things. More to learn, but more likely you'll find a form of expression that suits you.

You may have Octave available in your current Linux package installer. If not, try GNU Octave. If you happen to use Puppy Linux, try Slacko Archive for a package called mathslacko.sfs. A kind Puppy Linux user named Emil put together Gnuplot, Maxima, Octave, and R in an easy to use package for Slacko Puppy, and the documentation says that at least parts of it work in other versions.

Octave is the language of this selection that is most indicative of what I call The Linux way of thinking. By that I mean it makes the most of what's generally already available to augment its power. Rather than have an internally developed graphics pack, it uses Gnuplot, which is available on nearly every Linux system. Octave programs can easily be ran in batch mode using the same technique as with a BASH file, or any other shell scripting language. The first line of a typical Linux script file has what's called a bang statement which tells Linux what utility runs the script. It's called a bang statement because its second character is an exclamation point.

Here's a few examples of that concept:

In each of the above cases, the code following the bang statement would be interpreted by the indicated utility. None of the other languages integrate with Linux quite that simply, though Yorick comes close. Most, like the Yorick example, need not only the bang statement, but some additional parameters. Some also need some prep commands in the following code.

Octave basically works with 2 dimensional matrices. Functions can return one or more arguments. In addition, Octave has a list type container that can hold data of dissimilar size.

Octave is one of the most flexible in its support of file i/o. In addition to simple load and save functions for matrices, it has a decent complement of C style file functions, allowing the user to likely read and write nearly any file structure, ASCII or binary.

As mentioned before, Octave uses Gnuplot as it primary plotting utility. Gnuplot can produce 2d and 3d plots with considerable flexibility, and can also show images. The version I was using for this project (version 3.2.3) didn't give me the ability to use the mouse to select points on an image plot. It would do that on a line plot, but not an image plot. Since I needed that ability for this image processes task, I had my Octave program call an external program (PDL) to do this task, and get the results from the external utility.

The the user interface for most of these languages, including Octave, is bleak to some programmers. They present a blank screen within which you type commands. Of course, for all of them you can use an external editor to create programs. In octave you generally create what's called m files. One nice feature of Octave is that you can reference any m file function within an interactive session or within a program without explicitly loading it. Octave finds the functions if stored in the m file path. Most other languages require you to load the functions or libraries by specific command, either by hand or within functions that require them.

Scilab is another language considered reasonably compatible with the commercial language Matlab. Scilab was created by the French Institute for Research in Computer Science and Automation. If not already available in your package manager, you can get it at the Scilab Download site. It is designed to be a general purpose matrix language, with particular support for signal processing, statistics, and fluid dynamics. It includes full 2d and 3d graphics support.

Scilab also includes Xcos, which provides a graphical method of laying out dynamic process solutions, similar to a flowchart. It's very handy for engineers in some fields of endeavor.

Scilab doesn't just present, even in Linux, a blank screen ready for user input. Instead it includes a GUI, with a left side column showing contents of the current working directory, and a right side column with a variable browser and a command history window. In the largest column in the center of the screen is the command window for user input.

Though like Octave in many ways, Scilab doesn't auto-load functions when referenced, they must be loaded by the operator, or loaded explicitly within a function that needs them. So as with the other languages described here other than Octave (and PDL with the AutoLoader option), the general mode is to make library files than contain several functions, and load them when needed.

Scilab works with 2 dimensional matrices. Functions can return one or more arguments. It addition, Scilab has a list type container that can hold data of dissimilar size.

Scilab has many of the Octave style i/o functions, but they are named slightly differently, such as mopen to open a file instead of fopen. In fact, a number of functions common in name between Octave and Matlab have different names in Scilab. To help with that, Scilab includes a considerable number of help screens to give guidance on converting Matlab code to Scilab code, as well as tables which show which Scilab functions do what specific Matlab functions do. Needless to say, Scilab, while comparable in many ways, isn't as close syntactically to Matlab as is Octave.

I noticed that in working with Scilab, when it encounters a syntax error when loading a file, it specifies the line number of the error without counting any comment lines included in the code file. If several functions are in the same library file, the error line indicated is not from the beginning of the file, but from the beginning of the particular function with the error.

This makes coding difficult using an external editor. But Scilab includes a syntax color highlighting editor that counts lines the way the Scilab loader does. So it's better to use the Scilab editor to create code as it makes debugging easier.

My Puppy Linux version doesn't have the Euler Toolbox in its archive, so I got it from the Debian archive. Puppy Linux has a utility that can unpack a Debian deb file, and it installed easily. The GTK Linux version is also available at the Sourceforge GTK Euler Toolbox site. The Windows version is available at the Euler Math Toolbox site.

I consider Euler Matrix Toolbox (EMT) to be sort of an Octave Lite language. It works with two dimensional matrices as does Octave, but does not have a list type container (at least in Linux). It can, as does Octave, allow a function to return more than one argument, each can be a matrix, and each a different size.

EMT is not highly integrated into Linux, as is Octave. It is possible to run EMT programs in a batch mode, but the only arguments you can hand to EMT when starting it is the name of Euler function files. So a batch program needing operator input would have to get it from a file or ask the user for it.

EMT has far fewer file i/o features. It handles ASCII files very well. As to binary, it can only read and write byte and integer files, not floating point. So files from other languages must be converted to ASCII for EMT to use them.

Unlike all of the other languages, EMT does not provide a function for passing commands to the Linux system. There is a function named exec ostensibly for this purpose, but though documented, it is not functional in Linux. A solution I've used is to create a Linux pipe (fifo), and use a receiver program (I use a simple bash script) that listens to the pipe. Whatever comes to it from the pipe is handed to the system for execution. I then created a simple EMT function that takes a string argument and writes it to the pipe. This combination does what I expected the non-functional exec function to do.

EMT has little string support. One thing I needed for the test program was the ability to have an array of file names, one file name for each frame I wanted to process. It was possible to read the list of file names in as character arrays, and have a matrix of those, with each row holding the characters of a file name. A simple function to re-concatenate the characters into a string gave me the feature I needed. The Windows version of EMT has much more string support, including the capability of keeping strings in arrays.

EMT has a pretty solid collection of math functions built in, including general matrix manipulation, linear algebra, polynomial solutions, interval and exact solution functions, and statistical functions. It also includes an FFT utility.

What EMT has it spades is graphics capability. It can do 2d and very impressive 3d plots, as well as display images. It gave me the ability to interact with an image that I needed for the image processing program. EMT also uses one of the easiest to learn language syntaxes, with few arcane operators.

EMT also has, at least with respect to the other languages tested here, a unique notebook feature. All commands entered into the EMT window (as well as their outputs) can be saved as a notebook file. Comments can be inserted anywhere within this notebook before saving, to document the activity. The notebook files can be reloaded, and the cursor keys will step up and down through the commands, skipping over the command outputs, making it easy to run and/or modify and run previous commands.

The creator of EMT, Dr. Rene Grothmann, is a professor. He created EMT to use for mathematics instruction, and the notebook files are a wonderful tool for that purpose. I've found that they are also a handy tool for product development. I can reload a notebook and be quickly back at a project with all of the exploratory commands I used, and notes. Of course, the language is also fully capable of doing industrial work as well.

What I like especially about EMT is that it is quite a small and easy to install package. With some of the larger packages, it seems that when trying to install them into Linux flavors that don't have them already in their archives, you may spend a long time hunting down requirements. Less so with EMT.

Debian and some of its derivatives have Yorick available through their respective package managers. It's also available at the Yorick Homepage. I've successfully downloaded from there and found it easy to get working in Puppy Linux.

As with Octave, the Yorick screen interface is very simplistic. Yorick comes up with a blank screen, ready for the user to type instructions. In fact, Yorick doesn't even have history support to allow the user to up-arrow to previous commands. There is a utility commonly available in many Linux versions that can solve this problem. It's named rlwrap. You can use it with Yorick like this:

Rlwrap runs Yorick, the interface looks the same, except now the interface provides a history function as well as a file name completion function.

The creator of Yorick is physicist David Munro, and Yorick reflects that in the collection of science applicable functions. Yorick does 2 dimensional matrices, but that's not the limit. It can go to 7 dimensions and perhaps beyond. That's why, by the way, that the Yorick matrix multiply operator looks so strange. When multiplying matrices of over 2 dimensions, there must be a way to specify what's actually to be multiplied.

While Octave and EMT primarily work with double precision floating point for all variables, Yorick has most of the data types available in C. You can have byte arrays, integer arrays, string arrays, and of course floating point arrays. This adds flexibility, but you must be careful that you know what type of variable you're doing arithmetic with. Dividing one integer variable into another integer value when you're thinking floating point may well give you the wrong answer.

Yorick functions can only return a single value. That can be a number, variable, matrix -- or a struct. The struct is useful if you need to return a collection of dissimilar things, as in C. The awkward thing is that the structs must be globally declared, but then can be used in functions. For example, to declare a struct to store 2 double precision matrices, which may be of different sizes,

will do the trick. This struct declaration must occur outside of any function declaration, but is then available for use within a function.

The struct capability makes Yorick quite flexible, but clearly having a bit of C programming in your background is a plus.

Yorick has integrated graphics functions, all with cryptic names, like pli, plt, plm, for plot x versus y, plot text, plot mesh. Strange names, but there are plenty of routines (this is just a sample), so Yorick is quite plot capable. It is likely that some help file searching will be necessary.

Its best to make libraries of related functions, as Yorick requires an include command for each library. The include commands can be part of Yorick programs, so the programs take care of themselves. Yorick is batchable, and like Octave, EMT, and PDL, all functionally in a batch file is preserved. That is, a batch file can interact with the user and present graphics.

R is another language that is very popular, and so is likely to be in many Linux package archives. If you can find it there, its likely the best way to install it. If not, you can get it at the Cran-R-Project. If you happen to use Slacko Puppy Linux, you can get the mathslacko.sfs file at ibiblio Slacko Packages.

Hopefully the few code snippets give you a flavor of R syntax. It uses brackets like C and Java, but is otherwise unique in it's expressions. In general, the matrix manipulation functions look and work like those of most any other matrix languages, other than the assignment operator used instead of an equals symbol.

In Linux, R also presents just a blank screen for user input. It does have built in history support. I believe the Windows version has a GUI interface.

R can have variables of almost any type, byte, integer, and float. It has conversion functions to convert from one to the other. As with the other languages that have such variable flexibility, you must be conscious of what type of variables you're doing math with. Dividing integers by integers may not give you what you expect.

R has a reasonable assortment of file i/o functions, and I've never ran across anything I couldn't read or write. The functions aren't as simply constructed as the C style i/o functions of Octave however. R i/o functions allow a number of options by name, which makes some calls a bit verbose. R can read and write both ASCII and binary files. A sample of reading an ASCII file follows:

Very flexible, but not easy to remember.

R, like Octave and PDL, has a large number of followers, and supplemental functions for all three languages are probably available to simplify your programming challenges. For example, there was a package for R that allowed me to use it to load image files for my project.

R is heavily loaded with statistical math routines, and is used a lot in the statistics field. I've used R for time series analysis and image processing as well, so it makes a good general purpose matrix language.

R has a plentiful assortment of 2d and 3d graphics routines, making it useful for generating plots of all manner. Like the i/o routines, the plot functions often have a lot of named options one can use to tailor a graph.

R can be ran in batch mode, but it's not as convenient as using Octave for that purpose. To the R developers, batch means batch. That is, R goes to a dark place and processes data, and writes it out to a file (or files). But in batch it does not communicate with user, and cannot present graphics as its running. That capability is only available from the interactive R environment.

If the PDL isn't already in your Linux distro, check out the CPAN site for how to install the PDL in your Linux system (you probably already have Perl). If PDL isn't in your Linux package manager, it may be challenging to get installed. It that event be sure you check out all of the module requirements of the PDL and be sure you have them installed before attempting to install PDL. Then you will be ready to install PDL. If not already in your archive, the easiest way (assuming you've installed all of the PDL requirements, is to use the cpan command. This command directly gets the code from the CPAN site, compiles it and installs it. The CPAN site also provides access to countless supplemental packages to further enhance the PDL. Usually it can be installed as follows:

After entering this command, go grab a soda or cup of coffee, sit back, and relax. It will likely take awhile.

PDL provides a user interface utility called perldl. Perldl, like most of the other Linux matrix languages, presents a blank screen ready for user typing. The basic perldl doesn't have history support, but that's available with an additional PDL extension. You can, as I do, just run perldl with rlwrap as described in the Yorick section.

You can also use the cpan directive, likely already in your system, to install the ReadLine supplement to PDL, giving it a history function. Just do the following:

PDL doesn't auto-load referenced functions in its basic form. You must put loading commands (the use command) in library files so that they'll have the functions they need. There is a PDL module named AutoLoader that you can use, or even have always loaded by default by editing the .perldlrc file. With this enhancement, PDL, like Octave, will auto-load functions when they are referenced. This works for individual function files, but libraries will still need to be loaded by use commands.

PDL is also a language that can work with variables of many different types. There are bytes, integers, strings, and floats. So the same precaution mentioned before applies to PDL, be sure you know what kind of variables you're doing math with.

Like Octave, PDL makes a lot of use of external utilities that already exist. One of the main plotting utilities used by PDL is PGPLOT, for example. Like Octave and R, PDL has a pretty large on-line repository of donated libraries, possibly helping you with your problem solving. And, like Octave, Perl (with PDL) is easily batchable. To run a Perl or PDL script in batch, make the first line:

#!/usr/bin/perl

As with a shell script, Perl can be ran with just the appropriate bang line, followed by the program. That's one of the things about Octave, Yorick, and Perl that I like most. I like to create programs that each do some particular thing to data, like transform it into another coordinate frame, or compute regression coefficients on the data and output results. Then in a shell script file I may run 2 or 3 scripts or programs in a row, each doing their magic, with the final one giving the result I am seeking. With this procedure, script languages can be mixed and matched to solve a problem, with each offering its best capability.

Note that while the .perdlrc file can be used to set what modules to autoload when perldl is used, batch executed files don't use the .perdlrc file. So a batch perl/pdl program will need to have all necessary use modules explicitly listed, including a use PDL; instruction.

Perl is also quite flexible in file i/o capability, but like R can be a bit of a struggle to get set up. ASCII i/o is pretty simple. Binary quite doable, but not so simple. If you use some kind of locally standard structure, you can set up your Perl routines and forget about them. If you have to fiddle with the structure of the i/o routines a lot, it can get tedious.

Perl is used a lot in the astronomy community for image processing work. There, the odd syntax is actually advantageous. For example, if you have a Perl piddle $x that contains an image,

doesn't do what you might expect. You may be thinking, as with other languages, that $y is a new data object composed of a sub-section of $x.

Wrong!

In the PDL nomenclature, $y is a handle to reference the sub-section of the $x piddle. Changing $y in some way will actually change that subsection of $x.

This ploy can make some image work very handy as well as saving memory. Odd though it looks, it can be advantageous. If you actually want a new matrix that is a subsection of the old one, not just a handle into it, use the copy operator:

In support of its imaging processing functionality, PDL includes the most comprehensive library of image file i/o functions. So if working with images is your desire, the PDL may be your best solution. Perl is also a language with a lot of variation is expression. If you like expressive freedom, again Perl and the PDL may be your best solution.

I've successfully used the PDL for time series processing, regression, and filtering, in addition to image processing. It, like the others, is well adapted for general purpose matrix processing problem solving.

There are couple of drawbacks to using Perl as your go-to matrix language. One is obvious from some of the code snippets -- there's likely some learning to do. The other is, while the PDL offers an interactive interface (perldl), it doesn't offer a development interface that's as handy for program creation and testing as some of the other languages.

With any of the others, you may work on code in one window, then in the matrix language window, reload and tryout functions by hand. A handy way to know that each function is doing what you expect.

With perldl, you can load your program and exercise portions of it, but you can't reload it. You have to get out of perldl and back in again to load your changes. Better than conventional programming, but not as handy as just being able to reload your code in place.

While that situation is true of libraries, it's not necessarily true if you use the AutoLoader extension and individual function files. You can set up your .perldlrc file to aways use AutoLoader, and to also set autoloading to always rescan for new code versions like this: $PDL::AutoLoader::Rescan=1, which makes PDL operate much like Octave. With this setup, you can modify a .pdl function file, similar to an Octave m file, and the next use of it in the perldl utility will reflect the changes.

Though a bit odd in ways, Perl with the PDL is probably the most flexible and far-reaching of matrix languages. Perl users know the term TIMTOWTDI, which means: There Is More Than One Way To Do It. That flexibility can take a bit of learning, but all you need is to pick among the flexible nomenclature that fits your style, and never look back.