MathGroup Archive 2010

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Defining UpValues

  • To: mathgroup at smc.vnet.net
  • Subject: [mg110820] Re: Defining UpValues
  • From: "István Zachar" <replicatorzed at gmail.com>
  • Date: Wed, 7 Jul 2010 07:45:48 -0400 (EDT)

Dear Leonid,

thanks for the answer. Yes, I agree that the design is not the best in
this case, and to tell you the truth,
just after posting my question here I've decided - though I was a bit
dubious about it - to introduce the wrapper.
Now I'm much more confident with my choice as it seems to be the general
method to handle situations like this.

The only problem (at the moment) with the wrapper is that previously the
(IRL) outcome of func was a list, while
now it has the wrapper as head, making ReplaceAll calls a bit harder to
implement (like

{a, b} /. Wrapper[a -> 1, b -> 2]

which gives an errormessage. But setting UpValues for Wrapper with
ReplaceAll does help here:

Wrapper/: ReplaceAll[expr_, rep_Wrapper] :== ReplaceAll[expr, List @@ rep];

Anyway, your solution is impressive in its simplicity: I never would
have thought to fiddle with the evaluation stack,
but it's a very clever workaround! Though I won't use it, it still
remains to be a rather tricky intellectual achievement : )

Istvan


On 2010.07.06. 14:12, Leonid Shifrin wrote:
> Hi Istvan,
>
> This was a tough one. Here is one way (it took me a while to figure it
> out, first I thought it was
> not possible, and almost sent you a long explanation why it is
> impossible))):
>
> ClearAll[func];
> func[x_Integer] :==
>   x /; ! MemberQ[Stack[_], HoldForm[func[_Integer][args___]]];
> func /: func[sys_Integer][args___] :== sys + 1;
> func[sys_Function] :== sys;
>
>
> In[191]:== {func[1], func[1][2], func[# + 2 &], func[# + 2 &][2]}
>
>
> Out[191]== {1, 2, #1 + 2 &, 4}
>
> I would still consider changing the design though, since this kind of
> difficulties / workarounds usually
> indicate to me that the design of the function in question is not well
> thought over. For example, if
> your sys is often supplied with additional optional arguments, you can
> create a wrapper say sysData (or, just
> a List) and store them there, like func[sysData[sys,opts___]], etc.
>
> Hope this helps.
>
> Regards,
> Leonid
>
>
> 2010/7/6 Istv=E1n Zachar <zac at freemail.hu <mailto:zac at freemail.hu>>
>
>     Dear Group,
>
>     consider the following code:
>
>     func[sys_Integer] :== sys;
>     func /: func[sys_Integer][args___] :== sys + 1;
>     func[sys_Function] :== sys;
>
>     {
>      func[1],
>      func[1][2],
>      func[# + 2 &],
>      func[# + 2 &][2]
>      }
>
>     Is there a way to define func such a way that when the main argument
>     is an Integer, any further arguments are ignored? That is, to
>     return:    {1, 2, #1 + 2 &, 4}    instead of    {1, 1[2], #1 + 2 &,
>     4}. At present, the second function definition is basically ignored b=
y
>     the kernel.
>
>     I am aware that func[sys_type, args___] would be the easiest way to
>     use here, but in my real code
>        1. there is a large number of named options supplied with sys
>     preventing (or at least making hard) the use of *any number* of
>     optional second arguments;
>        2. sometimes the main call (func[sys]) is separated from the
>     introduction of any optional argument (this is part of a GUI), which
>     may cause calls like this:
>        x == func[some_function]; ... (* calculations involving x *) ... ;
>     y == x[2];
>
>     Thanks in advance,
>
>     Istv==E1n
>
>
>
>
>
>
>


  • Prev by Date: Re: overloading a function name in a package? How to query all names?
  • Next by Date: Re: overloading a function name in a package? How to query all names?
  • Previous by thread: Defining UpValues
  • Next by thread: Re: Defining UpValues