[Aldor-l] [Axiom-math] Are Fraction and Complex domains.

[Christian Aistleitner]

Hello,

On Fri, 12 May 2006 14:19:19 +0200, Ralf Hemmecke <ralf at hemmecke.de> wrote:
> Maybe it is possible to instantiate Dom(0) twice.

you will probably not have any luck with 0. It is too small. But what  
about 1073741824?
For those who cannot convert dec to hex on the fly: "But what about  
0x40000000?" :)

The upcoming part is not clearly an example in favor of Ralf's requirement.
However, it is pretty close and shows some nasty things.
I do not understand how these things work, so anybody having _any_  
information on this, please share.
(Hopefully, I did not make an obvious mistake in the code again ...)


Executing the compiled test2.as (I attached this test2.as to the mail), I  
get:

(i)Domain ( param : 1073741824) -- r: 336495754
(i)(d)(i)Domain ( param : 1073741824) -- r: 2058543685
inc            : 336495754
inc dec inc    : 2058543685
----
(i)(i)(d)(i)
----
a              : 336495754
b              : 2058543685

(You will most likely get different numbers)
Since the code is not too straight forward, let me explain what happens.

(i)Domain ( param : 1073741824) -- r: 336495754
(i)(d)(i)Domain ( param : 1073741824) -- r: 2058543685

We get two different (see the different r) instantiations of Dom, both  
with the parameter "param" being 1073741824.

If now you are thinking that this behaviour is obvious, as the parameter  
"param" is computed two times and is therefore stored two times, then you  
are right.
They are two different representations for the same number. No doubt. (We  
could discuss what "functional" really means in the context of data  
representations. But I guess its ok to get different instantiations for  
different representations of the same number)
So the two parameters are equivalent (they store the same number), but not  
equal (they store the information differently--at least at different  
positions in memory).

However, Aldor *magically* knows something, about 1073741824 and its  
representations.
Why? Because of the lines:
a              : 336495754
b              : 2058543685

For these lines, 1073741824 is derived again in two different forms.  
However, no new instantiation of Dom is made. So we have four equivalent,  
but different representations and Aldor "knows" that two of them are  
equivalent.
Aldor "knows" that "a" is equivalent to the first inc NUM.
Aldor "knows" that "b" is equivalent to the first inc dec inc NUM.

We are tempted to think that this is some effect from recycling or  
preinitializing the constants.
But I oppose by referring to the lines
----
(i)(i)(d)(i)
----
. There, the increase and decrease functions are called again in order to  
actually compute the values again.

Does not look like reusing values to me.

How to explain this behaviour?
I am not sure.
However, recollecting what Manuel told me, the use of caching might  
explain things a bit.
But maybe its just some caching on BInt?
Do BInts have a sense for history? -- This would explain the whole thing.

Some further remarks:
Try to introduce a third representation of 1073741824 and the compiler  
produces segfaulting code.

For example: Add
stdout << "inc inc dec   : " << f()$Dom( inc inc dec NUM ) << newline;
or
stdout << "1073741824    : " << f()$Dom( 1073741824 ) << newline;

Since I am somehow puzzled but the whole thing, I would like to close this  
mail by a big questionmark.

   ****
  **  **
  **  **
      **
     **
    **
    **

    **
    **

--
Kind regards,
Christian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.as
Type: application/octet-stream
Size: 1349 bytes
Desc: not available
URL: <http://mail.aldor.org/pipermail/aldor-l_aldor.org/attachments/20060514/d9dbafc0/attachment-0001.obj>