Hi.
I was making a bignum package in C++ for a program I've got, that will
generate images of fractals. Currently, it has two parts: a "raw"
unsigned integer type, and a big floating point type, the latter of
which is used to do all the fractal calculations. The purpose of a
bignum package is to allow for deep zooming (beyond the range of
hardware floating point). Although it's obviously going to be really
slow, it does allow for that deep stuff that I want.
But I'm wondering about how to set this up. The question I have right
now is should the big floating point type be a derived class (ie. use
inheritance) from the raw integer type, or should it just include an
object of type raw integer in it?
9  1327 
"mike3" <mi******@yahoo.comwrote in message
news:11*********************@t8g2000prg.googlegrou ps.com...
Hi.
I was making a bignum package in C++ for a program I've got, that will
generate images of fractals. Currently, it has two parts: a "raw"
unsigned integer type, and a big floating point type, the latter of
which is used to do all the fractal calculations. The purpose of a
bignum package is to allow for deep zooming (beyond the range of
hardware floating point). Although it's obviously going to be really
slow, it does allow for that deep stuff that I want.
But I'm wondering about how to set this up. The question I have right
now is should the big floating point type be a derived class (ie. use
inheritance) from the raw integer type, or should it just include an
object of type raw integer in it?
There are already a number of big number libraries out there for this type
of thing. Rather than reinvent the wheel, why don't you try to find one you
like? I believe boost has one also.
Hmm.. I went to boost site and dont' see a big number library.
Googling for "bignum floating point c++" gave some good hits, one was for
GMP. http://gmplib.org/
I haven't used it but it's an arbitrary length big num library.
mike3 wrote:
Hi.
I was making a bignum package in C++ for a program I've got, that will
generate images of fractals. Currently, it has two parts: a "raw"
unsigned integer type, and a big floating point type, the latter of
which is used to do all the fractal calculations. The purpose of a
bignum package is to allow for deep zooming (beyond the range of
hardware floating point). Although it's obviously going to be really
slow, it does allow for that deep stuff that I want.
But I'm wondering about how to set this up. The question I have right
now is should the big floating point type be a derived class (ie. use
inheritance) from the raw integer type,
Probably not.
or should it just include an object of type raw integer in it?
I take it that you represent a float by an integer part and some additional
data that give you a fractional part. In that case, an integer data member
is the most natural and cleanest way to go.
With regard to inheritance, you have essentially two options:
a) public inheritance. That would expose the integer part of your float to
independent manipulation (essentially like making the integer data member
public, BadIdea(tm)). On top of that, you get into all sorts of trouble
with pointers to integer objects that now could point to floats, and more
importantly, your float type would match any function
integer some_function ( integer const & )
which you probably don't want.
b) private inheritance. That does not have the problems from (a), but in
this case it wouldn't buy you anything. It will just obscure the code.
BTW: why do you reinvent the wheel? There are decent bignum libraries out
there, and it will be very hard to beat them performance-wise.
Best
Kai-Uwe Bux
On 8 , 10:24, Kai-Uwe Bux <jkherci...@gmx.netwrote:
a) public inheritance. That would expose the integer part of your float to
independent manipulation (essentially like making the integer data member
public, BadIdea(tm)). On top of that, you get into all sorts of trouble
with pointers to integer objects that now could point to floats, and more
importantly, your float type would match any function
integer some_function ( integer const & )
which you probably don't want.
I think matching floats in integer funtions is the thing one likely
does want. That's done not by inheritance (which won't work in the
way you expect floats to act as integers), but by specifying user-
defined typecast rather.
Pavel Shved wrote:
On 8 , 10:24, Kai-Uwe Bux <jkherci...@gmx.netwrote:
>a) public inheritance. That would expose the integer part of your float
to independent manipulation (essentially like making the integer data
member public, BadIdea(tm)). On top of that, you get into all sorts of
trouble with pointers to integer objects that now could point to floats,
and more importantly, your float type would match any function
integer some_function ( integer const & )
which you probably don't want.
I think matching floats in integer funtions is the thing one likely
does want. That's done not by inheritance (which won't work in the
way you expect floats to act as integers), but by specifying user-
defined typecast rather.
I am not sure that I want floats to silently match integer functions. Have a
look at the return type. For a simple function like
integer sqr ( integer const & i ) {
return ( i*i );
}
the result could be rather surprising when you feed in a float. Life will
get even more surprising if you also provide a conversion constructor
interger -float. Then, you could do:
float a = ...
a = sqr( a );
and what you get is not exactly what you see.
Best
Kai-Uwe Bux
On Nov 8, 11:58, Kai-Uwe Bux <jkherci...@gmx.netwrote:
Pavel Shved wrote:
On 8 , 10:24, Kai-Uwe Bux <jkherci...@gmx.netwrote:
a) public inheritance. That would expose the integer part of your float
to independent manipulation (essentially like making the integer data
member public, BadIdea(tm)). On top of that, you get into all sorts of
trouble with pointers to integer objects that now could point to floats,
and more importantly, your float type would match any function
integer some_function ( integer const & )
which you probably don't want.
I think matching floats in integer funtions is the thing one likely
does want. That's done not by inheritance (which won't work in the
way you expect floats to act as integers), but by specifying user-
defined typecast rather.
I am not sure that I want floats to silently match integer functions. Have a
look at the return type. For a simple function like
integer sqr ( integer const & i ) {
return ( i*i );
}
the result could be rather surprising when you feed in a float. Life will
get even more surprising if you also provide a conversion constructor
interger -float. Then, you could do:
float a = ...
a = sqr( a );
and what you get is not exactly what you see.
I see the following: float variable is passed to an integer function
and i expect the same behaviour as with intrinsic C++ types. And i do
get it. Of course if you don't like this endeavour you may fix it
out, but i prefer writing intgrality-indepentent functions with
templates, like
template <typename TT sqr (T const& _t)
{
return _t*_t;
}
, letting integers calculated with aid of floating algorithms fit to
greates-common-divisor functions or something with no explicit
conversions.
On Nov 8, 7:44 am, Pavel Shved <Pavel.Sh...@gmail.comwrote:
On Nov 8, 11:58, Kai-Uwe Bux <jkherci...@gmx.netwrote:
Pavel Shved wrote:
On 8 , 10:24, Kai-Uwe Bux <jkherci...@gmx.netwrote:
>a) public inheritance. That would expose the integer part of your float
>to independent manipulation (essentially like making the integer data
>member public, BadIdea(tm)). On top of that, you get into all sorts of
>trouble with pointers to integer objects that now could point to floats,
>and more importantly, your float type would match any function
> integer some_function ( integer const & )
>which you probably don't want.
I think matching floats in integer funtions is the thing one likely
does want. That's done not by inheritance (which won't work in the
way you expect floats to act as integers), but by specifying user-
defined typecast rather.
I am not sure that I want floats to silently match integer functions. Have a
look at the return type. For a simple function like
integer sqr ( integer const & i ) {
return ( i*i );
}
the result could be rather surprising when you feed in a float. Life will
get even more surprising if you also provide a conversion constructor
interger -float. Then, you could do:
float a = ...
a = sqr( a );
and what you get is not exactly what you see.
I see the following: float variable is passed to an integer function
and i expect the same behaviour as with intrinsic C++ types. And i do
get it. Of course if you don't like this endeavour you may fix it
out, but i prefer writing intgrality-indepentent functions with
templates, like
template <typename TT sqr (T const& _t)
{
return _t*_t;
}
, letting integers calculated with aid of floating algorithms fit to
greates-common-divisor functions or something with no explicit
conversions.
_t ?
On Nov 8, 12:24 am, Kai-Uwe Bux <jkherci...@gmx.netwrote:
mike3 wrote:
Hi.
I was making a bignum package in C++ for a program I've got, that will
generate images of fractals. Currently, it has two parts: a "raw"
unsigned integer type, and a big floating point type, the latter of
which is used to do all the fractal calculations. The purpose of a
bignum package is to allow for deep zooming (beyond the range of
hardware floating point). Although it's obviously going to be really
slow, it does allow for that deep stuff that I want.
But I'm wondering about how to set this up. The question I have right
now is should the big floating point type be a derived class (ie. use
inheritance) from the raw integer type,
Probably not.
or should it just include an object of type raw integer in it?
I take it that you represent a float by an integer part and some additional
data that give you a fractional part. In that case, an integer data member
is the most natural and cleanest way to go.
With regard to inheritance, you have essentially two options:
a) public inheritance. That would expose the integer part of your float to
independent manipulation (essentially like making the integer data member
public, BadIdea(tm)). On top of that, you get into all sorts of trouble
with pointers to integer objects that now could point to floats, and more
importantly, your float type would match any function
integer some_function ( integer const & )
which you probably don't want.
b) private inheritance. That does not have the problems from (a), but in
this case it wouldn't buy you anything. It will just obscure the code.
This makes more sense. Furthermore, in my case I
was talking about using (b). This is the discussion
that inspired the idea: http://groups.google.com/group/comp....6278b77597d648
The part that is relevant here is this:
"The Init functions are *pnly* and I say again, *ONLY*
called in CONSTRUCTORS, period. And *always* called from
them. They're just there to save a bit of cutting-and-
pasting. At no point are they called anywhere else.
By expressing them as constructors (of e.g. a private base class) you
express that in code, /ensuring/ that they're not called from anywhere
else, and so making it completely safe to remove initialization
checks. "
(The "Init" fns mentioned, by the way, were to
initialize the BigFloats, allocate memory for the
digits, etc. This discussion revolved around an
older implementation of big floating arithmetic
and part of the fractal program that I was having
a tough bug with.)
In response to this, I thought, "Hey! Let's make
a 'raw integer' type that will be inherited,
since when one says 'base class' that implies
'inherited', by the big floating point type,
and it'll be private. And we'll use std::vector
like he says to go and encapsulate the digit array!
This 'raw integer' thing will then alleviate the
need for those annoying 'Init' functions plus
handle the arithmetic on the digits to boot
as well.", insofar as implementing the big number
arithmetic part of the program goes.
BTW: why do you reinvent the wheel? There are decent bignum libraries out
there, and it will be very hard to beat them performance-wise.
Well, for one, I'd own all the copyrights this way.
For another, I do not need to *beat* them, either.
Even getting a significant fraction of their performance
would be acceptable.
Best
Kai-Uwe Bux
Pavel Shved wrote:
On Nov 8, 11:58, Kai-Uwe Bux <jkherci...@gmx.netwrote:
>Pavel Shved wrote:
On 8 , 10:24, Kai-Uwe Bux <jkherci...@gmx.netwrote:
>a) public inheritance. That would expose the integer part of your
float to independent manipulation (essentially like making the integer
data member public, BadIdea(tm)). On top of that, you get into all
sorts of trouble with pointers to integer objects that now could point
to floats, and more importantly, your float type would match any
function
> integer some_function ( integer const & )
>which you probably don't want.
I think matching floats in integer funtions is the thing one likely
does want. That's done not by inheritance (which won't work in the
way you expect floats to act as integers), but by specifying user-
defined typecast rather.
I am not sure that I want floats to silently match integer functions.
Have a look at the return type. For a simple function like
integer sqr ( integer const & i ) {
return ( i*i );
}
the result could be rather surprising when you feed in a float. Life will
get even more surprising if you also provide a conversion constructor
interger -float. Then, you could do:
float a = ...
a = sqr( a );
and what you get is not exactly what you see.
I see the following: float variable is passed to an integer function
and i expect the same behaviour as with intrinsic C++ types. And i do
get it.
A problem is of course that you would need to remember exactly which
function are integer and which are not. When you see gcd() or sin(), it's
probably not a problem. But for something like sqr() it becomes more iffy;
and I don't even want to think about operators like a*b.
In fact, I don't think that mimicking the behavior of built-in numeric types
is that good an idea: (a) it's not feasible to copy their behavior exactly
because overload resolution and user-defined conversions behave different
from promotion and arithmetic conversion rules; and (b) even for the
built-in types it causes all sorts of headaches (like when you mix signed
and unsigned types).
Of course if you don't like this endeavour you may fix it
out, but i prefer writing intgrality-indepentent functions with
templates, like
template <typename TT sqr (T const& _t)
{
return _t*_t;
}
I usually do the same.
, letting integers calculated with aid of floating algorithms fit to
greates-common-divisor function or something with no explicit conversions.
but I don't understand this part.
Best
Kai-Uwe Bux
On Nov 8, 2:32 pm, mike3 <mike4...@yahoo.comwrote:
On Nov 8, 12:24 am, Kai-Uwe Bux <jkherci...@gmx.netwrote:
mike3 wrote:
Hi.
I was making a bignum package in C++ for a program I've got, that will
generate images of fractals. Currently, it has two parts: a "raw"
unsigned integer type, and a big floating point type, the latter of
which is used to do all the fractal calculations. The purpose of a
bignum package is to allow for deep zooming (beyond the range of
hardware floating point). Although it's obviously going to be really
slow, it does allow for that deep stuff that I want.
But I'm wondering about how to set this up. The question I have right
now is should the big floating point type be a derived class (ie. use
inheritance) from the raw integer type,
Probably not.
or should it just include an object of type raw integer in it?
I take it that you represent a float by an integer part and some additional
data that give you a fractional part. In that case, an integer data member
is the most natural and cleanest way to go.
With regard to inheritance, you have essentially two options:
a) public inheritance. That would expose the integer part of your float to
independent manipulation (essentially like making the integer data member
public, BadIdea(tm)). On top of that, you get into all sorts of trouble
with pointers to integer objects that now could point to floats, and more
importantly, your float type would match any function
integer some_function ( integer const & )
which you probably don't want.
b) private inheritance. That does not have the problems from (a), but in
this case it wouldn't buy you anything. It will just obscure the code.
This makes more sense. Furthermore, in my case I
was talking about using (b). This is the discussion
that inspired the idea:
http://groups.google.com/group/comp....6278b77597d648
The part that is relevant here is this:
"The Init functions are *pnly* and I say again, *ONLY*
called in CONSTRUCTORS, period. And *always* called from
them. They're just there to save a bit of cutting-and-
pasting. At no point are they called anywhere else.
By expressing them as constructors (of e.g. a private base class) you
express that in code, /ensuring/ that they're not called from anywhere
else, and so making it completely safe to remove initialization
checks. "
(The "Init" fns mentioned, by the way, were to
initialize the BigFloats, allocate memory for the
digits, etc. This discussion revolved around an
older implementation of big floating arithmetic
and part of the fractal program that I was having
a tough bug with.)
In response to this, I thought, "Hey! Let's make
a 'raw integer' type that will be inherited,
since when one says 'base class' that implies
'inherited', by the big floating point type,
and it'll be private. And we'll use std::vector
like he says to go and encapsulate the digit array!
This 'raw integer' thing will then alleviate the
need for those annoying 'Init' functions plus
handle the arithmetic on the digits to boot
as well.", insofar as implementing the big number
arithmetic part of the program goes.
BTW: why do you reinvent the wheel? There are decent bignum libraries out
there, and it will be very hard to beat them performance-wise.
Well, for one, I'd own all the copyrights this way.
For another, I do not need to *beat* them, either.
Even getting a significant fraction of their performance
would be acceptable.
Any commment? This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Mike |
last post by:
I am sure that I am making a simple boneheaded mistake and I would
appreciate your help in spotting in. I have just installed
apache_2.0.53-win32-x86-no_ssl.exe
php-5.0.3-Win32.zip...
|
by: edgrsprj |
last post by:
PROPOSED EARTHQUAKE FORECASTING
COMPUTER PROGRAM DEVELOPMENT EFFORT
Posted July 11, 2005
My main earthquake forecasting Web page is:
http://www.freewebz.com/eq-forecasting/Data.html
...
|
by: Tom Lee |
last post by:
Hi,
I'm new to .NET 2003 compiler. When I tried to compile my
program using DEBUG mode, I got the following errors in the
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7
\include\xdebug...
|
by: christopher diggins |
last post by:
I am wondering if any can point me to any open-source library with program
objects for C++ like there is in Java? I would like to be able to write
things like
MyProgram1 >> MyProgram2 >>...
|
by: Eric Whittaker |
last post by:
hi all,
im trying to write my first c++ program. a success, but i can't get the
window to stay open after user enters input. it just automatically closes.
right now the end of my program looks...
|
by: Hemal |
last post by:
Hi All,
I need to know the memory required by a c program. Is there any
tool/utility which can give me the memory usage in terms of DATA
segment, TEXT segment, BSS segment etc.
I am working...
|
by: ibtc209 |
last post by:
I just started programming in C, and I need some help with this problem.
Your program will read the information about one MiniPoker hand, namely the rank and suit of the hand’s
first card, and...
|
by: Banfa |
last post by:
Posted by Banfa
The previous tutorial discussed what programming is, what we are trying to achieve, the answer being a list of instructions constituting a valid program. Now we will discuss how...
|
by: amitpatel66 |
last post by:
There is always a requirement that in Oracle Applications, the Concurrent Program need to be execute programatically based on certain conditions/validations:
Concurrent programs can be executed...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
