Re: [matplotlib-devel] Improve ticks with an offset readability

[Francisco de la Peña]

Hi Gökhan,

I tried your example and I couldn't find anything wrong with the offset
there. However, I agree that this particular mixture of scientific notation
and offset looks confusing. Maybe in that case it will be better to write:
x1e-10+320700e-10 . Is it what you mean?

Cheers,

Francisco

El 17 de noviembre de 2009 00:58, Gökhan Sever escribió:

>
>
> 2009/11/15 Francisco Javier de la Peña 
>
> Hi,
>>
>> I find it difficult to read the values of an axis when the offset is
>> active. The problem is that many time I find myself doing calculations like
>> -1.2345e2-0.048 to find out the value of the tick. I send enclosed a patch
>> and a test file to, in my opinion, improve the readability of the ticks with
>> an offset.
>>
>> Cheers,
>>
>> Francisco
>>
>
> Hi Francisco,
>
> Could you try this simple case ?
>
> I[6]: a = np.linspace(0.2, 0.5, num=9348)
>
> I[7]: plot(a)
>
> Still ticks produce mingled values. Like 1e-10+3.207e-5 after some zooming
> in.
>
>
>
>
>>
>> --
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
>
> --
> Gökhan
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* , and is
> believed to be clean.
>
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Improve ticks with an offset readability

[Gökhan Sever]

On Tue, Nov 17, 2009 at 4:29 AM, Francisco de la Peña <
delap...@lps.u-psud.fr> wrote:

> Hi Gökhan,
>
> I tried your example and I couldn't find anything wrong with the offset
> there. However, I agree that this particular mixture of scientific notation
> and offset looks confusing. Maybe in that case it will be better to write:
> x1e-10+320700e-10 . Is it what you mean?
>

I think this could be better presented collecting the base terms under the
same exponent (i.e  320701e-10 and further 32e-6) Doesn't this look simpler?



>
> Cheers,
>
> Francisco
>
> El 17 de noviembre de 2009 00:58, Gökhan Sever 
> escribió:
>
>>
>>
>> 2009/11/15 Francisco Javier de la Peña 
>>
>>  Hi,
>>>
>>> I find it difficult to read the values of an axis when the offset is
>>> active. The problem is that many time I find myself doing calculations like
>>> -1.2345e2-0.048 to find out the value of the tick. I send enclosed a patch
>>> and a test file to, in my opinion, improve the readability of the ticks with
>>> an offset.
>>>
>>> Cheers,
>>>
>>> Francisco
>>>
>>
>> Hi Francisco,
>>
>> Could you try this simple case ?
>>
>> I[6]: a = np.linspace(0.2, 0.5, num=9348)
>>
>> I[7]: plot(a)
>>
>> Still ticks produce mingled values. Like 1e-10+3.207e-5 after some zooming
>> in.
>>
>>
>>
>>
>>>
>>> --
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> 30-Day
>>> trial. Simplify your report design, integration and deployment - and
>>> focus on
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>> ___
>>> Matplotlib-devel mailing list
>>> Matplotlib-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>>
>>
>> --
>> Gökhan
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by *MailScanner* , and is
>>
>> believed to be clean.
>>
>
>


-- 
Gökhan
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Improve ticks with an offset readability

[Francisco de la Peña]

Hi Gökhan,

I think that we are understanding differently the notation (what would mean
that it is indeed confusing). For me 1e-10+3.207e-5 means: "to get your
value read the figure from the axis, multiply it by 1e-10 and add 3.207e-5".
The source of the confusion could be a missing "x" in front of 1e-10.
Anyway the patch that I have submitted is not related to this problem, it
only affects the way the offset is calculated, not the way it is displayed.
I just tested an unmodified version of matplotlib and the "x" is not
displayed there neither. The difference that the patch makes is that instead
of 4x1e-8+2.995e-5 you get  99x1e-8+2.9e-5 that I think it is easier to
read. In addition, if the number of significant figures in the axis range
changes it takes it into account so the offset becomes human friendly for
all the axis values.

