Re: Re: Types in Mathematica
- To: mathgroup at smc.vnet.net
- Subject: [mg62772] Re: Re: Types in Mathematica
- From: "Steven T. Hatton" <hattons at globalsymmetry.com>
- Date: Mon, 5 Dec 2005 03:37:19 -0500 (EST)
- References: <200511191053.FAA16418@smc.vnet.net> <dlp2ci$le$1@smc.vnet.net> <200511200950.EAA04496@smc.vnet.net> <dls4vp$mmc$1@smc.vnet.net> <dm1ak3$i1n$1@smc.vnet.net> <dmjrb8$5u6$1@smc.vnet.net> <dmm2tp$nmo$1@smc.vnet.net> <200512031040.FAA06695@smc.vnet.net> <dmtbuu$fo6$1@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
I wrote a rather long reply to this. But before I had a chance to send it I encountered the result of my doing something something foolish. I had updated several of the packages in the prerelease KDE I run, and didn't bother to restart X when I finished. X locked up, and I lost the message. What's below is quite different from the original message. Kristen W Carlson wrote: [snip, ain't gonna touch that] > When considering data typing in Mathematica, the thought process > should go something like this: > > 1. What is my purpose in typing? It would be interesting to enumerate the reasons for using data types in various languages. Here are a few uses of data types off the top of my head; mostly in terms of C++. 1) A self-commenting code. 2) Validity checking. 3) Control over lowlevel performance issues. 4) Representing abstract structures. (user defined types, i.e., classes) 5) Representing specific types of real world objects. (also classes) 6) Statefull functions. (Function objects) 8) Function overloading. 9)... I'm sure there is a lot that can be said about all of the above, and I am also sure it is not exhaustive. > 2. Are there built-in types or type filters or converters that I can > use? (There are a bunch) We do have something of a problem determining what we mean by built-in types, etc. Since Mathematica does not have a formal specification, much less a formal definition of what a "type" is, it really reduces to a matter of opinion as to what is, or is not a type. > 3. Should I create my own data type? (Easy to do) I'm still uncommitted regarding how easy it is to create data types with associated operations in such a way as to be less trouble than they are worth. Some of this certainly depends on the kind of application you are working on. It makes little sense to create an intricate data type which will only be used once or twice. > 4. Should I create an automatic type converter using pattern matching > and rules? (A little more complicated to get the syntax to work, but > still eminently doable and eminently flexible) I have come to realize that there are (or appear to be) certain limitations as to what can be done with type conversions in comparison to how they are used in C++. For example, in C++ it is possible to create type conversion operators which will be invoked according to the parameters accepted by a function. For example, you might have some kind of counter object which automatically converts to an integer when passed as a variable of integer type. I don't believe I could do something similar with Mathematica. For instance, if I have a type Vector3D[x,y,z], I don't see a way of getting that to convert to a List[x,y,z] when passed to an arbitrary function taking a List as an argument. > Or should I default to > Mathematica's implicit error message of getting back my input > unaltered? Or should I add an error message? I believe it would be possible to have a catchall signature that generates a message if none of the intended patterns (signatures) are matched. > 5. If I am extending built-in or user-defined functions (like Plus), > should I restrict users to using a constructor to do that, or extend > the existing function in the context of my data type with an upvalue? I'm not sure what you mean by "restrict users to using a constructor to do that". Care you explain? [Note: I read what follows, and I'm still a bit unsure what is meant.] > This last is a philosophical discussion; harry calkins of the > Education Group believes we should always use constructors. I believe, > following the same design principle of Mathematica's built-in > converters, which in turn follow the UI design principle of just get > the job done without involving the user's valuable time unnecessarily, > to consider extending existing functions with upvalues. I can't comment on that until I have a better understanding of what is meant by "constructors" in this context. > But below is an example that admittedly is borderline; altho I wrote > it as extending Part with an upvalue to extract the numerator or > denominator of a rational number (created as a new datatype as an > exercise from M220 the programming course), I can see the other point > of view--not allowing Part to do this. > .... > The datatype is rational[n_Integer, d_Integer] with n and d > type-checked as integers .... > > makeRational[n_Integer, 0] := > Print["This rational is undefined."] (* better than just getting > input back as output *) > > (* vs. this approach which Maeder wrote that does automatic type > conversion; for a negative denominator, it calls the function again > and just reverses the signs of the numerator and denominator; that way > negative rationals are always in the format rational[-n, d] *) > > makeRational[n_Integer, d_Integer?Negative] := makeRational[-n, d] The above are what I would call /constructors/. They are something like simple a factory design pattern. > ... > denominator::"denominator will extract the denominator of the > rational. You can also use Part[ rational ] , which has been modified > to work correctly in the context of this package." Using an upvalue? > ... > rational /: (r_rational)[[1]] := numerator[r]; (* numerator is the > constructor *) I believe Dr. Maeder would use the term "selector" instead of "constructor" in this context. Thanks for posting your example. Reading it was good exercise for me. -- The Mathematica Wiki: http://www.mathematica-users.org/ Math for Comp Sci http://www.ifi.unizh.ch/math/bmwcs/master.html Math for the WWW: http://www.w3.org/Math/