Re: Charting solutions
Re: Charting solutions
- Subject: Re: Charting solutions
- From: Drew McCormack <email@hidden>
- Date: Tue, 1 Apr 2003 09:28:48 +0200
Hi John,
There is a lot of interest in this developing a Cocoa community project
in this area and I believe also in providing a numerical toolkit that
is designed to interface with it and AltiVec (aka Apple's "Velocity
Engine"). The other thing we should consider is doing 3D in OpenGL.
I have also thought about this. I am a scientist, so I need this sort
of functionality.
I think the best approach for a numerical toolkit would be to build a
single class
or class cluster that wrapped around Apple's own vecLib, which uses
BLAS and Altivec
implementations where possible.
I have been using python a lot lately, and I think you could do a lot
worse than trying
to duplicate the design approach of the "Numeric" (Numpy) module. It
introduces a single
multi-dimensional array class, which includes operations that are
basically just wrappers for
BLAS and LAPACK. The class is very flexible: you can set it to any
shape, change its shape,
extract a slice, etc, rather like Fortran 90 array constructions. And
because Python
and Obj-C are very similar in many ways, I think it should certainly be
possible to create
such a class or class cluster.
For example, myself and others have already independently developed
basic Cocoa classes that handle numeric data as formal Objects, like C
arrays that can be placed in NSArray or NSDictionary and that you can
call [myArray sort] or [myArray insertValue:aFloat AtIndex:anUnsigned].
I would also like to support this numerical kit with something
approaching a full implementation of Numerical Recipes in C, but with
AltiVec implementations and AltiVec streaming management!
Sounds like a good start. I would begin by supporting basic linear
algebra, simply wrapping
the LAPACK functions in vecLib.framework, and later look at some of the
more complex stuff
from NR.
Obviously, it makes no sense for all to independently re-develop what
the community as a whole needs, like-wise the open-source approach
generates essentially the academic benefits of peer-review and
contribution. Furthermore, as we all know Apple is an alternative
platform, which by means game theory that like any other minority
group, our best strategy as software developers is to work together.
Specifically, it is in our mutual interest to enhance the stability and
depth of Apple's platform so that it easier to develop applications
that are significantly better, both in terms of system integration and
individual performance, than those available in the Windows world.
Can't agree more.
Some kind of Cocoa Numerics web site
will be coming from me.
Yes please!
That being said, back to the simple 2D Chart Kit. The status of this
thread changes very fast, before you spoke up we had just received a
partial Cocoa update of XYPlot from the original author Sean Hill, who
based XYPlot on nxyPlot. It appears at first glance to be have the
advantage of being 100% Cocoa and only needing the creation of
"PlotInspector.nib" to turn it into a fully functioning Interface
Builder palette that can be added to anyone's application simply be
added dragging it into Interface Builder and making some connections.
Yes, I have just thrown together a small test app with XYPlot to see
what it is about.
It works very well, and is quite complete. My framework is less user
friendly at this
stage.
My framework takes quite a different approach to XYPlot. XYPlot is
basically procedural plotting
code in a single cocoa class. This has advantages, such that it is very
fast, and quite easy to
understand. In this sense, it probably meets most peoples needs and
expectations.
My framework is much more object-oriented, with a view to future
extensions and changes. For
example, I have used an NSTableView type data source approach, so that
I make no assumptions
about how the data is stored. This is slower, but more flexible.
I also have many more classes that work together to create a
chart/plot. Any of these classes
can be subclassed to introduce new behavior. For example, I use a class
called "Transform" to
transform between various coordinate representations, such as NSView
coordinates, plot coordinates,
axis coordinates etc. Introducing a new type of scale, such as a log
scale, is then a matter of
simply subclassing the Transform class with, say, a LogTransform class.
Introducing a whole new type of plot, such as a pie chart, would only
require a few classes be subclassed.
If you are interested, check out the header files in
Narrative.framework inside my app. You can get a good idea of the
design from them.
As you can see, my approach is not as straightforward as XYPlot, but I
must admit that I am
quite proud of some of the OO design elements. It's not all good, but I
like a lot of the
ideas behind Narrative.framework, even if I do say so myself ;-)
That said, I also like XYPlot, from what I have seen. Speed and
simplicity are important, and
I can't match XYPlot there. Narrative probably has the advantage of
flexibility, but I wonder
how many people need that.
I don't think I will release Narrative as open source unless there is
enough interest. XYPlot is
nice, and ready to go, and I don't want to compete thereby ruining the
chances that either
plotting library will reach critical mass.
However, I am sure that we would all benefit from looking at what you
written as well.
Maybe, maybe not. The headers are available. I wouldn't want to release
the code just so
others could steal stuff from it. If I released it, I would want it to
develop.
Drew
========================================
Dr. Drew McCormack (Kmr. R153)
Afd. Theoretische Chemie
Faculteit Exacte Wetenschappen
Vrije Universiteit Amsterdam
De Boelelaan 1083
1081 HV Amsterdam
The Netherlands
Email email@hidden
Telephone +31 20 44 47623
Mobile +31 6 483 21307
Fax +31 20 44 47629
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.