Cheers,

Francisco

2009/11/17 Gökhan Sever 

>
>
> On Tue, Nov 17, 2009 at 4:29 AM, Francisco de la Peña <
> delap...@lps.u-psud.fr> wrote:
>
>> Hi Gökhan,
>>
>> I tried your example and I couldn't find anything wrong with the offset
>> there. However, I agree that this particular mixture of scientific notation
>> and offset looks confusing. Maybe in that case it will be better to write:
>> x1e-10+320700e-10 . Is it what you mean?
>>
>
> I think this could be better presented collecting the base terms under the
> same exponent (i.e  320701e-10 and further 32e-6) Doesn't this look simpler?
>
>
>
>>
>> Cheers,
>>
>> Francisco
>>
>> El 17 de noviembre de 2009 00:58, Gökhan Sever 
>> escribió:
>>
>>>
>>>
>>> 2009/11/15 Francisco Javier de la Peña 
>>>
>>>  Hi,

 I find it difficult to read the values of an axis when the offset is
 active. The problem is that many time I find myself doing calculations like
 -1.2345e2-0.048 to find out the value of the tick. I send enclosed a patch
 and a test file to, in my opinion, improve the readability of the ticks 
 with
 an offset.

 Cheers,

 Francisco

>>>
>>> Hi Francisco,
>>>
>>> Could you try this simple case ?
>>>
>>> I[6]: a = np.linspace(0.2, 0.5, num=9348)
>>>
>>> I[7]: plot(a)
>>>
>>> Still ticks produce mingled values. Like 1e-10+3.207e-5 after some
>>> zooming in.
>>>
>>>
>>>
>>>

 --
 Let Crystal Reports handle the reporting - Free Crystal Reports 2008
 30-Day
 trial. Simplify your report design, integration and deployment - and
 focus on
 what you do best, core application coding. Discover what's new with
 Crystal Reports now.  http://p.sf.net/sfu/bobj-july
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


>>>
>>>
>>> --
>>> Gökhan
>>>
>>>
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by *MailScanner* , and
>>> is
>>> believed to be clean.
>>>
>>
>>
>
>
> --
> Gökhan
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* , and is
> believed to be clean.
>
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Improve ticks with an offset readability

[Gökhan Sever]

You are right Francisco. I was misinterpreting, and probably not having an
"x" is not an issue.

On Tue, Nov 17, 2009 at 1:25 PM, Francisco de la Peña <
delap...@lps.u-psud.fr> wrote:

> Hi Gökhan,
>
> I think that we are understanding differently the notation (what would mean
> that it is indeed confusing). For me 1e-10+3.207e-5 means: "to get your
> value read the figure from the axis, multiply it by 1e-10 and add 3.207e-5".
> The source of the confusion could be a missing "x" in front of 1e-10.
> Anyway the patch that I have submitted is not related to this problem, it
> only affects the way the offset is calculated, not the way it is displayed.
> I just tested an unmodified version of matplotlib and the "x" is not
> displayed there neither. The difference that the patch makes is that instead
> of 4x1e-8+2.995e-5 you get  99x1e-8+2.9e-5 that I think it is easier to
> read. In addition, if the number of significant figures in the axis range
> changes it takes it into account so the offset becomes human friendly for
> all the axis values.
>
> Cheers,
>
> Francisco
>
> 2009/11/17 Gökhan Sever 
>
>
>>
>> On Tue, Nov 17, 2009 at 4:29 AM, Francisco de la Peña <
>> delap...@lps.u-psud.fr> wrote:
>>
>>> Hi Gökhan,
>>>
>>> I tried your example and I couldn't find anything wrong with the offset
>>> there. However, I agree that this particular mixture of scientific notation
>>> and offset looks confusing. Maybe in that case it will be better to write:
>>> x1e-10+320700e-10 . Is it what you mean?
>>>
>>
>> I think this could be better presented collecting the base terms under the
>> same exponent (i.e  320701e-10 and further 32e-6) Doesn't this look simpler?
>>
>>
>>
>>>
>>> Cheers,
>>>
>>> Francisco
>>>
>>> El 17 de noviembre de 2009 00:58, Gökhan Sever 
>>> escribió:
>>>


 2009/11/15 Francisco Javier de la Peña 

  Hi,
