[Lemon-user] GraphReader

Kovács Péter kpeter at inf.elte.hu
Sun Jan 20 01:27:45 CET 2008


Hi,

Maybe Alpar's idea seems better. However there are special cases when it 
is not so good. For example if the .lgf file contains a map of 
dim2::Point value, the following lines are valid now:

	coords	
1	10 20
2	(30 40)
3	50, 60
4	(70, 80)
5	90,100
6	(110,120)

If we used the method suggested by Alpar, only the last two lines would 
be valid, but according to the current implementation of the 
dim2::Point::operator<< function, a graph writer would generate the 4th 
line. (Of course it could be changed to the last version: (x,y) without 
spaces.)

Peter


Alpár Jüttner írta:
> Hi,
> 
> This design has much more drawbacks than advantages.
> 
> The worst thing is that it makes it fully impossible to write any tool
> that would manipulate a general .lgf file. For example it is even
> impossible to correctly read a general .lgf file into a graph editor.
> 
> Do we really need such a free file-format? Probably we don't.
> 
> I think we should insist on the original definition, i.e. the edgeset
> and the nodeset of the file should consist of plain whitespace separated
> columns. The only exception I would allow is that a column can also be a
> string enclosed by two double-quotes characters (in order to enable
> whitespace containing strings). Of course, we may also use a more
> complex evaluation similar to the way the unix shells evaluate their
> parameters, but I'm not sure if it is worth doing that.
> This approach would make it possible to write general .lgf manipulation
> tools, and it would also enable a much simpler API for making custom
> readers/writers for special data types, as they would basically be
> converters between std::string and the data type.
> 
> Of course, it also means that we must write e.g. "x + y / 82" instead of
> just x + y / 82.
> I think it is really worth doing that.
> 
> Regards,
> Alpar
> 
> 
> 
> On Fri, 2008-01-18 at 17:20 +0100, Balazs Dezso wrote:
>> Hi
>>
>>> What is the reason for that?
>> The reader does not cache the string representation of the map value, because
>> the map reader reads the value directly from the input stream. More general
>> reason, the graph IO design is based on the next rule, just the map knows
>> where is the end of its input. By example, the value may contains space, or
>> it should be well formed expression.
>>
>> By example, valid values for some readers:
>> Hello\ world!
>> <xml> AB <tag> C </tag> D </xml>
>> x + y / 82
>> separator;
>> "\"Hello\" \"World\""
>>
>> Best, Balazs
>>
>> On Friday 18 January 2008 16.50.25 you wrote:
>>> Hi,
>>>
>>>> It is not possible, but an exception is thrown when you try to do this.
>>> What is the reason for that?
>>>
>>>>  The
>>>> only solution is using maps such ForkWriteMap...
>>>>
>>>> Best, Balazs
>>>>
>>>> On Thursday 17 January 2008 11.07.26 Alpár Jüttner wrote:
>>>>> Hi,
>>>>>
>>>>> Is it possible to read a column of an .lfg file into two different maps
>>>>> (of different types, such as NodeMap<double> and NodeMap<std::string>)
>>>>> at the same time?
>>>>>
>>>>> Regards,
>>>>> Alpar
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Lemon-user mailing list
>>>>> Lemon-user at lemon.cs.elte.hu
>>>>> http://lemon.cs.elte.hu/mailman/listinfo/lemon-user
>>>> _______________________________________________
>>>> Lemon-user mailing list
>>>> Lemon-user at lemon.cs.elte.hu
>>>> http://lemon.cs.elte.hu/mailman/listinfo/lemon-user
>>
> 
> _______________________________________________
> Lemon-user mailing list
> Lemon-user at lemon.cs.elte.hu
> http://lemon.cs.elte.hu/mailman/listinfo/lemon-user




More information about the Lemon-user mailing list