Download Reference Manual
The Developer's Library for D
About Wiki Forums Source Search Contact

Complex/imaginary support for tango.text.convert.Float

Moderators: kris

Posted: 02/13/08 11:30:00

As per the title, are there any plans for adding this functionality?

I was going to have a go at adding this, but want to ask a few questions first:

1: I noticed this comment on format():

TODO: this should be replaced, as it is not sufficiently accurate

Does this mean the function is soon to be replaced? Will the replacement only affect the function internals or will it also affect the arguments and the way the function should be used? Or is there as-yet no-one intending on replacing this?

2: What should be the syntax for complex types upon which the conversion functions should work? One thing I've noticed about some of tango's text<->int/float conversion functions is that they don't always document the exact syntax used and don't exactly correspond to D's syntax (although some changes like the octal prefix definitely make sense). Also hex floats aren't currently supported which might be nice (although I don't know if it would be very useful). Should we stick to the D syntax closely? One thing of note is that whitespace between arguments may be expected to be different for different situations; e.g. to conform to what trim does it should probably only be ' ' or '\t' but with a larger parser using such a function, but regarding '\n', '\r', etc. as whitespace for it's own syntax, (which is something I'm working on) an inconsistent and confusing syntax would result. Hence maybe there could be an option specifying what whitespace is considered as for both Integer.trim and the complex-parsing function (just ' ' and '\t' or everything Util.isSpace considers whitespace)?

3: Err... can't remember my third question.

Hmm... well I don't suppose complex parse and format functions need to know exactly how float parse/format functions work anyway, but I wanted to check what was being worked on and was planned.

Author Message

Posted: 02/13/08 12:39:57

Cyborg16 wrote:

As per the title, are there any plans for adding this functionality?

I was going to have a go at adding this, but want to ask a few questions first:

1: I noticed this comment on format():

TODO: this should be replaced, as it is not sufficiently accurate

Does this mean the function is soon to be replaced? Will the replacement only affect the function internals or will it also affect the arguments and the way the function should be used? Or is there as-yet no-one intending on replacing this?

The usage should not change, the implementation just needs to be more accurate (without degrading performance). There are not specific plans as we don't know the perfect algorithm to use yet.