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.

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.

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).