Re: Charting solutions
Re: Charting solutions
- Subject: Re: Charting solutions
- From: John Anderson <email@hidden>
- Date: Wed, 2 Apr 2003 13:01:13 -0500
On Wednesday, Apr 2, 2003, at 01:37 America/Detroit, Drew McCormack
wrote:
>
I fully agree that XYPlot will meet most needs in terms of quickly
>
throwing together a scatter plot or histogram, but I think it will not
>
be that easy to extend if it doesn't quite meet your requirements.
>
Narrative was designed for this type of evolution.
>
I agree. I think Narrative is a broader-based project, that could
>
offer plotting solutions for people in wider fields.
Then perhaps you will release Narrative, when you are convinced it will
be appropriately developed by the community.
>
NSValueArray is basically just NSData with typed data. It's very
>
useful, but what I would love to see is a multidimensional array
>
class, like what is found in python. That would be really powerful for
>
scientific programming.
I think all we need to do here is to sub-class NSValueArray to
something like NSValueNArray (for n - dimesionsal arrays).
Then all that is basically needed are two simple algorithms that
convert n - dimensional coordinates to 1 - dimension, and vice versa.
Obviously, any n - dimensional array can be represented in 1 dimension
and indeed must be done so with Cocoa memory architecture.
Going in the other direction, with an eye towards graphing, we could
also subclass NSValueArray to something like NSTupleArray, where each
"value" is now a data structure of n - values of different data-types.
However, I am not entirely comfortable using the "NS" prefix for class
that I develop, as I think that this designation has been been reserved
by Apple. Maybe we should use the designation "NF" for our numerical
foundation?
I find Sean Hll's discussion of memory issues related to NSValueArray
interesting:
// Under FoundationKit, you could use an NSArray of NSValue instances
// to achieve somewhat the same effect as a Storage under earlier
// versions of NeXTSTEP. One major difference is that if all of
// the values in the array are of the same type, Storage is more
// space-efficient because it doesn't require the extra object
// overhead. [The NSArray+NSValue version requires 1+N objects,
// while Storage requires 1 object.] Furthermore, the NSArray+NSValue
// version will require about 2+2N separate mallocs, while the
// Storage version only requires 2 mallocs. [Each malloc has some
// overhead, and on some systems may have more overhead due to
// memory granularity concerns.]
//
// For small systems, this is reasonable. But for large systems,
// it is not.
// There is also certainly performance tuning which could be done.
He is clearly is not satisfied with the memory allocation performance
in "large systems." So this, makes me wonder if it will ultimately be
necessary to rewrite NSValueArray in pure C?
// The archiving format is exactly that of NSArray. This ability
depends on
// the existence of the function NSGetSizeAndAlignment(). The archive
written
// by this object can be read by an NSArray transparently. If you
choose to load a
// prearchived NSArray or NSMutableArray using a NSValueArray it must
have contained
// only NSValues of the same type. These will then be stored
internally in an efficient
// manner. These could be stored more efficiently however the
convenience of having
// an archive format identical to that of NSArrays was too alluring.
However, I do not understand what the benefit of having an archive
format identical to NSarray is.
- John
_______________________________________________
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.