nicola | 5 Dec 12:23 2007
Picon

Using |s| as a variable name

Hello,
I am a bit puzzled by the way a name like |s| may behave. Why is this 
seemingly correct:

   string s;
   s = "aaaaaaa";
   |s| = length s;
   show |s|;

and why does the following produce an error?

   string s;
   s = "aaaaaaa";
   |s| = length s;
   for i = 1 upto |s|:
      ;
   endfor;

>> |s|:
! Improper final value has been replaced by 0.

I would like to use |s| in a subroutine, as follows:

vardef foo(expr x) =
   |x| := length x;
enddef;

string s;
s = "abc";
foo(s);
(Continue reading)

Taco Hoekwater | 5 Dec 13:02 2007

Re: Using |s| as a variable name

nicola wrote:
> and why does the following produce an error?
> 
>    string s;
>    s = "aaaaaaa";
>    |s| = length s;
>    for i = 1 upto |s|:
>       ;
>    endfor;

Because the colon is taken to be part of the variable name,
as it is in the same character class as the pipe symbol.

This works:

   for i = 1 upto |s| :

and so does this:

   for i = 1 upto (|s|):

Best wishes,
Taco
--
http://tug.org/mailman/listinfo/metapost

Stephan Hennig | 10 Dec 14:52 2007
Picon

