>
> 2. I dont think declaring the sample rate as 'long double' is enough. We
> need to add a portable, object oriented arbritrary precision floating
> point library to LAME. The sample rate should be a default of
> 128 digits, but the user can increase this with suitable
> options.
>
Mathematican:
Arbitrary precission is not enough.
Physist:
Planck time is around 10^-42 s, age of universe is around 10^+18 s,
so 60 decimal digits are good enough.
non C Programmer:
Current CPUs are supporting long double (being 64 or 80 bit) in
hardware, so why we aren't use this.
Assembler Programmer:
How large are the floating point registers? Is there any trick to store
two numbers to increase speed? No?
Video technican:
Films are at most around 4 hours, humans can detect time differences
down to 20 ms, so we need something around 6 decimal digits.
Markedroid:
Reduce precission as long as noone complains.
Advanced Markedroid:
Reduce precission as long as noone charges you.
Professional Markedroid:
Reduce precission as long as income increases.
C Programmer:
Why we are not using a 'int', if we need more precission,
then we can store ms or mHz in ints. Also µs, ms, cs and s/HZ
are possible (see POSIX API).
C++ Programmer:
We need a class ...
Ada programmers:
Don't we have a generic type to store time intervals?
COBOL programmer:
Sample frequencies are between 00000 and 99999 Hz, right?
FORTRAN programmer:
It isn't an index, so I use a REAL.
Rivest:
Can we assume that all sample frequencies can be exactly described by
a/b with a and b being two finite integral numbers with gcm (a,b) := 1 ...
Haskell programmer:
Do we need numbers? You can describe all by sets.
or:
There is really no computation until you want to remove the WAV files
from hard disk.
Perl:
What are types?
> 4. LAME should be converted to C++ or Java. C just is not up to
> the task of distinguishing between 30 different types of integers.
>
Current C (C89 + POSIX) has something around 18 integer types. C99 + POSIX
something around 90 integer types. May be the ISO committee is stupid, may be
they have recognized some problems of the C language.
C89 + POSIX
~~~~~~~~~~~
char signed char unsigned char short unsigned short long unsigned long int
unsigned int size_t ssize_t off_t ptrdiff_t wchar_t ptr_t clock_t time_t
C99 + POSIX
~~~~~~~~~~~
char signed char unsigned char short unsigned short long unsigned long int
unsigned int size_t ssize_t off_t off64_t fpos_t fpos64_t ptrdiff_t wchar_t
wint_t ptr_t clock_t time_t int8_t int16_t int32_t int64_t int128_t uint8_t
uint16_t uint32_t uint64_t uint128_t int_least8_t int_least16_t
int_least32_t int_least64_t int_least128_t uint_least8_t uint_least16_t
uint_least32_t uint_least64_t uint_least128_t int_fast8_t int_fast16_t
int_fast32_t int_fast64_t int_fast128_t int_fast16_t int_fast32_t
int_fast64_t int_fast128_t uint_fast8_t uint_fast16_t uint_fast32_t
uint_fast64_t uint_fast128_t bool ...
Also note: float_t and double_t
And there are also a lot of Unix types out there (having currently fixed sizes):
pid_t, dev_t, ino_t, fsid_t, gid_t, uid_t, mode_t, umode_t, nlink_t, ...
--
Frank Klemm
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
