News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

Fast Exp approximation

Started by guga, August 12, 2020, 12:29:23 AM

Previous topic - Next topic

jj2007

Quote from: guga on August 12, 2020, 08:45:29 PMI see this:

I actually meant "what kind of pattern do you see, and how could we use it to fumble mantissa and exponent"

QuoteBtw..how you managed to create this curve window ? I like that a lot :thumbsup: :thumbsup: :thumbsup: :thumbsup:

See ArrayPlot in the help file. All you need is an array:

Event Paint
  ArrayPlot MyData(), RgbCol(200, 255, 255, 0), lines=4
  ArrayPlot exit, "Exponential function"

Siekmanski

Hi Guga,

You said: MY main concern is about precision.
So, a very fast Chebyshev polynomial approximation is out of the question?

For what purpose do you need the Exp function?
Creative coders use backward thinking techniques as a strategy.

guga

Quote from: Siekmanski on August 12, 2020, 09:05:31 PM
Hi Guga,

You said: MY main concern is about precision.
So, a very fast Chebyshev polynomial approximation is out of the question?

For what purpose do you need the Exp function?

Hi Marinus

It depends of the level of precision of the Chebyshev polynomial. I think it´s usefull for what we are doing. Even considering some loss of precision, it seems to me, it won´t affect the final result.

The exp functon i was using to test that W Lambert function i told on  the other post. Even if we won´t use it for the watermark r emover, we can use for other puposes in other image filters that we could make. I gave a try on that laplace 2D algorithm that used this exp and pow functions to compute the W function. But, after you explained, i understood better this laplace thing, but i wwant to give a try calculating the sigma as a standard deviation of the whole image and see if we will need this Lambert algoithm or not.

But, even if we wouldn´t need it we can use faster pow and exp to build other algorithms such as a faster (and more accurate) CieLab for example or the other algorithm i tried last year (HSM or something)
Coding in Assembly requires a mix of:
80% of brain, passion, intuition, creativity
10% of programming skills
10% of alcoholic levels in your blood.

My Code Sites:
http://rosasm.freeforums.org
http://winasm.tripod.com

guga

Quote from: jj2007 on August 12, 2020, 09:04:50 PM
Quote from: guga on August 12, 2020, 08:45:29 PMI see this:

I actually meant "what kind of pattern do you see, and how could we use it to fumble mantissa and exponent"

QuoteBtw..how you managed to create this curve window ? I like that a lot :thumbsup: :thumbsup: :thumbsup: :thumbsup:

See ArrayPlot in the help file. All you need is an array:

Event Paint
  ArrayPlot MyData(), RgbCol(200, 255, 255, 0), lines=4
  ArrayPlot exit, "Exponential function"


Hi JJ

You mean, the result ?

I took a look at the result and compared with the same value as in wolframalpha and...for my surprise, my algo seems to be 100% accurate (At least until the 13th digit) ! :dazzled: :dazzled: :dazzled: :dazzled:


These are the results i´ve got !

When using the input as Real8 i see this number:

exp(5) = 148.4131591025766

and in wolframalpha, the result is:

exp(5) = 148.4131591025766034211155800405522796234876675938789890467...

exp(-5) = 6.737946999085467e-3

in wolframalpha results in:

exp(-5) = 6.737946999085467096636048423148424248849585027355085430e-3

When i use the input as Real4(Float), i see this:

exp(5) = 148.4131591025766
exp(-5) = 6.737946999085467e-3

When i use the input as int, i see this:
exp(5) = 148.4131591025766
exp(-5) = 6.737946999085467e-3



This really surprises me, because on my initial tests, the original version from windows10 had a lack of precision after the 6th or 7th digit, but, somehow i managed to fix this damn algo, regardless the input format. So, even a int or Real4 value will result on a precise value without loss :greensml: :greensml: :greensml: :greensml: :greensml:
Coding in Assembly requires a mix of:
80% of brain, passion, intuition, creativity
10% of programming skills
10% of alcoholic levels in your blood.

My Code Sites:
http://rosasm.freeforums.org
http://winasm.tripod.com

nidud

#19
deleted

jj2007

Quote from: nidud on August 13, 2020, 01:29:54 AM
@Nidud: with AsmC /Znk I get that error A2071 :sad:
Quote
Well, it is an erroneous number according to the specification used:

    dq 2.42294657314453310e-310

...
However, ML and ML64 version 14 do not produce this error.

Indeed. And Olly reports 2.4229465731445330820e-310 in ST(0) after a fld with that number.

include \masm32\MasmBasic\MasmBasic.inc
ExpTable dq 2.42294657314453310e-310 ; invalid number for AsmC
  Init
  fld ExpTable
  fld FP10(1.0e310)
  fmul
  PrintLine "expected:  2.42294657314453310"
  PrintLine Str$("obtained:  %Jf", ST(0)v)
EndOfCode


Output:
expected:  2.42294657314453310
obtained:  2.422946573144533082


Using 2.4e-320, a certain loss of precision creeps in:
expected:  2.42294657314453310
obtained:  2.422897927205473053

HSE

Quote from: nidud on August 13, 2020, 01:29:54 AM
DBL_MAX equ 1.7976931348623158e+308
DBL_MIN equ 2.2250738585072014e-308

That is Normalized range.

Intel specification say that only 80 bit denormalized values can be loaded without to raise an exception...  I don't know, here I have an AMD  :biggrin:
Equations in Assembly: SmplMath

jj2007

Yep, but the hardware allows much more: at e-320 you still have over 4 digits of precision, more than enough for most purposes.

nidud

#23
deleted

jj2007

http://www.website.masmforum.com/tutorials/fptute/fpuchap4.htm
QuoteIf the source is a denormalized number, a Denormal exception will be detected, setting the related flag in the Status Word. The value will still be loaded and normalized if possible.

This is exactly what you can observe with Olly when loading from somevar REAL8 2.42294657314453310e-320 - the D flag is set. The question is how to deal with it. IMHO UAsm does it right: accept denormal values. If a programmer insists to work in this exotic range, he should know how to handle the loss of precision. A warning would be ok, though.

HSE

Equations in Assembly: SmplMath

nidud

#26
deleted

jj2007

Quote from: nidud on August 13, 2020, 09:59:25 AMI'm a bitu sceptical about this approach thought

The hardware can handle the value, but AsmC refuses to accept it? Let's use UAsm then.

Seriously: if the risk of setting the Underflow flag bothers you, issue a warning. The case is so exotic that I wouldn't worry at all.

nidud

#28
deleted

guga

Quote from: HSE on August 13, 2020, 05:12:28 AM
Quote from: nidud on August 13, 2020, 01:29:54 AM
DBL_MAX equ 1.7976931348623158e+308
DBL_MIN equ 2.2250738585072014e-308

That is Normalized range.

Intel specification say that only 80 bit denormalized values can be loaded without to raise an exception...  I don't know, here I have an AMD  :biggrin:

Tks you so much for the equates HSE
Coding in Assembly requires a mix of:
80% of brain, passion, intuition, creativity
10% of programming skills
10% of alcoholic levels in your blood.

My Code Sites:
http://rosasm.freeforums.org
http://winasm.tripod.com