Charles R Harris wrote: > > > On 2/27/07, *Travis Oliphant* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Charles R Harris wrote: > > > > > > The problem is that we aren't really specifying floating-point > > standards, we are specifying float, double and long double > as whatever > > the compiler understands. > > > > There are some platforms which don't follow the IEEE 754 > standard. > > This format specification will not be able to describe > > platform-independent floating-point descriptions. > > > > It would be nice to have such a description, but that is not > what > > struct-style syntax does. Perhaps we could add it in the > > specification, > > but I'm not sure if the added complexity is worth holding it > up over. > > > > > > True enough, and it may not make that much sense until it is in > the c > > standard. But it might be nice to reserve something for the > future and > > maybe give some thought of how to deal with new data types as they > > come along. I can't think of any really flexible methods that don't > > require some sort of verbose table that goes along with the > data, and > > the single letter codes are starting to get out of hand. Hmmm. It > > would actually be nice to redo things so that there was a > prefix, say > > z for complex, f for float, then something for precision. The > > designation wouldn't be much use without some arithmetic to go > with it > > and it doesn't make sense to write code for things that don't > exist. I > > wonder how much of the arithmetic can be abstracted from the > data type? > > I suspect we may have to do this separately in the NumPy world. > Perhaps we could get such a specification into Python itself, but I'm > not hopeful. Notice, though that we could use the struct syntax to > specify a floating-point structure using the bit-field and naming. > > In other words an IEEE 754 32-bit float would be represented in > struct-style syntax as > > '>1t:sign: 8t:exp: 23t:mantissa:' > > > That would probably do nicely. There are potential ambiguities but > nothing worth worrying about. Is there a way to assign names to such a > type? I suppose that it is just another string constant so one could > write something like > > float32 = '>1t:sign: 8t:exp: 23t:mantissa:' > > and use that. Can those bit fields be of arbitrary length? > > Now for something completely different ;) In some things, like the > socket module, it is possible to ask for a filelike interface which > buffers the input and has the usual read, readline, etc function > interface, but fromfile doesn't work with it. This isn't a biggie and > I suppose fromfile is looking for a 'real' file, but I wonder if this > would be a difficult thing to implement? I could look at the code but > I thought I would ask you first.
The problem here is that fromfile is using the raw stdio fscanf commands which require an actual file id. It is not using the Python-level fread. It's pretty low-level. On the other-hand there is the fromstring approach which works with any stream. I suspect a function that uses one or the other could be implemented. The relevant functions are XXXX_scan and XXX_fromstr in arraytypes.c.src These are used for each data-type. Notice that PyArray_FromFile actually requires a FILE *fp pointer. You might be able to use PyArray_FromString which allows a char * to read data from. -Travis > > Chuck > > > ------------------------------------------------------------------------ > > _______________________________________________ > Numpy-discussion mailing list > [email protected] > http://projects.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
