[Ohrrpgce] SVN: james/9631 The "experience to level" command now has a new optional hero slot argum

Ralph Versteegen teeemcee at gmail.com
Tue Nov 7 08:55:55 PST 2017


I think that as long as we aren't using functions like exp, sin, log, etc,
it can be fixed. The IEEE 754 floating point standard is actually very
strict about results being the same everywhere, and compilers not being
allowed to change the results when performing optimisations. I think those
functions are meant to return exactly the same result on all CPUs and
compilers (at least, basic operations like multiplication definitely must);
my ARM CPU is just not conformant.

I just need to find out the equivalent code for other OSes.

Anyway, if we couldn't make the fpu consistent, the best solution would be
to change exptolevel to not use floating point math.

On 8 November 2017 at 05:26, James Paige <Bob at hamsterrepublic.com> wrote:

> If the problem isn't realistic to fix, then we might just have to make
> those particular tests more fuzzy.
>
> abs(experience to level(2, bram slot) -- 69) < 2
>
> It ain't ideal but I could live with it.
>
>
>
> On Tue, Nov 7, 2017 at 8:23 AM, Ralph Versteegen <teeemcee at gmail.com>
> wrote:
>
>>
>>
>> On 8 November 2017 at 05:18, Ralph Versteegen <teeemcee at gmail.com> wrote:
>>
>>> We have a bit of a problem: the xp formula produces different results in
>>> gengcc=1 builds!
>>>
>>> ! TRACE: ASSERT FAILURE:
>>> ! TRACE: autotest.hss:1127: experience to level(2, bram slot) == 69
>>> [actual values were 70 == 69]
>>>
>>> This would be because floating point calculations aren't totally
>>> reproduceable between different CPU architectures, compilers, and build
>>> options. The biggest problem is that the x87 FPU defaults to using 80 bit
>>> registers, so it makes a difference whether a compiler puts an intermediate
>>> result in a register or writes it out.
>>> In this case, an intermediate result is 34.5, and it gets rounded
>>> differently.
>>>
>>> By coincidence, I read through the long discussion at
>>> http://yosefk.com/blog/consistency-how-to-defeat-the-purpose
>>> -of-ieee-floating-point.html
>>> about this just a week or two ago.
>>>
>>> I've tried and confirmed that running the following linux-specific code
>>> to use 64-bit instead of 80-bit x87 registers fixes the assert failure:
>>>
>>
>> Oh, to be clear, it doesn't fix the failure, it just makes gengcc=0 and
>> gengcc=1 consistent, by making them both return 70.
>> Of course, we do use floating point in a number of places, so I wonder
>> how many of those could lead to a visible change.
>>
>>
>>> #include <fpu_control.h>
>>> fpu_control_t cw;
>>> _FPU_GETCW(cw);
>>> cw = (cw & ~_FPU_EXTENDED) | _FPU_DOUBLE;
>>> _FPU_SETCW(cw);
>>>
>>> I read that this might have negative effects on the accuracy of math
>>> functions like pow() implemented with library routines, but it'll be pretty
>>> tiny.
>>>
>>> I was planning on adding this anyway, to make scripts (once we add
>>> floating point to HS) more portable between CPUs and builds.
>>> But you're never going to avoid 100% of differences. For example the ARM
>>> fpu in my phone gives larger errors on some math functions like exp, which
>>> actually causes several tests in freebasic's test suite to fail.
>>>
>>>
>>> On 1 November 2017 at 09:55, <subversion at hamsterrepublic.com> wrote:
>>>
>>>> james
>>>> 2017-10-31 13:55:49 -0700 (Tue, 31 Oct 2017)
>>>> 208
>>>> The "experience to level" command now has a new optional hero slot
>>>> argument for checking the experience curve of a specific hero
>>>> Also added a test-case to autotest.rpg verifying a customized
>>>> experience curve
>>>> ---
>>>> U   wip/docs/plotdict.xml
>>>> U   wip/docs/plotdictionary.html
>>>> U   wip/plotscr.hsd
>>>> U   wip/scriptcommands.bas
>>>> U   wip/testgame/autotest.hss
>>>> U   wip/testgame/autotest.rpg
>>>> _______________________________________________
>>>> Ohrrpgce mailing list
>>>> ohrrpgce at lists.motherhamster.org
>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>
>>>
>>>
>>
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
>>
>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20171108/d085926a/attachment.html>


More information about the Ohrrpgce mailing list