Ticket #2387 (closed enhancement: wontfix)

Opened 9 months ago

Last modified 3 months ago

[with partial patch] Create _sage_init_ functions for all objects

Reported by: jason Assigned to: was
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: interfaces Keywords: editor_wstein
Cc:

Description

Create a _sage_init_ function that behaves like the _maxima_init_, _magma_init_, etc., functions which returns a string sufficient to construct the given object in Sage.

For example: 

sage: a=matrix([[1,2,3],[4,5,6],[7,8,9]])
sage: a._sage_init_
'matrix([[1,2,3],[4,5,6],[7,8,9]])'

Attachments

sage_init.patch (7.9 kB) - added by jason on 03/05/2008 11:08:18 AM.

Change History

03/04/2008 12:45:56 PM changed by jason

  • summary changed from Create a _sage_init_ function for all objects to Create _sage_init_ functions for all objects.

03/05/2008 11:07:57 AM changed by jason

I've posted a stab at it by searching for _magma_init_ functions and implementing _sage_init_ next to it for most cases.

How should we deal with: 

sage: R.<y>=ZZ[]                                           
sage: a=matrix(R, [[y,1],[1,y^2]])                         
sage: a._sage_init_()                                      
"matrix(PolynomialRing(ZZ, 'y'), [[y, 1], [1, y^2]])"

The string returned will not construct the object usually since y is not a variable in a new session. However, putting in the parent of y would make things much uglier. How would you handle this situation?

03/05/2008 11:08:18 AM changed by jason

  • attachment sage_init.patch added.

03/05/2008 11:09:40 AM changed by jason

Also, there aren't any doctests...I'll be adding those. If anyone wants to comment on something I did, please do so! I'm not very familiar with the coercion system and did the above mainly by searching for _magma_init_ and copying where it made sense.

03/05/2008 11:10:00 AM changed by jason

  • summary changed from Create _sage_init_ functions for all objects to [with beta patch] Create _sage_init_ functions for all objects.

03/05/2008 11:10:28 AM changed by jason

  • summary changed from [with beta patch] Create _sage_init_ functions for all objects to [with partial patch] Create _sage_init_ functions for all objects.

03/05/2008 03:12:25 PM changed by was

However, putting in the parent of y would make things much uglier. How would you handle this situation?

I don't think it is possible without changing _sage_init_'s protocol as suggested by carl witty (either allow a sequence of semicolon separated statements or have two blocks, an initialization block and a eval block). I think I prefer the latter solution, since it can be used to do the former and more, but not conversely.

06/19/2008 09:44:12 PM changed by craigcitro

  • keywords set to editor_wstein.

08/25/2008 12:34:57 PM changed by mabshoff

  • status changed from new to closed.
  • resolution set to wontfix.
  • milestone changed from sage-3.1.2 to sage-duplicate/invalid.

Closed as wontfix due to #3484 and #3485. 

[12:29pm] jason-: mabshoff_, cwitty: I believe that 3484 and 3485 make 2387 obsolete.  Comments?
[12:29pm] mabshoff_: let me check
[12:29pm] jason-: (it's the sage_input stuff; I made a simple sage_init patch a long time ago)
[12:30pm] cwitty: I agree.
[12:30pm] mabshoff_: Ok, let's close it as "wontfix" then.
[12:30pm] mabshoff_: objections?
[12:30pm] You are now known as mabshoff.
[12:31pm] jason-: hehe, *another* ticket that is < 0.61*(current ticket number) down!

Cheers,

Michael