>
> I find it difficult to read the values of an axis when the offset is
> active. The problem is that many time I find myself doing calculations 
> like
> -1.2345e2-0.048 to find out the value of the tick. I send enclosed a patch
> and a test file to, in my opinion, improve the readability of the ticks 
> with
> an offset.
>
> Cheers,
>
> Francisco
>

 Hi Francisco,

 Could you try this simple case ?

 I[6]: a = np.linspace(0.2, 0.5, num=9348)

 I[7]: plot(a)

 Still ticks produce mingled values. Like 1e-10+3.207e-5 after some
 zooming in.




>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>


 --
 Gökhan


 --
 This message has been scanned for viruses and
 dangerous content by *MailScanner* , and
 is
 believed to be clean.

>>>
>>>
>>
>>
>> --
>> Gökhan
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by *MailScanner* , and is
>>
>> believed to be clean.
>>
>
>


-- 
Gökhan
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Dissapearing data? / path.simplify behavior

[Drain, Theodore R (343P)]

FYI: Thanks for the help John.

This is case where having path.simplify = True causes the plot to be incorrect. 
 Attached are two different images (not quite the same data as the original 
post- but the same affect).  One with path.simplify as true and one as false.  
Notice the bottom right plot - the simplify case causes a massive change in the 
way the plot looks.

It looks like we'll be reconfiguring things for our users to make sure this is 
set to false for now.  I haven't experimented w/ the threshold argument to see 
where this kicks in.  It's definitely a function of plot size (which is 
probably expected after reading the simplify documentation).

Does anyone know if there is a good write up anywhere on the cases where having 
path.simplify=True is important?  I'll search back through the old list posts 
and see what I can find...

Ted


From: James Evans [jreva...@earthlink.net]
Sent: Friday, November 13, 2009 11:15 AM
To: 'matplotlib development list'
Subject: [matplotlib-devel] Dissapearing data?

All,

I have noticed a bizarre occurrence.  I have a fairly dense plot that when 
viewed in a large figure I can see all of the data, but as I resize the plot 
smaller I start to see some of the data disappear.  I understand that there is 
a pixel-space issue, but to someone who might not realize that their plot is 
physically too small, they might think that what they see is really true.  In 
the attached example script (with data) you can see this behavior.  When the 
plot gets small enough you never see anything reach the y value of 20.0.  I 
found this to be a little disconcerting and was wondering if I can get a 
detailed explanation as to what I am seeing.

Thanks,
--James Evans
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Dissapearing data? / path.simplify behavior

[Eric Firing]

Drain, Theodore R (343P) wrote:
> FYI: Thanks for the help John.
>  
> This is case where having path.simplify = True causes the plot to be 
> incorrect.  Attached are two different images (not quite the same data 
> as the original post- but the same affect).  One with path.simplify as 
> true and one as false.  Notice the bottom right plot - the simplify case 
> causes a massive change in the way the plot looks. 
>  
> It looks like we'll be reconfiguring things for our users to make sure 
> this is set to false for now.  I haven't experimented w/ the threshold 
> argument to see where this kicks in.  It's definitely a function of plot 
> size (which is probably expected after reading the simplify documentation).
>  
> Does anyone know if there is a good write up anywhere on the cases where 
> having path.simplify=True is important?  I'll search back through the 
> old list posts and see what I can find...

It is a matter of speed, and I think of some hard limits in agg on the 
number of points it can handle.

So far, every time someone has pointed out a problem--a case in which 
the simplification code makes a perceptible difference in the appearance 
of the plot--Mike D. has found a way to fix it.

I haven't followed this thread closely, but have you verified the 
problem with recent mpl, and have you provided a minimal script to 
trigger it?

Eric

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel