Euler - Gamma for Complex - interesting enough for a DLL ?

[RobbeK]

Hi all,

Been busy with some other things, but just tested the FBmath (Mr Jean Debord - http://sourceforge.net/projects/fbmath/ )
Everything standard with the Bureau des statistiques etc.. (seems excellent)

The module doesn't output CGamma directly but LnGamma -- but it's easy to convert.
As for the program (in FB for the moment) , you can zoom, rotate etc...

Interesting to see the poles at the negative integers (-n)! -> inf (the real axis is in the middle).

Interesting to make these available in TB ?


best Rob

[mike lobanovsky]

Hi Rob,


Interesting to make these available in TB ?

Every little thingy that has such a nice-looking graphical output as this one is certainly worthy of being translated to TB just in case it attracts the attention of some casual passer-by like e.g. me.http://www.fbsl.net/phpbb2/images/smilies/icon_biggrin.gif

Many anonymous guests popping up here every day may potentially become TB users and fans due to just being once attracted by some such awesome visual.

Have a Happy New Year!

http://www.fbsl.net/phpbb2/images/smilies/icon_ml_noel.gif

[RobbeK]

Thanks Mike,

There's also an excellent module doing Fourier transformations (both the Gamma and Fourier are practical tools with many applications) ...
(and the step to the Zeta is somewhat easier now .. )
What surprised me the most (it are of course not all Mike's, Eros's , Charles's, Petr's , John's (and those who I'm unintended forgetting now) wandering the world wide web) ... - while searching alternatives , is that most don't even mention where their function is defined - (hmm , infact they even do not mention if it is expandable into the complex plane etc ... ).
-- one has to be very careful with such things , especially when publishing on Wikipedia.
Reading the code of FBmath is a joy, even the NaN's are predifined -- seems crashproof.

С Новым Годом !! Rob

[ErosOlmi]

Also reading fbmath.pdf manual is a joy.

Thanks for letting us know about this lib: a source of inspiration developed in perfectly reading Basic code.
A would say: a double joy.

[RobbeK]

Eros, (or any one else who knows) ,
How free am I with this code - if I write a DLL , is it personal use only, and / or can this be shared on a forum like this one.


thanks in advance

(adding fast Fourier Tr. into TB could attract certain people imo ).

