siunitx 2: more numbers, more tables, SVN?

The issue of input formats for siunitx and numbers has been mentioned. It seems every time I think I’ve sorted broadly what I need to do, other ideas come up. I’ve thought about scientific notation before, but haven’t had a go at coding anything. The idea of “compressing” error input such as 1.23\pm 0.02 into 1.23(2) was mentioned to me before, but that one slipped off my radar. I guess I should re-visit both of these areas and see what I can do. Of course, that will delay me with other things, but I’d really like siunitx 2 to cover a lot of things that version 1 does less well.

Tables have also been raised (again). I’ve had a quick look at pgfplotstable in the past, but I suppose I should read things in detail. I mention it a lot, but tables were not on the original “manifesto” for siunitx, and have rather crept up on me. It seems that this is a key area for users, and so I’ll also need to look at this area again. I’ve already said I need to work on more table ideas, so this is not really that much of a surprise. Over all, my aims in siunitx are probably slightly different to pgfplotstable, but I’ll see what I can learn.

All of this leads me to worrying about public information and releases. As a developer, I’d love to keep things simple for users, and only release working material. On the other hand, advanced users often provide good feedback well before things are done. I think I need some kind of public repository for the version 2 code, and as I currently use BerliOS for my LaTeX3 ideas, I’ll look at settings something up there over the weekend. They seem to be quite happy with the LPPL, which not every free open-source hosting service is.

Work on siunitx version 2

Progress on siunitx 2 was slower over Christmas than I’d hoped. However, I should still manage a first snap-shot of what I’m doing some time this month.

I’m working on three different targets at once:

  1. Making the existing code clearer. This means improving the internal naming of functions, making each section more independent of the others and trying to use some LaTeX3 ideas in the internal code. This is the fastest part of the job.
  2. Improving the efficiency of the current code. LaTeX3 has lots of good ideas about loops and expandable tests, and I’m using this to make the existing code more efficient. I’ve removed a lot of loops from the current number parsing system, which makes for a faster package. Once everything works properly, I’ll try to get some testing done on this to see what difference it makes.
  3. Adding new features. This is the slowest job, unsurprisingly. There are various things I’m still working out how to do with numbers, before I even look at some of the unit-based problems.

Each of the areas takes time, and and have other things to do as well! I’m still hoping to get something done in time for TeXlive 2009: it’s always best to have some kind of target.

Section numbers in achemso

When I wrote the achemso class for submissions to American Chemical Society journals, I did my best to get the style of each journal correct. Of course, this is not easy as there are a lot of journals and they are not necessarily consistent in applying the style rules! One issue that comes up a lot is section numbering. Most of the journals do not number sections, most of the time. However, sometimes authors want to include section numbers. I need to look at this again for version 3.2, but in version 3.1 you need to do:


somewhere in the preamble to restore numbering.

Choice options

As I work through recoding siunitx for version 2, I’m re-thinking all of the options. As I’ve said already (and others have said too) the current structure is too complex. A particular problem is the options which currently take a choice of values, or a literal item. I’m thinking that it would be better to either (a) have a fixed list of choices or (b) use the input as given. For example, the current:

\sisetup{decimalsymbol = comma}

could become either:

\sisetup{numbers/output/decimal marker = comma}


\sisetup{numbers/output/decimal marker = {,}}

For options which give literal output (like the above), I think the later method is better (it matches up with the input options, for example). On the other hand, some options (particularly those involving spaces) seem better done using keywords:

\sisetup{numbers/output/digit separator = thick space} % thin space, comma, ...

I’d be keen to see what others think.

Developement Timetables

The need to have public timetables for large projects is something I mention quite a bit on the LaTeX-L list. The LaTeX3 project has run for many years, and at the moment there is no public indication of when a “LaTeX3 kernel” might be available. As I’ve mentioned that I’m working on siunitx v2, I guess I’d be hypocritical if I didn’t have some kind of public statement about how things are going.

The plan at the moment is something like:

  • Christmas period. Re-code number output and tables.
  • January. Look at extending unit system to cope with more cases.
  • February. Additional items (such as awkward symbols). Write basic documentation for v2.
  • March. Public beta one for testing. Continue to write documentation
  • June. Depending on feedback and success, release siunitx v2.

As you can see, I’m hoping to get everyhting revised for TeXLive 2009, having learnt from getting siunitx v1 out. Of course, this is subject to change (and other committments), but I think it’s pretty achievable.

achemso v3.1

My achemso package (for submissions to the American Chemical Society) has been updated to v3.1. This brings two main developments. First, JACS Communications now automatically format in the journal style. This was asked for by the editorial office, and hopefully shows the approximate page requirement. Second, I’ve completely revised author affiliations. The original system was much too inflexible (just one main affiliation per author), and I’ve had a lot of questions about this. The new system gives you three macros:

  • \affiliation
  • \altaffiliation
  • \alsoaffiliation

The last one is new, and should enable pretty much any combination of different addresses.

Toward siunitx 2

My siunitx package has attracted a lot of attention, and I’ve had a lot of requests for new features. To get these working, I’m having to re-code the package from the ground up. There are lots of problems with the code as it stands, as it is cobbled together from the previous packages in many cases.

So far, I’ve recoded the system that parses numbers, taking out a lot of the loops and making it hopefully much faster. I’ve also got about half of the table system redone: this collects up the table contents in a more efficient (and intelligent) manner than the old code. The next step is to look at the output formatting system, where I have several ideas to make everything smoother.

One area that I’m keen to improve is the user options. The current system is too complex, so I’m looking at doing something tree-based. The options are all being divided into groups, which should make things easier to follow.

Another area for lots of attention is table output. This seems to be the thing that I get most questions about. Lots to work on there, but so far nothing is done. I need to look over all of the suggestions I’ve had and find a way to please everyone (not easy).