[mp-form.mp and negative numbers

Hi,

I've noticed a problem with package graph not being able to format
negative numbers if package metafun is loaded.  I've noticed that
metafun comes with its own version of the format package, called
mp-form, that replaces format.  So I guess there must be a bug in
mp-form.mp.

In the attached code, if the metafun version of format is used, negative
numbers are prefixed by a string "unknown" instead of a minus sign.

Best regards,
Stephan Hennig

input metafun
% input format
prologues := 3;
beginfig(1);
  label(format("%3f", 1234), (50,100));
  label(format("%3f", -1234), (50,50));
endfig;
end
--
http://tug.org/mailman/listinfo/metapost

Dan Luecking | 11 Dec 21:00 2007
Picon

Re: [mp-form.mp and negative numbers


It appears that metafun's initialize_numbers is buggy. Or perhaps it
was never meant to be used alone. That particular function is defined
in mp-text.mp and calls
   init_numbers(textext.raw($-$),textext.raw($1$),...). The
macro textext appears to return "unknown" if some quantity called
texpictures[noftexpictures] is unknown. This appears to be the
case when textext is first called. Thus the minus sign picture
is unknown.

Other uses of metafun (within context, for example) might arrange for
that variable to be known.

The following work-around might or might not be useful. I only tested
it on stephan's example:

   noftexpictures:=0;
   picture texpictures[];
   texpictures1 := btex$-$etex;

Use after metafun is input but before any calls to format().

Dan

Daniel H. Luecking
Department of Mathematical Sciences
University of Arkansas
"Dubito ergo cogito, cogito ergo sum" --Descarte

--
(Continue reading)

Hans Hagen | 11 Dec 21:19 2007
Picon

Re: [mp-form.mp and negative numbers

Dan Luecking wrote:
> It appears that metafun's initialize_numbers is buggy. Or perhaps it
> was never meant to be used alone. That particular function is defined
> in mp-text.mp and calls
>    init_numbers(textext.raw($-$),textext.raw($1$),...). The
> macro textext appears to return "unknown" if some quantity called
> texpictures[noftexpictures] is unknown. This appears to be the
> case when textext is first called. Thus the minus sign picture
> is unknown.
> 
> Other uses of metafun (within context, for example) might arrange for
> that variable to be known.
> 
> The following work-around might or might not be useful. I only tested
> it on stephan's example:
> 
>    noftexpictures:=0;
>    picture texpictures[];
>    texpictures1 := btex$-$etex;
> 
> Use after metafun is input but before any calls to format().

sorry for not answering sooner, but i looked at it and was puzzled why 
it didn't initialize .. normally it should fall back to the old method; 
i need to spent some more time on it

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
(Continue reading)

Stephan Hennig | 11 Dec 22:52 2007
Picon

Re: [mp-form.mp and negative numbers

Dan Luecking schrieb:

> The following work-around might or might not be useful. I only tested
> it on stephan's example:
> 
>    noftexpictures:=0;
>    picture texpictures[];
>    texpictures1 := btex$-$etex;
> 
> Use after metafun is input but before any calls to format().

For me, those lines only work for the next call to format.  After that,
again "unknown" numbers appear.

Best regards,
Stephan Hennig

input metafun
prologues := 3;
beginfig(1);
  noftexpictures:=0;
  picture texpictures[];
  texpictures1 := btex$-$etex;
  label(format("%3f", -1234), (50,100));
  label(format("%3f", -1234), (50,50));
endfig;
end

--
http://tug.org/mailman/listinfo/metapost
(Continue reading)

Dirk Laurie | 11 Dec 15:58 2007
Picon
Picon

NAPOLEON


NAPOLEON is a Metapost package for making geometry sketches given
a typical mathematical description.  For example, part of the 
NAPOLEON code for the mathematical text

  Circles $k_1$ and $k_2$ are drawn so that 
  $k_2$ passes through the centre of $k_1.$  
  The circles cut each other in points $A$ and $B.$  
  A third circle $k_3$ touches $k_1$ in $C$ and $k_2$ in $D$ 
  so that $k_1$ and $k_2$ are inside $k_3.$  
  $AB$ is extended to meet $k_3$ in $E$ and $F.$  
  The lines $DE$ and $DF$ cut $k_2$ respectively in $G$ and $H.$ 

is

  k3 = circumcircle (k1,k2,C); 
  A = cut(k2,k1); B = cut(k1,k2);
  D = cut(k2,O2--O3);
  E = cut(k3,A--B); F = cut(k3,B--A);
  G = cut(k2,E--D); H = cut(k2,F--D);

To find out more, download the README, documentation and source
code from  http://dip.sun.ac.za/~laurie/napoleon.

Dirk Laurie 

--
http://tug.org/mailman/listinfo/metapost

(Continue reading)

Dirk Laurie | 12 Dec 12:45 2007
Picon
Picon

NAPOLEON


NAPOLEON is a MetaPost package for making geometry sketches given
a typical mathematical description.  For example, part of the 
NAPOLEON code for the mathematical text

  Circles $k_1$ and $k_2$ are drawn so that 
  $k_2$ passes through the centre of $k_1.$  
  The circles cut each other in points $A$ and $B.$  
  A third circle $k_3$ touches $k_1$ in $C$ and $k_2$ in $D$ 
  so that $k_1$ and $k_2$ are inside $k_3.$  
  $AB$ is extended to meet $k_3$ in $E$ and $F.$  
  The lines $DE$ and $DF$ cut $k_2$ respectively in $G$ and $H.$ 

is

  k3 = circumcircle (k1,k2,C); 
  A = cut(k2,k1); B = cut(k1,k2);
  D = cut(k2,O2--O3);
  E = cut(k3,A--B); F = cut(k3,B--A);
  G = cut(k2,E--D); H = cut(k2,F--D);

To find out more, download the README, documentation and source
code from  http://dip.sun.ac.za/~laurie/napoleon.

Dirk Laurie

--
http://tug.org/mailman/listinfo/metapost

(Continue reading)

Lander | 26 Dec 13:58 2007
Picon
Picon

`withprescript' writing order

Dear List,

When several `withprescript' drawing options are specified
for a given object, the order in which the strings are
written to the output file is the opposite of the order in
which they appear in the input file.  This does not happen
with `withpostscript'.  Example:

        beginfig(1)
          fill fullcircle scaled 2cm withcolor blue
            withprescript "gsave"
            withprescript ".3 .setopacityalpha"
            withpostscript "grestore";
          fill fullcircle scaled 2cm shifted (1cm, 0)
            withcolor blue;
        endfig;

The `.setopacityalpha' operator comes before `gsave' in the
output file, but my intention is the other way round (just
to alter the graphics state for the first circle).  I wonder
whether this is a deliberate behaviour as intended by the
developers: because it is a "prescript", it may make sense
that LIFO writing order.  I find it a bit awkward, though;
perhaps it is worth adding a line to the manual, as a
clarification.

Sincerely,
Lander.
--
http://tug.org/mailman/listinfo/metapost
(Continue reading)

Dan&Jan Luecking | 27 Dec 10:03 2007
Picon

Re: `withprescript' writing order

At 06:58 AM 12/26/2007, you wrote:
>Dear List,
>
>When several `withprescript' drawing options are specified
>for a given object, the order in which the strings are
>written to the output file is the opposite of the order in
>which they appear in the input file.  This does not happen
>with `withpostscript'.  Example:
>
>         beginfig(1)
>           fill fullcircle scaled 2cm withcolor blue
>             withprescript "gsave"
>             withprescript ".3 .setopacityalpha"

Couldn't you write
   withprescript "gsave .3 .setopacityalpha"
?

>             withpostscript "grestore";
>           fill fullcircle scaled 2cm shifted (1cm, 0)
>             withcolor blue;
>         endfig;
>
>The `.setopacityalpha' operator comes before `gsave' in the
>output file, but my intention is the other way round (just
>to alter the graphics state for the first circle).  I wonder
>whether this is a deliberate behaviour as intended by the
>developers: because it is a "prescript", it may make sense
>that LIFO writing order.

(Continue reading)


Gmane