felix sit annus novus !! (don't speak Italian , but got some Latin - looong time ago)

[ErosOlmi]

eheh I studied latin for 5 years at high school but now ... I just remember first singular declination of "rosa" end few poems :D

Not sure to have understood well the question ... anyway I will try to reply.

Writing a generic DLL is always possible and publishing it here is welcome. To be used in thinBasic it should be just a matter of function declaration and parameters passing.

thinBasic modules instead are special DLL that must follows some thinBasic specific rules and are responsible of parsing script source code:

there are some examples in \thinBasic\SDK\ directory
there are some info in Petr thinBasic Journal issue 2 at http://www.thinbasic.com/community/showthread.php?t=9450
or we can start a discussion


If you want to make a derivative work from FBMath library is another matter.
There will be some restrictions due to the licence used by FBMath and thinBasic licence but it will depend if such derivative work will be distributed or not with thinBasic setup.

Having a FFT function in thinBasic would be fantastic of course.

[mike lobanovsky]

Volentem ducunt fata, nolentem - trahunt!
http://www.fbsl.net/phpbb2/images/smilies/icon_ml_burn.gif

[RobbeK]

Anyway fata vocant !!

but , about ... what is it that makes floating point formats/representations incompatible between specific DLL's and specific programming languages ?
I know about IEEE and MBF - remember something about big/little Endian (from Lisp) , but it's something else not ? -- I have problems with these (never had problems with integers/words/long .. these signed / unsigned etc ... ).

Rob

[Billbo]

I like your program very much!!!

Could you provide the source?

Bill

[mike lobanovsky]

Anyway fata vocant !!
Absolutely! http://www.fbsl.net/phpbb2/images/smilies/icon_biggrin.gif

The FPU capabilities of a language may also depend on what the language core is written in or linked against.

For example, PowerBASIC is hand-coded assembly. thinBasic is coded in PowerBASIC. x86/i387 FPU calc is always done internally with 80-bit precision in the FPU registers however such quantities can only be loaded on the FPU stack and popped from there but not used directly as in-memory operands. These can only be 32- and 64-bit floating point or integer quantities. But this is sufficient for both PowerBASIC and thinBasic to have an extended precision floating point data type - Currency. It is somewhat slower than pure 32- and 64-bit decimals as it needs to be first loaded into the FPU registers from memory rather than used as direct operands but it sometimes is a tolerable compromise for some more precision-critical calc.

OTOH FBSL is linked against the very basic msvcrt.dll system library which not only has no equivalent to Currency but neither does it support complex numbers or a long double data type. Hence FBSL which is a general-purpose programming language is limited to 32-bit Single and 64-bit Double FPU calc only.

Other languages may have yet other reasons for FPU incompatibilities especially when ported to harware platforms other than the ones they've been originally created for. However such general-purpose languages as either thinBasic or FBSL are unlikely to be used for plotting ballistic missile trajectories between the Kremlin and the White House, after all. http://www.fbsl.net/phpbb2/images/smilies/icon_biggrin.gif

[ErosOlmi]

Talking for thinBasic ...

all internal numeric calculations (even the integer ones) are done using EXTENDED (https://en.wikipedia.org/wiki/Extended_precision) floating point data types.

Every time there is a numeric expression, thinBasic perform the following:

all numbers used in expressions are firstly transformed into EXTENDED numbers
than the internal calculations are done
than the result is transformed into the destination data type required by the expression (user defined in the script)


The same is done when passing numeric data into external (DLL) functions:

script expressions representing the function parameters are first transformed into an EXT data type
the EXT data type is than transformed into the destination parameter data type defined by the external function declaration just before passing it into the stack


This ensures that there is no data lost unless the final destination variable is not big enough to get back the result of the expression.

[mike lobanovsky]

John,

gdb is indeed a very, very good tool but luckily it is also available under Windows. I'm using it occasionally in my MinGW/GCC setup to debug the most discouraging glitches that can't be traced and isolated by any other instrument at my disposal. I couldn't resist mentioning it here although it's most certainly downright off topic.

Let's leave it to Rob to decide if we've gone too far; he was the topic starter, after all.

[mike lobanovsky]

Hmmmm Eros,

I presume you realize that emulating e.g. integer division or multiplication by a power of 2 - in fact, an extremely fast right or left bitshift - on the FPU via 80-bit extended calc is plain shooting oneself in the foot, speed-wise? Integer calc can't lose precision when being done in general-purpose registers and even integer division leaves its modulo in edx so theres no loss whatsoever.

Adding an integer to an integer takes just one CPU cycle or even half a cycle if the instructions are properly paired in a modern Pentium's pipes. Emulating the same on the FPU will probaly take dozens if not hundreds of non-pairable cycles lost for nothing.

[ErosOlmi]

Yes I know but thinBasic is a continuous interpreter of the source code without intermediate code.

Checking at every step what numeric type a token representing a numeric variable is and making optimization on the fly when, for example inside a loop, is much more time consuming than letting the processor making some unnecessary calculations.

A compiler or an interpreted language that creates an intermediate step (PCODE) can do that job because they would do it just once.

Maybe this is a strong limitation of thinBasic but that's it.

[mike lobanovsky]

No problem Eros,

Having a nimble twin bro like Oxygen around makes thinBasic bullet-proof against any criticism. http://www.fbsl.net/phpbb2/images/smilies/icon_biggrin.gif

[RobbeK]

"as either thinBasic or FBSL are unlikely to be used for plotting ballistic missile trajectories between the Kremlin and the White House, after all. "

Well, there comes a day they need to update their COBOL - never say never ;-)

-----------------

Thanks Bill, the code is (as we say) - two times nothing. I extended it a little , now the space switches between |z| , |R(z)| , |I(z)| .. more fun.

Eros, John , Mike etc .. is a roundabout as using strings as communcator between lib <-> prog a worthy solution of just waste of time ?
(I mean numbers coded to strings and then decoded).

Ah, yes , did not use GLlists in the little prog - Petr can answer this, but I do think the lists are more memory consuming then walking through an array. (they stack 3 coordinates, not ?) -- I mean, in non interpreted languages the benefit will rather minimal ???

best Rob

[ErosOlmi]

Eros, John , Mike etc .. is a roundabout as using strings as communcator between lib <-> prog a worthy solution of just waste of time ?
(I mean numbers coded to strings and then decoded).


At the end it is just a matter of piece of memory interpreted in one way or the other: a LONG are four bytes interpreted as number but at the end that same 4 bytes can be 4 ASCII chars or 4 single bytes or an array of 4 strings of 1 char, or an array of two integers (16 bits) :)

