Re: Re: Resource Hog :-(
- To: mathgroup at smc.vnet.net
- Subject: [mg5285] Re: [mg5184] Re: [mg5094] Resource Hog :-(
- From: Mark Evans <evans at gte.net>
- Date: Sat, 23 Nov 1996 01:44:31 -0500
- Sender: owner-wri-mathgroup at wolfram.com
Daryl Reece wrote: > > I like the generality of Mathematica. It's this generality that will > allow you to write this ByteArray header if you want. See if > stripping off MMA's headers will reduce the size significantly. I > believe the problem with specialized data structures is then writing > the rules and code to allow existing functions to deal with them. > > Regarding your comment about resources. Remember your time is > probably the most precious resource so if spending $1000 on RAM will > allow you to formulate problems 100% faster, I'd say it's a good > trade. > > -Daryl > I like generality too. I disagree with the idea that generality must sacrifice efficiency. All it takes is for WRI to deal with the "bottleneck" cases on a one-by-one basis, e.g. ByteArray[]. It's the same idea you have with the DFT. There is a "general" procedure for computing a DFT, but if you happen to have a list whose length is a power of 2, then you immediately bypass the general DFT procedure in favor of the FFT procedure. If you're smart, that is. So if you have a heterogeneous List[] that includes symbolics and numerics, MMA 3.1 would use the generalized procedures. If you have a homogeneous list of floating-point numbers or ints, MMA 3.1 would use the specialized procedures. Object-oriented programming is supposed to allow designers to write code that works the same across multiple data types, from raw bytes, to integers, to floating points, to Generalized Thingys. You send the List[] object a "message" that says "add 2.5 to yourself" for example, and the List[] either knows it has a homogeneous array and does the operation personally, or knows it has a heteogeneous array and passes the message down the food chain to each individual element. Yes, time is precious, which is why I wish MMA were more efficient. I don't know that a problem is formulated properly until I can run it. Inefficiency impacts problem formulation as much as it does subsequent mechanical execution and testing. Mark