[DGD]Best way to create datatypes...

[Felix A. Croes]

"Michael J. Bacon" <mj.bacon at gte.net> wrote:

> 	Greetings everyone.  I have been working on a high precision math library
> extension for DGD.  It works pretty good except for the fact that right now
> I have to store the high precision number as a string in LPC objects, ie
> "13.787123912312313351230987871231251121" instead of the custom numeric
> structure that the functions use to actually do the math.  So each time I
> need to do any high precision math I first have to call a function to
> convert the string into the custom data structure, then do my math, then
> output the number as a string and destroy the structure then return the
> string for lpc to display or store in an object string variable....
>
> 	So my question is - what's a better way to do this?  Is there an extendable
> way to add new datatypes to DGD or a way to pass a pointer to this structure
> back and forth from LPC?

DGD 1.2 has room for another value type, but DGD 1.2.19+ doesn't.

There are 3 possible ways to store a new value.  First, you can
incorporate it into the value struct.  A possible problem with this is
that the value struct must be large enough to hold any type, and if
you want it to hold a 64 bit floating point number, then <all> values
will be at least 64 bits in size, including integer values, which
would inflate the mud quite a bit.

The second possibility is to store it in a string.  If so, it is
probably best to store it as the binary image of an IEEE double
value, or the binary image of whatever you are using (take care
with cross-platform issues).

The third possibility is to chop it up into smaller bits, and store
it as an array of (32 bit) ints or (48 bits) floats.

If there is room for a new value type, then you could add your own,
which behaves in a string-like or array-like manner, as noted above.

The simplest solution is probably to keep storing it in strings,
but as a binary number rather than a decimal one.  There is some loss
of precision involved in converting to a different base, and it is
slow.

DGD does not have a simple way to add new types at present, and since
the most recent version does not have room for new value types anyhow,
it is not going to happen in the future.

Regards,
Dworkin

List config page:  http://list.imaginary.com/mailman/listinfo/dgd