[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GT] Re: Re: Re: perl floating point great-equal bug?



2009/11/5 Thomas Weigert <weigert
AT
mst.edu>:
> I think this warrants a broader examination.
>
> I think that prices, if they need to be matched precisely, should not be
> implemented as floating point numbers, or if we do so, they should be
> compared using an epsilon region.
>
> But it might be best to treat prices as fixed point numbers, to ensure
> that we can make exact comparisons?

+1, as this also enables more precise behaviour for things like
CS:Fixed:Stop, which might be doing a stop order on an impossible
fractional price, which should be rounded according to the minimum
fluctuation.

I think a tradable item ("code", in GT term) should define its minimum
fluctuation, and that unit should be in an integer value internally
for processing.

> In either case, a systematic review of the use of prices is warranted....
>
> Th.
>
> Robert A. Schmied wrote:
>> fr.gamberale
AT
tiscali.it wrote:
>>> Hello,
>>> Â Â i'm new to this Âmailing list, i started using GT at the
>>> beginning of this year but i didnt realize the project was going on,
>>> so i used the older version and i modified it a little bit.
>>> Now that i discoved the svn version im switching to it.
>>>
>>> One of the things that i changed on the library that seems not
>>> corrected in the svn version is a little bug using the >= and <=
>>> operators in floating context.
>>>
>>> The problem is that if you create the order using for the price
>>> ($order->price) a division like ($var/100)*100, the $order->price
>>> will not be exactly $var but $var Ä 0.000....01 (this is a known perl
>>> problem)
>>> and the is_executed function could return false if the $order->price
>>> is equal to the HIGH or the LOW of the bar.
>>>
>>> In particular i created 2 functions in Tools.pm and changed all the
>>> <= and >= with these functions in
>>>
>>> Portfolio/Order.pm
>>> is_executed function
>>> lines 372 373 389 394 402 403 408 409
>>>
>>> I dont know if this problem is present in other part of GT but i
>>> fixed only in Order.pm
>>>
>>> If someone is interested in the problem i can send Âthe
>>> Portfolio/Order.pm and Tools.pm modified.
>>>
>>> I hope this is usefull.
>>>
>>> PS: im using the http://www.geniustrader.org/wws/compose_mail/devel
>>> to write this post but i cant attach anything here.Is possible to
>>> send a post
>>> from thunderbird?
>>>
>>> thx
>>
>>
>> aloha fr.gamberale
>>
>> your observation could very well be the cause of many of the odd
>> results one
>> sees from time to time.
>>
>> as there are three (at least) gt branches on the svn at
>> http://geniustrader.org/
>> you need to identify the one you're using so we can get on the same
>> page (or at
>> least identify it as a reference).
>>
>> as far as sharing your fixes you can either post differences or the
>> complete files.
>> differences might be the preferred method, but it probably doesn't
>> matter much.
>> see man page diff(1) and/or info diff for details on how to create
>> difference files.
>> for reference diff -u orig_file changed_file. there are probably diff
>> equivalents
>> built-in in svn, but i don't know about them, so you are on your own
>> there.
>>
>> if you have subscribed to the gt devel mailing list you should be able
>> to post
>> messages with attachments to the list with any email client. see the
>> gt website
>> (http://geniustrader.org/) main page 'Mailing lists' section. for
>> reference you
>> post to devel
AT
geniustrader.org.
>>
>> ciao
>>
>> ras
>>
>