Inconsistent axis label format for default "s" formatter -- one axis might get "0.8" another might get "800m"

[ellisonbg]

Please:

• Check for duplicate issues
• Describe how to reproduce the bug / the goal of the new feature request
• Provide an example spec and/or screenshots (if applicable)

Here is a simple Q/Q scatter plot where the x variable is being treated as a T rather than Q by vega-lite:

http://vega.github.io/vega-editor/

[ellisonbg]

Sorry, here is the spec:

{
  "layers": [
    {
      "encoding": {
        "x": {
          "type": "quantitative",
          "field": "x"
        },
        "y": {
          "type": "quantitative",
          "field": "y"
        }
      },
      "mark": "line"
    },
    {
      "encoding": {
        "x": {
          "type": "quantitative",
          "field": "x"
        },
        "y": {
          "type": "quantitative",
          "field": "y"
        }
      },
      "mark": "point"
    }
  ],
  "data": {
    "values": [
      {
        "x": 0.38932394045040675,
        "y": 0.6415381588826321
      },
      {
        "x": 0.8876175977902927,
        "y": 0.7764036119699418
      },
      {
        "x": 0.6847443037497015,
        "y": 0.6364476522434331
      },
      {
        "x": 0.8156885141244735,
        "y": 0.19512149715932536
      },
      {
        "x": 0.10343745851917496,
        "y": 0.755887274899728
      },
      {
        "x": 0.9747637379801027,
        "y": 0.6849368990011483
      },
      {
        "x": 0.08278509303896364,
        "y": 0.8773512074972996
      },
      {
        "x": 0.23116523187521087,
        "y": 0.05785317421235814
      },
      {
        "x": 0.6139270132180712,
        "y": 0.08260902006275694
      },
      {
        "x": 0.32121169962549534,
        "y": 0.6589634118776869
      }
    ]
  },
  "config": {
    "cell": {
      "width": 500,
      "height": 350
    }
  }
}

This is with ipyvega master @domoritz

[ellisonbg]

Hmm, sometimes, the x variable gets the T encoding, other times, the y...

[ellisonbg]

And a non-layered spec showing the problem:

{
  "encoding": {
    "x": {
      "type": "quantitative",
      "field": "x"
    },
    "y": {
      "type": "quantitative",
      "field": "y"
    }
  },
  "data": {
    "values": [
      {
        "x": 0.38932394045040675,
        "y": 0.6415381588826321
      },
      {
        "x": 0.8876175977902927,
        "y": 0.7764036119699418
      },
      {
        "x": 0.6847443037497015,
        "y": 0.6364476522434331
      },
      {
        "x": 0.8156885141244735,
        "y": 0.19512149715932536
      },
      {
        "x": 0.10343745851917496,
        "y": 0.755887274899728
      },
      {
        "x": 0.9747637379801027,
        "y": 0.6849368990011483
      },
      {
        "x": 0.08278509303896364,
        "y": 0.8773512074972996
      },
      {
        "x": 0.23116523187521087,
        "y": 0.05785317421235814
      },
      {
        "x": 0.6139270132180712,
        "y": 0.08260902006275694
      },
      {
        "x": 0.32121169962549534,
        "y": 0.6589634118776869
      }
    ]
  },
  "config": {
    "cell": {
      "width": 500,
      "height": 350
    }
  },
  "mark": "line"
}

[kanitw]

Thanks for reporting.

I don't think this is a bug. Both x and y still use linear scale so the problem isn't about T/Q.

I think the problem you suggest is the fact that we have to order the points in the line somehow and there is not clear good default between

1. Sort by x-axis value
2. Sort by y-axis value
3. Sort by original order of the data

I'm torn between 1 and 3 but currently we do 1 by default, following Tableau's convention, which is battle tested for years.
If you have strong opinion that we should do 3, I can consult with other team members if we want to change to do 3 by default.

(You can use path channel to customize between 1 and 2. Too bad, we don't have a syntax for 3 yet as discussed in #1020 but after we fix it, you should be able to express it too.)

[ellisonbg]

Hmm, not sure I follow. The problem also exists with a point mark as well. Here are two screen shots:

The thing that is most confusing is the units of the y scale. Even though the y values are between 0.0 and 1.0, the axis labels read 100m, 200m, 300m. What does that mean? I figured that the m meant minutes somehow. I don't see how this is related to the sorting as it also appears in points.

I think sorting by x values make sense though.

[kanitw]

Oh Thank you. I see what you mean now!

We currently use string "s" formatter (which is a "decimal notation with an SI prefix, rounded to significant digits") by default. So 900m is 0.9. That said, I don't know why one axis got 0.9 and one axis got 0.8.

@jheer recently upgraded formatter in Vega. Let's see what he says.

[ellisonbg]

OK thanks!

On Sat, Jul 9, 2016 at 12:18 PM, Kanit Wongsuphasawat <
notifications@github.com> wrote:

Oh Thank you. I see what you mean now!

We currently use string "s" formatter (which is a "decimal notation with
an SI prefix, rounded to significant digits") by default. So 900m is 0.9.
That said, I don't know why one axis got 0.9 and one axis got 0.8.

@jheer https://github.com/jheer recently upgraded formatter in Vega.
Let's see what he says.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#1459 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AABr0H_RkmUGWV41Uv4PqJxlwxnuUDdJks5qT9fqgaJpZM4JIo48
.

Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com

[peller]

bump. Just ran into the same problem. We thought maybe the 'm' meant meters?

[kanitw]

This is another example of this problem (from Voyager 2) - found by @domoritz

[domoritz]

Hmm, who reported that one? 😄

[kanitw]

This is not fixed yet, but should be a part of #1539.