|Anonymous | Login | Signup for a new account||2017-02-21 22:01 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000037||OCaml||OCaml general||public||2000-02-14 22:00||2001-06-25 10:10|
|Target Version||Fixed in Version|
|Summary||0000037: feature wish: uninitialized unboxed arrays|
|Description||Full_Name: Markus Mottl|
Submission from: ballater.dai.ed.ac.uk (220.127.116.11)
would it be easily possible to provide for functions in the
"Array"-module which allocate unboxed integer- and float-arrays
without initializing them (similar to "String.create")?
This would allow twice as fast reallocations when implementing
resizable arrays for such data types.
Because this might lead to illegal representations of the numbers,
these functions should probably be in the "unsafe" part.
|Tags||No tags attached.|
> would it be easily possible to provide for functions in the
> "Array"-module which allocate unboxed integer- and float-arrays
> without initializing them (similar to "String.create")?
For float arrays, this would be no problem. For int arrays, it's
harder, because those uninitialized int arrays should be tagged
specially so as to prevent the GC from scanning them for pointers.
This special tagging (e.g. as Abstract_tag) would cause generic
polymorphic functions such as equality, hashing and output_value to
produce wrong results.
> Because this might lead to illegal representations of the numbers,
> these functions should probably be in the "unsafe" part.
Reading from an uninitialized float arrays could certainly return NaNs
("not a number"). The so-called "quiet" NaNs cause no problem, they
just propagate through all floating-point operations. But there might
be some problems with "signalling" NaNs (if the processor implements
- Xavier Leroy
The new Bigarray module partially answers this wish.
|2005-11-18 10:14||administrator||New Issue|
|Copyright © 2000 - 2011 MantisBT Group|