siunitx problem with error separation
t.m.tr...@gmail.com
in cases like this:
\num[seperr]{354.6(12)}
I also tried:
\num[seperr]{354.6(1.2)}
but this doesn't seem to be supported syntax (error about duplicated
decimal point).
I have the latest version 1.0l of the package.
Cheers,
Tomek
%----- minimal example -----%
\documentclass{minimal}
\usepackage{siunitx}
\begin{document}
\num[seperr]{354(12)} % this is OK
\num[seperr]{354.6(12)} % <- this fails
\num[seperr]{354.6(1.2)} % <- this fails as well
\num[seperr]{354.67(12)} % this is OK
\end{document}
Joseph Wright
Drat. That would be a bug (in the error-recycling code, I think).
Leave it with me. By the way
354.6(1.2) = 354.6 +- 0.12
which I don't think is intended! (I've never seen such usage.)
--
Joseph Wright
t.m.tr...@gmail.com
> Drat. That would be a bug (in the error-recycling code, I think).
> Leave it with me. By the way
>
> 354.6(1.2) = 354.6 +- 0.12
>
> which I don't think is intended! (I've never seen such usage.)
Indeed, that is not intended. I tried all the combinations in hope
that something will work.
Another problem. Can I use 'seperr' option in tables? If I do, I only
get error part displayed preceded with +-. I would like to format
numbers as 12.3 +- 0.4 and align them on +- sign. Is it possible?
Cheers,
Tomek
Joseph Wright
> Joseph Wright wrote:
>> Drat. That would be a bug (in the error-recycling code, I think).
>> Leave it with me. By the way
>>
>> 354.6(1.2) = 354.6 +- 0.12
>>
>> which I don't think is intended! (I've never seen such usage.)
>
> Indeed, that is not intended. I tried all the combinations in hope
> that something will work.
I was just (hopefully) showing why this is not supposed to work. of
course, 354.6(12) is *supposed* to!
> Another problem. Can I use 'seperr' option in tables? If I do, I only
> get error part displayed preceded with +-. I would like to format
> numbers as 12.3 +- 0.4 and align them on +- sign. Is it possible?
Not in v1.0, but I can think again for v1.1: currently the seperr option
is deliberately disabled inside tables. There is an example in the
documentation of how to do something like this, but "by hand" based on
something from the dcolumn documentation.
The problem I have is how to make an interface that makes sense on this
one. The S column is supposed to align on the decimal marker, and that
is how the options are written. So I'm worried that it might be
misleading to suddenly use the \pm symbol in tables for alignment.
There is also the issue of how much space to use for everything
(remember tabformat expects something like 3.1, for your example). I'd
need some clue for reserving error spaces in the column. How about:
tabseperr (Boolean)
taberrdigits (integer)
With tabseperr=false, nothing changes. With tabseperr on, taberrdigits
tells the package how much space to reserve for the error (with
tabformat still doing the space for the main number). The tabnumalign
setting then applies to the \pm sign when set to "centredecimal"
(perhaps renamed "centremarker"). Or is this too complicated?
It looks like v1.1 while be a little longer than expected (already lots
to do on it).
--
Joseph Wright
t.m.tr...@gmail.com
> t.m.tr...@gmail.com wrote:
> > Joseph Wright wrote:
> >> Drat. That would be a bug (in the error-recycling code, I think).
> >> Leave it with me. By the way
> >>
> >> 354.6(1.2) = 354.6 +- 0.12
> >>
> >> which I don't think is intended! (I've never seen such usage.)
> >
> > Indeed, that is not intended. I tried all the combinations in hope
> > that something will work.
>
> I was just (hopefully) showing why this is not supposed to work. of
> course, 354.6(12) is *supposed* to!
OK. For now, I will just use single digit errors.
> > Another problem. Can I use 'seperr' option in tables? If I do, I only
> > get error part displayed preceded with +-. I would like to format
> > numbers as 12.3 +- 0.4 and align them on +- sign. Is it possible?
>
> Not in v1.0, but I can think again for v1.1: currently the seperr option
> is deliberately disabled inside tables. There is an example in the
> documentation of how to do something like this, but "by hand" based on
> something from the dcolumn documentation.
I generate my tabular material from script, so I will make the changes
there and stick to the centered alignment for the time being. I have a
deadline tomorrow, so more sophisticated solutions will have to wait.
> The problem I have is how to make an interface that makes sense on this
> one. The S column is supposed to align on the decimal marker, and that
> is how the options are written. So I'm worried that it might be
> misleading to suddenly use the \pm symbol in tables for alignment.
There is already an option to align on exponents. Perhaps a similar
solution could be used for alignment on \pm.
> There is also the issue of how much space to use for everything
> (remember tabformat expects something like 3.1, for your example). I'd
> need some clue for reserving error spaces in the column. How about:
>
> tabseperr (Boolean)
> taberrdigits (integer)
>
> With tabseperr=false, nothing changes. With tabseperr on, taberrdigits
> tells the package how much space to reserve for the error (with
> tabformat still doing the space for the main number). The tabnumalign
> setting then applies to the \pm sign when set to "centredecimal"
> (perhaps renamed "centremarker"). Or is this too complicated?
I would have to think about it a little bit more. Designing good user
interface is not an easy task. I think I would rather format data and
error in two columns separated by \pm. Then each column could have its
own alignment independently. I will come back to you if I will have
some more specific ideas about the user interface. I need to get more
familiar with the current set of options first.
> It looks like v1.1 while be a little longer than expected (already lots
> to do on it).
The speed at which you improve this package is nothing short of
amazing already. I certainly don't mind waiting a little bit longer.
And thanks for all the great work you've done already.
Cheers,
Tomek
Joseph Wright
>> There is also the issue of how much space to use for everything
>> (remember tabformat expects something like 3.1, for your example). I'd
>> need some clue for reserving error spaces in the column. How about:
>>
>> tabseperr (Boolean)
>> taberrdigits (integer)
>>
>> With tabseperr=false, nothing changes. With tabseperr on, taberrdigits
>> tells the package how much space to reserve for the error (with
>> tabformat still doing the space for the main number). The tabnumalign
>> setting then applies to the \pm sign when set to "centredecimal"
>> (perhaps renamed "centremarker"). Or is this too complicated?
>
> I would have to think about it a little bit more. Designing good user
> interface is not an easy task. I think I would rather format data and
> error in two columns separated by \pm. Then each column could have its
> own alignment independently. I will come back to you if I will have
> some more specific ideas about the user interface. I need to get more
> familiar with the current set of options first.
>
Okay, I'll wait. I prefer using two columns, really. Hence the current
situation that seperr does not work in tables! You are quite right
about interface. I spend a lot of time on that.
> The speed at which you improve this package is nothing short of
> amazing already. I certainly don't mind waiting a little bit longer.
> And thanks for all the great work you've done already.
No problem. Remember I borrowed a lot of the code from other places!
--
Joseph Wright
t.m.tr...@gmail.com
wrote:
> t.m.trzec...@gmail.com wrote:
> >> There is also the issue of how much space to use for everything
> >> (remember tabformat expects something like 3.1, for your example). I'd
> >> need some clue for reserving error spaces in the column. How about:
>
> >> tabseperr (Boolean)
> >> taberrdigits (integer)
>
> >> With tabseperr=false, nothing changes. With tabseperr on, taberrdigits
> >> tells the package how much space to reserve for the error (with
> >> tabformat still doing the space for the main number). The tabnumalign
> >> setting then applies to the \pm sign when set to "centredecimal"
> >> (perhaps renamed "centremarker"). Or is this too complicated?
>
> > I would have to think about it a little bit more. Designing good user
> > interface is not an easy task. I think I would rather format data and
> > error in two columns separated by \pm. Then each column could have its
> > own alignment independently. I will come back to you if I will have
> > some more specific ideas about the user interface. I need to get more
> > familiar with the current set of options first.
>
> Okay, I'll wait. I prefer using two columns, really. Hence the current
> situation that seperr does not work in tables!
I tried to think of some good solution but I'm not sure if I can
suggest anything reasonable. The problem is that if you want to come
up with something more general, then you have to consider cases like
this:
case 1: (1.23 +- 0.04) x 10^5
or this:
case 2: 1.23 x 10^5 +- 0.04 x 10^5
How to proceed in the above cases? What alignment options should be
available in each of them? I really don't know.
I can think of two solutions.
Approach 1.
Let's make it general and low-level. Choosing an alignment symbol (one
of '.' 'x' '+-' but others could also be considered as well) would
mean that the formated material is split into columns at that symbol
and the symbol itself becomes the separator between those newly formed
columns. Then, in each of the columns any of the standard alignment
modes (left, right or center) would be possible. This would allow for
something like this (integer left- and fraction right-aligned):
other column | 1000. 1 | other column
other column | 1 .0001 | other column
This is of course a pure nonsense, but this generality could be useful
in some cases. Say, you want to align angles with degrees, minutes and
seconds (all right aligned):
other column | 10deg 10' 10" | other column
other column | 1deg 1' 1" | other column
With such a general approach this becomes possible (I'm not sure if
angles can be aligned like this atm).
Approach 2.
Let's forget about the generality and provide only solutions for the
most common cases. This makes it less flexible but also much more user
friendly. Only the combinations of alignment settings that we deem as
sensible would be provided as options.
Approach 1+2.
Let's use solution 1 and build 2 on top of it. That could work in a
similar way to styles in PGF. Low-level stuff would be still available
but for user's convenience the most common cases would be provided as
styles that set up the right combination of low-level settings.
Personally, my preference goes for the last of those solutions (1+2)
but that would probably mean a massive rewrite of the package,
especially that right now siunitx uses xkeyval and not pgfkeys for key
management. Therefore, I don't expect that you will be very keen on my
ideas but I would like to know what you think about it. I also hope
that some other people will join our discussion and share their
opinions on the subject.
Cheers,
Tomek
Joseph Wright
CTAN now: look for v1.0m.
Moving on to the other issue
> I tried to think of some good solution but I'm not sure if I can
> suggest anything reasonable. The problem is that if you want to come
> up with something more general, then you have to consider cases like
> this:
>
> case 1: (1.23 +- 0.04) x 10^5
>
> or this:
>
> case 2: 1.23 x 10^5 +- 0.04 x 10^5
>
> How to proceed in the above cases? What alignment options should be
> available in each of them? I really don't know.
This is always the issue if one tries to be too clever! There are a lot
of possibilities, not all of which can be automated. Hence my current
preference for leaving alone.
Try, I do use xkeyval at the moment. Moving to pgfkeys would not be too
bad, but I'm not sure that I'm going to do that at the moment.
I'll think about your suggestions again, but there is a fundamental
issue with the way I wrote table support in siunitx. Originally, this
was very much a "side issue", but it seems to be more and more
important. My thinking is that I'll look at writing a "v2" of siunitx
using the expl3 code of LaTeX3, once it is stable enough to be generally
used. I *hope* that there will be something like pgfkeys available in
expl3 at some point. At that stage, I'll probably shift all of the
tabular support into its own key path, as the current situation is
rather "cramped".
I think this is all a bit too ambigious for v1.1, but I'll see what
ideas come to me. Perhaps on the list for 1.2!
--
Joseph Wright