Some random thoughts on future features



C Y wrote:

>--- Richard Fateman <fateman@cs.berkeley.edu> wrote:
>
>  
>
>>2. It is not so clear how to combine stuff.  For example,
>>bigfloats of different precision.  Rational + float could be
>>made into a rational.  It could be made into a float unless it
>>overflows.
>>    
>>
>
>Presumably the least precise bigfloat would win, wouldn't it? 
>
Not necessarily.  In the current system, all bigfloats are converted to 
the global
floating-point precision setting and arithmetic is done in that precision.
Assuming that a number is inaccurate because it has low precision is not 
always
right.  Another rule, useful in the example below, is to do all 
arithmetic in the
widest format, if there is an obvious one,  and then perhaps convert to 
some other
narrower form if that seems to be appropriate.

> As for
>rational plus float, wouldn't it be better to have it remain a rational
>unless someone uses the float() or numer() commands on it?  
>  
>
for CRE  there is keepfloat flag.  Using rationals when not justified 
can lead to
exponentially long number representations. (exponential in number of 
operations performed).

>I know these are just examples, but really we should have some idea
>about all this stuff because:
>
>a)  Currently, Maxima has some behavior which may or may not be correct
>for all these assorted questions, unless it just avoids them by
>limiting its abilities.  If these things are concerns, minimally we
>should be able to say what we do even if we can't defend it.
>
>b)  If we want to have appeal to the community, I think we have to be
>able to address things like this in order to be taken seriously.
>  
>
probably true.

>  
>
>>If you add a+b+c+d,  it may make sense to look at the types of all
>>the operands before adding any two of them.
>>    
>>
>
>Conversely, would it make sense NOT to?  If you don't, aren't you just
>avoiding the issue?  Or am I missing something?
>  
>
See above.

>  
>
>>There are many papers in the computer algebra literature espousing
>>the use of a different kind of "type" system that imposes some 
>>algebraic structure rather than some data abstraction inheritance 
>>structure. That is, notions of rings, fields, polynomials over rings,
>>    
>>
>
>  
>
>>etc. rather than built-in numbers, arrays of built-in numbers, etc.
>>    
>>
>
>How much work would be required to move Maxima to such a system?  It
>sounds like it would be a major system overhaul, but I could be wrong.
>
I assume it would require a major overhaul.  Maybe starting over with 
Axiom as
a base!

>
>  
>
>>Axiom uses this.  Mupad maybe uses this. Maple has a system "Gauss"
>>that professes to use this. Foderaro's "Newspeak" system used 
>>something like this.  Zippel's Weyl system too.
>>
>>Not to say that using CLOS would be bad, just that the thoughts along
>>these lines can be pushed in different dimensions.
>>    
>>
>
>This sounds like something that should be addressed post 5.9.3 (unless
>we can't kill a large number of math bugs without addressing it).  With
>case sensitivity starting to come into focus, hopefully (knock on wood)
>5.9.2 will not be too long in coming.  Then we can rip into the math
>bugs for 5.9.3, which will hopefully put us in a good position to make
>more fundamental decisions between 5.9.3 and 5.9.4.
>  
>
OK with me.

>CY
>