MathGroup Archive 2005

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

Search the Archive

Re: EUREKA Re: Types in Mathematica, a practical example

  • To: mathgroup at
  • Subject: [mg63185] Re: EUREKA Re: [mg62800] Types in Mathematica, a practical example
  • From: Kristen W Carlson <carlsonkw at>
  • Date: Sat, 17 Dec 2005 03:46:17 -0500 (EST)
  • References: <> <>
  • Sender: owner-wri-mathgroup at


I am happy for your Archimedean insight and admire how you have delved
into this area and found a solution, and come out the other side
appreciating Mathematica all the more.

So don't feel insulted at this question, and it's my ignorance of
either your task or the style in other languages that generates it.
It's asked in the context of the various threads that reveal a
"world-view" conflict between programming styles, mainly those
inherited from other languages, I believe.

Can you help me understand why you need to do this? Are you adapting
Mathematica to do something that you have done easily in another
language, rather than doing it the Mathematica Way (i.e. the way that
is built in, since you have created a new Mathematica Way on top of

>The functionality we
> obtain by defining an array by g=Array[f,{n1,n2}] could be built into
> Mathematica in a hidden way, in such a way that g[[1,2]] behaved as f[1,2]
> in expressions. But it is not so now.

In an earlier post I redefined Part with two upvalues so it worked
fine for arrays or matrices, extending the "unfinished" definition as
you point out.

>None of these methods gives the effect
> that g[[1,2]] is returned unevaluated if it is undefined, as is done with an
> undefined variable g

& did this with a symbol, 'undefined', which could return the string
"undefined" or anything you want. In any event you could reset all the
undefined terms through the variable of that name, or selectively via
f[i] in indexed arrays or ReplacePart in matrices.

& others had various other suggestions. So what exactly is missing?

Even if you are adapting Mathematica to your own 'desire' rather than
necessity, a package may be very helpful to all those who feel the
same way, and more generally in other areas as well to help people
transition from 'native' languages to Mathematica. The other
possibility is that it's an overly complex workaround for personal
preference (still apparently worth it to you in that case, tho).


PS Yet another general way to do typing--we have now accumulated a
bunch--is by setting a flag in a "named argument", as Maeder calls
options. The functions are built-in for initializing and changing
them, and we need the package FilterOptions to pass the options
between functions, which I see exists but haven't explored.

  • Prev by Date: Re: Reduce bug?
  • Next by Date: Re: EUREKA Re: Types in Mathematica, a practical example
  • Previous by thread: Re: Types in Mathematica, a practical example
  • Next by thread: Re: Types in Mathematica, a practical example