As far as results are OK and efficiency is not a bottle neck ... why not.

thinBasic as an efficient way to cast "virtual variables" over some piece of memory:
DIM <variable name> AS <variable type>... AT <memory pointer>
"Vitual variables" are variable not having any local memory allocated but use memory allocated somewhere by someone else.
In thinBasic the speed of "virtual variables" are identical to the standard ones.

[RobbeK]

Ah, thanks Eros ...

""Vitual variables" are variable not having any local memory allocated but use memory allocated somewhere by someone else."
(Well, I know some people with more or less similar behaviour ;-) (self-mockery)

best Rob

(c I'm able to make the euler2 running from within TB/TBGL)

[mike lobanovsky]

Hello Rob,

By all means, what Eros calls "virtual variables" in thinBasic is an extremely handy feature and using the "At" operator directly in a declaration is indeed a very elegant solution. C equivalents to TB's "virtual variables" would be called dereference, indirection, or type cast depending on the situation.

FBSL also has several historical ways to dereference a variable:



' explicit strict typing is purely exemplary here
Dim a As Long = 123, b As String = ""

' Ex.1 - permanent dereferencing; b acquires data type of a
' and may become e.g. an UDT, a class instance or even a function
ReferenceOf b = a ' b is set to reference a's memory location and acquires its type

' Ex.2 - permanent indirection; b preserves its own data type
PointerOf b = PointerOf a ' ... or its equivalent shorthand below:
@b = @a ' b is set to reference a's memory location but preserves an own type

' Ex.3 - temporary cast to another data type in current occurence only
b = $a ' treats a as a string literal "123" and assigns this value to b


Some such conversions for simple data types can however be done by FBSL automatically depending on the nature of the expression the variables are used in. Explicit dereferencing through ReferenceOf and PointerOf operators frees the variable's former memory automatically while type casting doesn't (and shouldn't).

Regarding OpenGL display lists, you shouldn't underestimate their efficacy. In fact, they are the only reason why immediate-mode OpenGL is still alive and kicking in the era of Cg, HLSL, and GLSL. Display lists precompile a sequence of assorted OpenGL function calls on the GPU and may speed up rendering up to 20 times if your OpenGL drivers are up-to-date. Don't worry about a display list's memory footprint. That would be in your video card's VRAM and that's exactly what your VRAM is there for. http://www.fbsl.net/phpbb2/images/smilies/icon_biggrin.gif

[RobbeK]

Hi Mike,

Thanks -- yep, you're right -- I'm still thinking in decade-ago quantities. I only have 64Mb VRAM , but a quick calculation shows there's plenty of room left (3 arrays of 10000 coordinates) ... (I think to remember in the 1970s I paid around 25€ for 1 Kb RAM ;-) .. Rockwell IIRC and later ACORN ... I even think the Rockwell could only do JP's of max 256 -- you had to make "ladders" if more was needed.

best Rob