[Push] division and tangent instructions

[Lee Spector]

Maybe you're right and I don't care so much about auto-promotion per se. I just prefer integers to be able to get big without getting weird. (And this only for some projects, I guess.) I don't care as much how many bits or whatever other implementation details are involved in representing them when they're small, but if the system can transparently make them faster via automatic, behind-the-scenes tricks then that's swell. That's the norm in the Lisp world, with auto-promotion, and I assume it's an efficiency win over using only bigints.

I don't really know if weird hybrid uses of integers as addresses and data will really make sense in a lot of evolutionary contexts. I was only trying to point out that the intuitive separation of the uses doesn't necessarily hold water in an evolutionary context and so I wouldn't want to commit to it as part of a standard.

I guess it would make sense to say that an implementation should allow users to specify how numbers will be handled -- not only the bit representation but also auto-promotion (or not), translations between types, what gets used in indexing instructions, etc -- but I think that's a big job and it may be more realistic to demand only that all of this be documented, including whatever choices the implementation gives the user.

 -Lee


On Jun 30, 2010, at 3:52 AM, PerPlex Ed wrote:

> Lee said:
>> My own preference would be to start with a single integer type that acts as close to mathematical integers as possible, which I guess means that it auto-promotes to BigInts, and to use this type for all things that 
> need integers (unless there's a good reason to create another integer 
> type for a specific application).
> Ok. Then just use that BigInts and write it in the language specification.
> One thing I don't understand. If you don't care about the bit representation and performance, why do you care about auto-promotion? For performance reasons?
> If I don't care about a performance penalty and want integers that work as mathematical integers, I just use BigInts and that's all. Some BigInts implementations may be optimized to be almost as fast as normals ints for "small" values. If I'm lucky, I'll be using one of those, otherwise... didn't we said we can accept a performance penalty if we get mathematical integers? Auto-promotion itself has a performance penalty, I presume.
> 
> 
>> ((code.nth) code.atom)
>> I'm sure one could express (and evolve) solutions in the context of 
> other schemes for representing integers, even if "addressing" and 
> "arithmetic" uses are separated into two different types. But this 
> elegant little program presumably wouldn't work.
> 
> I guess a solution of that kind has a value but only in few contexts.
> Every language that one can use for genetic programming has its peculiarities that can be - and, because of the very nature of genetic programming, will be exploited sooner of later.
> 
> If your experience tells you that there are many cases where it's worth running or even only testing programs and evolution using a single arbitrary size integer type for both addressing and computations, then demand that all 100% conformant Push implementations should allow you to switch between 32bit(, 64bit) and BigInts as the underlying representation of the main Integer Push type.
> 
> That would be a setting to be choosen before the interpreter is initialized, of course.
> 
> 
> 
> 
> _______________________________________________
> Push mailing list
> Push at lists.hampshire.edu
> https://lists.hampshire.edu/mailman/listinfo/push

--
Lee Spector, Professor of Computer Science
School of Cognitive Science, Hampshire College
893 West Street, Amherst, MA 01002-3359
lspector at hampshire.edu, http://hampshire.edu/lspector/
Phone: 413-559-5352, Fax: 413-559-5438

Check out Genetic Programming and Evolvable Machines:
http://www.springer.com/10710 - http://gpemjournal.blogspot.com/