Hi Folks. This is not strictly a ConTeXt problem, but I was hoping there were enough MetaPost experts on the list that I might get an idea of what's going on, or at the least, where to go for more information. I think the MetaPost graphing features are fantastic. It produces very nice output, and automatically handles a lot of axis labelling that other packages don't bother with. However, it auto-labels the y-axis on the following three graphs very differently. I was wondering if this is a strict limitation in the axis ranges that MetaPost deals with gracefully, or if it might be a bug. I haven't seen any reference to the correct range for graph axes. I've tried many ranges, and some work, some don't. Would the MetaFont list be able to help? \usemodule[graph] %% This one works as it should. \startMPcode draw begingraph(130mm,35mm); setrange(0,0,10,22000); glabel.lft(btex {correct 0--22000} etex rotated 90, OUT); autogrid(itick.bot,grid.lft) withcolor .75white ; endgraph; \stopMPcode %% This one gives output, but yields incorrect labels \startMPcode draw begingraph(130mm,35mm); setrange(0,50,10,22000); glabel.lft(btex {wrong 50--22000} etex rotated 90, OUT); autogrid(itick.bot,grid.lft) withcolor .75white ; endgraph; \stopMPcode %% This simply gives up. \startMPcode draw begingraph(130mm,35mm); setrange(0,110,10,22000); glabel.lft(btex {failed 110--22000} etex rotated 90, OUT); autogrid(itick.bot,grid.lft) withcolor .75white ; endgraph; \stopMPcode Thanks in advance, adam -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Adam Lindsay +44(0)1524 594 537 atl@comp.lancs.ac.uk http://www.comp.lancs.ac.uk/computing/users/atl/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
At 07:13 PM 11/6/2002 +0000, you wrote:
This is not strictly a ConTeXt problem, but I was hoping there were enough MetaPost experts on the list that I might get an idea of what's going on, or at the least, where to go for more information.
I think the MetaPost graphing features are fantastic. It produces very nice output, and automatically handles a lot of axis labelling that other packages don't bother with.
However, it auto-labels the y-axis on the following three graphs very differently. I was wondering if this is a strict limitation in the axis ranges that MetaPost deals with gracefully, or if it might be a bug. I haven't seen any reference to the correct range for graph axes. I've tried many ranges, and some work, some don't.
looks like some problem in interpreting the big numbers, (mp can handle only numbers <4000 and some string trickery is used in the graph package); does this also happens in stand alone graphics or is it context specific? Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------
Hans Hagen said this at Thu, 7 Nov 2002 09:55:29 +0100:
At 07:13 PM 11/6/2002 +0000, you wrote:
However, it auto-labels the y-axis on the following three graphs very differently. I was wondering if this is a strict limitation in the axis ranges that MetaPost deals with gracefully, or if it might be a bug. I haven't seen any reference to the correct range for graph axes. I've tried many ranges, and some work, some don't.
looks like some problem in interpreting the big numbers, (mp can handle only numbers <4000 and some string trickery is used in the graph package); does this also happens in stand alone graphics or is it context specific?
I'm not able to mpost things alone at the moment because of my earlier- described texnum.mpx weirdness. So I run all my MP graphics from within ConTeXt right now. When I get home, I'll try to investigate this side further, though. I'm aware of the MP number limit, but MP-graph has its stated (and empirical) limits at 32768. Anyway, I tried variants with all numbers in quotes. It made a difference with numbers over 2^15, but not in the test cases that I sent. It could well have to do with the big number limit, but I'm very confident it's not that alone. Thanks, adam -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Adam T. Lindsay atl@comp.lancs.ac.uk Computing Dept, Lancaster University +44(0)1524/594.537 Lancaster, LA1 4YR, UK Fax:+44(0)1524/593.608 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
On Thu, 07 Nov 2002 09:55:29 +0100
Hans Hagen
looks like some problem in interpreting the big numbers, (mp can handle only numbers <4000 and some string trickery is used in the graph package); does this also happens in stand alone graphics or is it context specific?
no, the problem is not specific to ConTeXt. The problem is in the Gipick_ macro. There a logarithm is calculated: n = 1 for i=1 upto mlog(xpart Gmhh_-xpart Gmll_)/Mten - mlog m/(Mten-epsilon): *10 endfor; The problem is that the argument of mlog becomes <0, thus it is not defined. Here is the error message for the 3rd graph: ! Logarithm of -1385.99995 has been replaced by 0. Gipick_->...i=1upto.mlog(xpart.Gmhh_-xpart.Gmll_)/ Mten-mlog.m/(Mten-epsilon)... auto->...fi.else:hide(Gme_:=Gesame_)Gigen_(Gipick_ ,Gcma_.Gpack_(m,Gme_))fi <to be read again> I spend some time yesterday, but the package is a little tricky and uses some not intuitive variable names. so... Jens
Hi Jens. Thanks for those insights. Perhaps ironically (perhaps not), I don't encounter the problem when I put the axes on a log-scale. Is MP-graph being actively maintained? Is this something that I could push to get fixed? (It *is* something I can work around in this particular application, I think, but it would be nice if it worked in a predictable manner.) Cheers, adam Jens-Uwe Morawski said this at Thu, 7 Nov 2002 14:36:50 +0100:
On Thu, 07 Nov 2002 09:55:29 +0100 Hans Hagen
wrote: looks like some problem in interpreting the big numbers, (mp can handle only numbers <4000 and some string trickery is used in the graph package); does this also happens in stand alone graphics or is it context specific?
no, the problem is not specific to ConTeXt. The problem is in the Gipick_ macro. There a logarithm is calculated: n = 1 for i=1 upto mlog(xpart Gmhh_-xpart Gmll_)/Mten - mlog m/(Mten-epsilon): *10 endfor;
The problem is that the argument of mlog becomes <0, thus it is not defined. Here is the error message for the 3rd graph:
! Logarithm of -1385.99995 has been replaced by 0. Gipick_->...i=1upto.mlog(xpart.Gmhh_-xpart.Gmll_)/ Mten-mlog.m/(Mten- epsilon)...
auto->...fi.else:hide(Gme_:=Gesame_)Gigen_(Gipick_ ,Gcma_.Gpack_(m,Gme_))fi <to be read again>
I spend some time yesterday, but the package is a little tricky and uses some not intuitive variable names. so...
Jens _______________________________________________ ntg-context mailing list ntg-context@ref.ntg.nl http://ref.ntg.nl/mailman/listinfo/ntg-context
-- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Adam T. Lindsay atl@comp.lancs.ac.uk Computing Dept, Lancaster University +44(0)1524/594.537 Lancaster, LA1 4YR, UK Fax:+44(0)1524/593.608 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
At 03:03 PM 11/7/2002 +0000, you wrote:
Hi Jens.
Thanks for those insights. Perhaps ironically (perhaps not), I don't encounter the problem when I put the axes on a log-scale.
Is MP-graph being actively maintained? Is this something that I could push to get fixed?
since hobby published the manual in a recent tugboat ... i suggest that you
send him a mail with a test.mp file demoing the problem; afaik normally
he's responsive to real bugs (you can cc to me)
"John Hobby"
participants (4)
-
Adam Lindsay
-
Adam T. Lindsay
-
Hans Hagen
-
Jens-Uwe Morawski